Geo

From EXPath

(Difference between revisions)
Jump to: navigation, search
m (Definition of the EXPath Geo module proposal)
Line 14: Line 14:
Relying on the OGC SF API implies a specific markup for the geometry model.  I believe this is where things get complicated for implementors, as they will have to arbitrate the interchange between the XML markup for geometries, which can vary widely, and the internal (native) model of geometries, which of need must be strictly controlled.
Relying on the OGC SF API implies a specific markup for the geometry model.  I believe this is where things get complicated for implementors, as they will have to arbitrate the interchange between the XML markup for geometries, which can vary widely, and the internal (native) model of geometries, which of need must be strictly controlled.
-
To gain broad adoption, I recommend supporting the GML 2.1.2 geometry encoding of OGC SF.  While this encoding does not take advantage of the XML Schema list types that later versions of GML do, it is widely used, notably by KML.  
+
To gain broad adoption, I recommend supporting the [http://www.opengeospatial.org/standards/gml GML 2.1.2] geometry encoding of OGC SF.  While this encoding does not take advantage of the XML Schema list types that later versions of GML do, it is widely used, notably by KML.  
-
To enable faster processing, it may be desirable to also support GML 3.x  There may be significant differences between 3.0 and 3.2 markup that someone very intimate with those specifications should flag.  Supporting too many encodings will make the EXPath Geo module more difficult to implement, hence we should agree on a single model and let XQuery / XSLT developers use their tools to converge on that model in order to use EXPath.
+
To enable faster processing, it may be desirable to also support [http://www.opengeospatial.org/standards/gml GML 3.x] There may be significant differences between 3.0 and 3.2 markup that someone very intimate with those specifications should flag.  Supporting too many encodings will make the EXPath Geo module more difficult to implement, hence we should agree on a single model and let XQuery / XSLT developers use their tools to converge on that model in order to use EXPath.

Revision as of 05:53, 7 April 2010

The EXPath Geo module is a proposal for geospatial functions that would be useful in an XPath context.

To begin, the module core should be based on the Simple Features API from the Open Geospatial Consortium. Using the OGC SF specification implies a geometry model as well as a set of standard high-level functions for manipulating or managing interactions between geometries. The XML model allows a deeper interaction with geometries than that enabled by the OGC SF, yet it is those functions identified by OGC SF which would be out of reach, if not impossible, for most XQuery and XSLT applications of XPath.

For example, to allow a stylesheet to display a map of a set of features (in SVG for example), it is necessary to 'clip' the features to the neatline of the map. This is enabled through the "intersection" function of SF.

The functions are categorized by OGC SF into "query" and "analysis". A third category would be accessors, which allow conversion and introspection, which may be less important in an XPath setting because of the granularity of the XPath model.

Analysis functions: distance, buffer, convexHull, intersection, union, difference and symDifference (symmetric difference).
Query functions: equals, disjoint, touches, crosses, within, contains, overlaps, relate, locateAlong, locateBetween.

Issues

Relying on the OGC SF API implies a specific markup for the geometry model. I believe this is where things get complicated for implementors, as they will have to arbitrate the interchange between the XML markup for geometries, which can vary widely, and the internal (native) model of geometries, which of need must be strictly controlled.

To gain broad adoption, I recommend supporting the GML 2.1.2 geometry encoding of OGC SF. While this encoding does not take advantage of the XML Schema list types that later versions of GML do, it is widely used, notably by KML.

To enable faster processing, it may be desirable to also support GML 3.x There may be significant differences between 3.0 and 3.2 markup that someone very intimate with those specifications should flag. Supporting too many encodings will make the EXPath Geo module more difficult to implement, hence we should agree on a single model and let XQuery / XSLT developers use their tools to converge on that model in order to use EXPath.

Personal tools