Christian,

No problem, glad I can (hopefully) help.

Perhaps you or someone else can help me get started. Is there something special I need to do in order to get the geo module to work while running inside eclipse? I can compile and run basex, but if I try any queries with geo: I get "[XQST0059] Module "http://expath.org/ns/geo" not found."

So then I went to the command line and did 'mvn compile' and 'mvn package' instead of using m2eclipse, and I got a bunch of jars in basex-api/lib as I might expect. But when I run from that directory (setting the classpath appropriately) I get the same error.

Finally, I tried copying my newly built jar into the basex .zip distribution directory (downloaded separately), and that worked. So I guess, how do I get the zip distribution stuff from etc/modules to work within eclipse?

Thanks,
Zach


-



On Fri, Oct 25, 2013 at 8:29 AM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Zach,

thanks for your long e-mail, and your offer to add WKB support to the
Geo Module. I absolutely agree that it would be nice to have support
for other Geo format. The main reason for the GML support is that we
didn’t have time yet to adopt other standards.

We are looking forward to your implementation. Masoumeh, who has
written the Geo module, will soon give you some more feedback.

Best,
Christian
___________________________

2013/10/25 Zachary DeLuca <zadeluca@gmail.com>:
> Hi All, apologies in advance for the long message,
>
> I have many documents that store WKB (base64-encoded) geometry data (going
> for speed not readability). I want to be able to do queries where I can use
> the geo predicate functions with the stored WKB geometry and a provided WKT
> geometry. Example:
>
> Sample document structure: <root><geoWKBdata type=xs:base64Binary/></root>
> Sample query: collection()/root[geo:intersects(geo:fromWKB(geoWKBData),
> geo:fromWKT("LINESTRING((0,0),(1,1))"))
>
> I have looked at the module code and the only problem is that all methods
> assume an input of GML. I don't want to just make functions to convert from
> WKB/WKT to GML on input because I think that would be very inefficient
> (slow).
>
> I could just hack something together for my own needs, but I would like some
> input so that ideally I can produce something good enough to contribute back
> to the project. Options:
> 1) Add copies of all methods to accept each possible encoding type (GML,
> WKB, WKT). I don't like this approach because it doesn't scale well, and I
> don't even know if it's possible? (Pretty sure you can't overload functions
> in XPath/XQuery)
> 2) Leave the Geo module the way it is and add "sister" modules for the
> additional encoding types. Yuck.
> 3) The only thing that makes sense, really. Define 3 new functions, fromGML,
> fromBinary, and fromText and change the signatures of all module functions
> to just accept Geometry objects. That way you can load your geometry however
> you want and then pass it to the desired function. I will also modify the
> functions asText and asBinary to accept a Geometry object, and add an
> additional asGML so that the many existing functions that already return GML
> (envelope, boundary, etc.) can instead return Geometry, and can then be
> converted as needed to the desired format. This should scale well too
> because if any future encoding formats are desired all you need to do is add
> fromXYZ and asXYZ functions. With these functions, you could also string
> together 2 calls to convert between any of the supported encoding types.
> Does this make sense? It seems easy enough, am I missing anything?
>
> Also, assume for a second that I implement #3. Refer to my sample
> document/query above. As I understand it, for each document in the
> collection, the back end will have to parse "LINESTRING((0,0),(1,1))" into a
> Geometry first in order to compare. Is there any way to make that happen
> only once for the duration of the query? Is it as easy as this?:
> let $data = geo:fromText("LINESTRING((0,0),(1,1))");
> return collection()/root[geo:intersects(geo:fromWKB(geoWKBData), $data)
> This would work, right? (I'm new to XQuery, sorry)
>
> So, am I on the right track with this? Have I overlooked some absurdly
> simple solution to my problem? I would appreciate any and all input. As I
> said, I would like to go beyond meeting my own needs and actually get this
> into the code base.
>
> I'll leave you with this snippet taken from the EXPath Geo Module Spec:
> "The data model envisioned by EXPath Geo module is abstract in the sense
> that it may be possible for module implementers to support more than one
> encoding on input. Output data types are specified in GML and XML Schema,
> where appropriate. All that is necessary is that the input geometry be
> transformable to the model specified by OGC SF and supported by the EXPath
> implementation. -SNIP- Implementations are not limited to GML, KML, nor even
> XML, on input. It is possible that geometries encoded as “Well Known Text”,
> GeoJSON, or even “Well Known Binary”, among other possibilities, could be
> supported by an implementation."
>
> Thanks,
> Zach
>
> _______________________________________________
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>