From EXPath

Revision as of 19:54, 14 August 2010 by FGeorges (Talk | contribs)
Jump to: navigation, search

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

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.


To help open source development of EXPath Geo, Java Topology Suite (JTS) provides a 100% java comprehensive implementation of OGC SF for Java developers and GEOS is a C++ port of JTS. Closed source implementations may be able to negotiate appropriate licensing with those projects or others more suitable to that development model.


  • 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.

Notes on the current draft

First, agree or not on the following changes I made directly on the draft:

  • 1/ I changed the <eg> and <p>: <p> must follow the <eg>, not be embedded.
  • 2/ I changed some punctuation and put a capital at the beginning of each paragraph.
  • 3/ I've changed the param name in CamelCase to dash-separated.
  • 4/ The <a> elem does not exist, I've change them to <loc>.
  • 5/ I've added the "as" keyword before the return type of the functions.
  • 6/ I've indented correctly the function signatures: the spaces are preserved within <eg>, and I put each param on its own line, indented to the first one.
  • 7/ I've put the sections <div2> that contain the function at the level <div1>, to avoid hidding the structure of the document by having at top-level only two parts: intro + geo module. I find that more clear, but you can revert it of course. I think we should find a better name for section 2. instead of "Thw geo: module".

Then maybe discuss quickly and possibly address the following points:

  • a/ "nil" in XPath would be the empty sequence, so the return type would change from xs:double to xs:double? (with the question mark).
  • b/ What's "LineString"? (in section "Curve")
  • c/ A blocker issue for publication is the definition of the function spatial-dimension(), which reads: "Not sure what this is". In the worst case scenario, we can comment it out in the first version.
  • d/ I do not really know this domain, but it feels like the types are not precise enough. Most of them are defined as "node()". Couldn't they be more precise in most case? Like "element(kml:geometry)" instead of "node()" when a geometry is passed or returned (assuming such an element exist, I really do not know this language).
  • e/ Even if the d/ is not really possible, we should explain the data model on which this module is based. It seems to be at the heart of the library, and it is not explained.
  • f/ The sections 2 reads: "This module defines a set of XPath extension functions". Well, defines XPath functions, not necessarily extensions. I would remove this word.
  • g/ Then the links says: "Simple Feature access (SFA)". I guess the "A" of "access" should be upper case.
  • h/ Does dimension() return -1? Not the empty sequence instead?
  • i/ In coordinate-dimension(), make a proper sentence, replace "<=" by some words, and replace "dimension($geometry as node()) for a given geometry node" by just "dimension($geometry)" (i.e. calling this function with the same param).
  • j/ I don't understand the definition of geometry-type().
  • k/ Put some marker around editorial notes, like for srid() ("Not quite sure...") For instance "[ TODO: Not quite sure ... ]".
  • l/ In is-simple(): "ring". In graph theories, and in algorithms in general, the coined term is "cycle". Is "ring" the idiomatic term in the Geo world? (I don't know, that's maybe even a different concept)
  • m/ In "Spatial predicate functions": there is no definition of "spatially equal", "spatially disjoint", etc. E.g. the definition of equals() says: "Returns whether $geometry is spatially equal to $another-geometry." But there is no definition of "spatially equal". Same remark for every function in this section.

That's all for now :-)

Personal tools