From EXPath

Revision as of 06:09, 7 April 2010 by PRushforth (Talk | contribs)
Jump to: navigation, search

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.


  • 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 specifying support for the GML 2.1.2 geometry encoding of OGC SF. While this encoding does not take advantage of the XML Schema list types (for coordinate pairs) 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.

  • The relate function yields an interaction matrix between geometries. A standard XML markup for the result of this function may be desirable.
Personal tools