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
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:
- 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
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.comwrote:
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:
- 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
Scratch that last question, I think I figured that part out. I had not set the classpath correctly.
On Fri, Oct 25, 2013 at 2:02 PM, Zachary DeLuca zadeluca@gmail.com wrote:
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:
- 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
Dear Zachary,
Thanks for your interest and inquiry. Sorry for being late.
The solution which have you proposed sounds good enough. The point that you need to consider is that there is no such a data type as Geometry in BaseX. Data type which is used after the parsing step in BaseX is JTS Geometry type. So, there is a need to do the conversion from a DB node or even more an abstract node (ANode in BaseX) to Geometry,before to put it as an input argument in module functions, in case which the input types would be changed.
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)
Right! This would happen just once, using a map inside the source code. So, $data would be only converted just once during the query time.
It might help also to take a look at the directory I have put the related classes in [1], since there is also some works done for spatial index structure for GML.
Hope this helps. If there is any question or ambiguity, let me know.
Regards, Masoumeh
[1] https://github.com/Masoumeh/basex-api/tree/master/src/main/java/org/expath/n... ------------------------------------------------------------------------------------------------------------------------------------------------- On Friday, October 25, 2013 04:32 CEST, Zachary DeLuca zadeluca@gmail.com wrote:
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:
- 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
Masoumeh,
Thanks for your response. I will take a look at the directory you provided to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry type, I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need to be used in conjunction with the new fromXYZ() and asXYZ() methods on input and output, respectively, to parse and represent the data as needed. Are we on the same page with what I intend to do?
Problems with this approach: 1) This is an API breaking change; current users of the Geo module will need to adapt their code. 2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be nice if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to implement it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g. geo:as-text()) reconciled with the name of the appropriate java method (Geo.asText()) when the names are not the same in this case?
Thanks, Zach
Hi Zachary,
a short one: I wouldn’t recommend to break the existing API, as implementation independence is something EXPath is all about. Instead, I would vote for a unified XML representation of the geometry objects, which can then be interpreted by the Geo functions. Converting XML to objects and back sounds like an expensive operation, but there’s a lot of potential for optimizations when it turns out that the conversion is a real bottleneck.
Christian ___________________________
2013/10/28 Zachary DeLuca zadeluca@gmail.com:
Masoumeh,
Thanks for your response. I will take a look at the directory you provided to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry type, I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need to be used in conjunction with the new fromXYZ() and asXYZ() methods on input and output, respectively, to parse and represent the data as needed. Are we on the same page with what I intend to do?
Problems with this approach:
- This is an API breaking change; current users of the Geo module will need
to adapt their code. 2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be nice if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to implement it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g. geo:as-text()) reconciled with the name of the appropriate java method (Geo.asText()) when the names are not the same in this case?
Thanks, Zach
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Zachary,
I also do agree with you Christian, to not change the current API. Based on the point which JTS contains WKT/WKB Reader/Writer functions, adding the support of WKB/T after the format recognition seems not to be hard. We would need a function that finds the input format, then we can call the function checkGeo based on the input format. So, this function should be extended to read WKT/B.
About the unified XML, since geometries are based on the points, it could be possible to form the geometries as an objects made of a set of points in this format.
Question: How is the name of an XQuery Module function (e.g. geo:as-text()) reconciled with the name of the appropriate java method (Geo.asText()) when the names are not the same in this case?
Exactly. The naming is exactly in this way.
Regards, Masoumeh ---------------------------------------------------------------------------------------------------------------------------------------------
On Monday, October 28, 2013 18:06 CET, Zachary DeLuca zadeluca@gmail.com wrote:
Masoumeh,
Thanks for your response. I will take a look at the directory you provided to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry type, I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need to be used in conjunction with the new fromXYZ() and asXYZ() methods on input and output, respectively, to parse and represent the data as needed. Are we on the same page with what I intend to do?
Problems with this approach:
- This is an API breaking change; current users of the Geo module will
need to adapt their code. 2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be nice if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to implement it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g. geo:as-text()) reconciled with the name of the appropriate java method (Geo.asText()) when the names are not the same in this case?
Thanks, Zach
I agree with both of you about not breaking the API. I have reviewed the Geo spec more and I think I understand the intent of how to support multiple input formats.
I'm not sure about a unified XML representation, though. I would think the normal usage of WKT/WKB would be a simple type element in a document (xs:string or xs:base64Binary) or even just a literal text value.
Forgive me, thinking out loud. What if we did something like: - Create QName of input types (make something up, how about ogc:wkt and ogc:wkb) where each contain a single text node containing the WKT/WKB data. Data in this format can be loaded directly into geo module functions because checkGeo() will be modified to recognize the QName and will parse appropriately. - Additionally, fromText and fromBinary methods take as input a simple element (and/or literal?) and just uses the value (ignores the name). That way it will work no matter the element name in the document and not require the use of our made up type names, since it is just a simple type anyway. It can take the text value and wrap it with QName created above, which can be processed "normally." So in my example from my first email where the WKB is stored in my document as geoWKBdata, I can use fromBinary to get it loaded into the appropriate namespace without knowing or caring about what it is. - Since EXPath Geo spec defines output of analysis functions as GML any, that should not change. But you can still use as-text and as-binary to get the WKT/WKB content anyway.
I think this would work great without breaking anything, but not sure if it is hackish. Thoughts?
Thanks, Zach
On Wed, Oct 30, 2013 at 3:02 AM, Masoumeh Seydi Gheranghiyeh < Masoumeh.Seydi-Gheranghiyeh@uni-konstanz.de> wrote:
Hi Zachary,
I also do agree with you Christian, to not change the current API. Based on the point which JTS contains WKT/WKB Reader/Writer functions, adding the support of WKB/T after the format recognition seems not to be hard. We would need a function that finds the input format, then we can call the function checkGeo based on the input format. So, this function should be extended to read WKT/B.
About the unified XML, since geometries are based on the points, it could be possible to form the geometries as an objects made of a set of points in this format.
Question: How is the name of an XQuery Module function (e.g.
geo:as-text())
reconciled with the name of the appropriate java method (Geo.asText())
when
the names are not the same in this case?
Exactly. The naming is exactly in this way.
Regards, Masoumeh
On Monday, October 28, 2013 18:06 CET, Zachary DeLuca zadeluca@gmail.com wrote:
Masoumeh,
Thanks for your response. I will take a look at the directory you
provided
to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry
type,
I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need
to
be used in conjunction with the new fromXYZ() and asXYZ() methods on
input
and output, respectively, to parse and represent the data as needed. Are
we
on the same page with what I intend to do?
Problems with this approach:
- This is an API breaking change; current users of the Geo module will
need to adapt their code. 2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be
nice
if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to
implement
it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g.
geo:as-text())
reconciled with the name of the appropriate java method (Geo.asText())
when
the names are not the same in this case?
Thanks, Zach
Hi Zachary,
I think this would work well. Actually this is somehow the way GML support is added and could be extended to the other formats, as you have described.
Bests, Masoumeh ------------------------------------------------------------------------------------------------------------------- On Wednesday, October 30, 2013 16:35 CET, Zachary DeLuca zadeluca@gmail.com wrote:
I agree with both of you about not breaking the API. I have reviewed the Geo spec more and I think I understand the intent of how to support multiple input formats.
I'm not sure about a unified XML representation, though. I would think the normal usage of WKT/WKB would be a simple type element in a document (xs:string or xs:base64Binary) or even just a literal text value.
Forgive me, thinking out loud. What if we did something like:
- Create QName of input types (make something up, how about ogc:wkt and
ogc:wkb) where each contain a single text node containing the WKT/WKB data. Data in this format can be loaded directly into geo module functions because checkGeo() will be modified to recognize the QName and will parse appropriately.
- Additionally, fromText and fromBinary methods take as input a simple
element (and/or literal?) and just uses the value (ignores the name). That way it will work no matter the element name in the document and not require the use of our made up type names, since it is just a simple type anyway. It can take the text value and wrap it with QName created above, which can be processed "normally." So in my example from my first email where the WKB is stored in my document as geoWKBdata, I can use fromBinary to get it loaded into the appropriate namespace without knowing or caring about what it is.
- Since EXPath Geo spec defines output of analysis functions as GML any,
that should not change. But you can still use as-text and as-binary to get the WKT/WKB content anyway.
I think this would work great without breaking anything, but not sure if it is hackish. Thoughts?
Thanks, Zach
On Wed, Oct 30, 2013 at 3:02 AM, Masoumeh Seydi Gheranghiyeh < Masoumeh.Seydi-Gheranghiyeh@uni-konstanz.de> wrote:
Hi Zachary,
I also do agree with you Christian, to not change the current API. Based on the point which JTS contains WKT/WKB Reader/Writer functions, adding the support of WKB/T after the format recognition seems not to be hard. We would need a function that finds the input format, then we can call the function checkGeo based on the input format. So, this function should be extended to read WKT/B.
About the unified XML, since geometries are based on the points, it could be possible to form the geometries as an objects made of a set of points in this format.
Question: How is the name of an XQuery Module function (e.g.
geo:as-text())
reconciled with the name of the appropriate java method (Geo.asText())
when
the names are not the same in this case?
Exactly. The naming is exactly in this way.
Regards, Masoumeh
On Monday, October 28, 2013 18:06 CET, Zachary DeLuca zadeluca@gmail.com wrote:
Masoumeh,
Thanks for your response. I will take a look at the directory you
provided
to see what I can learn from it. I was working on this at the end of last week and began to discover some of the problems in my plan.
Just to clarify, in my original email, when I mentioned the Geometry
type,
I was referring to the JTS Geometry type. So my intent was to change the method signatures for all Geo methods and replace ANode (input parameters AND return types) with JTS Geometry. In this case, all Geo methods that currently expect input as or return data as GML (ANode) would then need
to
be used in conjunction with the new fromXYZ() and asXYZ() methods on
input
and output, respectively, to parse and represent the data as needed. Are
we
on the same page with what I intend to do?
Problems with this approach:
- This is an API breaking change; current users of the Geo module will
need to adapt their code. 2) Don't think the module would remain strictly compliant with the EXPath Geo spec? (functions are spec'd with node() as input parameters and element() as return types with GML assumed) But the spec does talk about supporting multiple encoding types and this is one way to accomplish that goal...
I cannot think of a way to avoid these problems I listed. It would be
nice
if everything could remain unchanged except modify checkGeo() to somehow detect the input format and construct the JTS Geometry automatically (and efficiently!). And then for methods that return a geometry, replace gmlWriter() with something that automatically returns it in the format of the geometry(s) used on input. I don't think I would know how to
implement
it in this way, but if this is a better/preferred approach and you have some ideas on how to make it work, I would be glad to do it that way instead.
Question: How is the name of an XQuery Module function (e.g.
geo:as-text())
reconciled with the name of the appropriate java method (Geo.asText())
when
the names are not the same in this case?
Thanks, Zach
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Masoumeh Seydi Gheranghiyeh -
Zachary DeLuca