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
