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