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