Simple Geometry Language

This page describes some incomplete work undertaken in 2003 to define a standard, XML-based language for describing geographic regions, i.e., geometric regions on the Earth's surface. For brevity, we'll call any such language a geometry language. A geometry language defines a set of possible shapes and standard representations and encodings of those shapes, and also addresses the handling of cartographic quantities (Earth datums, projections, and coordinate systems), either by mandating standard quantities or by providing standard declaration mechanisms.

The motivation for a standard geometry language is rooted in the observation that every system/service/effort that has had to deal with geographic regions has ended up defining its own geometry language. All these languages have broadly similar capabilities to varying degrees, yet all have enough idiosyncracies to bedevil easy interoperability. It is instructive to compare and contrast the geometry languages embedded in specifications such as:

• FGDC Content Standard for Digital Geospatial Metadata
  (see "Spatial Domain," p. 5, and "Latitude and Longitude," p. x)
• ADN (ADEPT/DLESE/NASA) metadata framework
  (see Geospatial overview and geospatial.xsd)
• ADL Middleware Server
  (see elements <spatial-value> in ADL-bucket-report.dtd and <spatial-constraint> in ADL-query.dtd)
• ADL Gazetteer Protocol
  (see Reports and Query language and elements <bounding-box> and <footprints> in gazetteer-standard-report.xsd and <footprint-query> in gazetteer-query.xsd)
• Dublin Core
  (see DCMI Point and DCMI Box encoding schemes)
• OpenGIS Simple Features Specification for SQL
  (see §2.1, "Geometry Object Model," p. 2-1, and §3.2.5, "SQL Textual Representation of Geometry," p. 3-11)
• IBM Informix Geodetic DataBlade Module
  (see §3, "Geodetic Data Types," p. 3-1)
• MapInfo SpatialWare for SQL Server
  (see §8, "Constructing Geometry," p. 62)
• PostgreSQL
  (see Geometric Types)
• OpenGIS Web Feature Service Implementation Specification
  (see §13.3.3, "Bounding box," p. 61)
• OpenGIS Web Map Service
  (see §6.7.4, "Bounding boxes," p. 11, and §7.2.4.6.8, "BoundingBox," p. 20)
• GCMD Directory Interchange Format (DIF)
  (see Spatial Coverage)

(A number of additional geometry languages are derived from one or more of the above.) A standard geometry language would facilitate interoperability across different systems, particularly among consumers of geographic regions such as renderers and spatial indexers.

From the perspective of distributed geospatial digital libraries and distributed gazetteer services, which use geometry only for the limited purposes of representing object footprints and query regions and performing spatial comparisons between the two, a geometry language must satisfy three requirements:

1. The language must support enough possible shapes—and complex enough shapes—so that spatial matching over those shapes yields acceptable search precision. For gazetteers a sufficient set of shapes is not known, but necessary shapes include points for point features such as water wells, polylines for linear features such as rivers, and at least simple polygons for areal features.
2. The spatial reference system (SRS) in which shapes are defined (i.e., the Earth datum and coordinate system) must not be mandated by the language, but must be declarable in a standard way. Mandating a particular SRS forces language users to translate SRSs, which can be mathematically complex and can introduce unintended consequences such as formation of aggregate shapes.
3. The language must provide a lingua franca that virtually all geometry producers and consumers can operate on; in practice, due to simplicity of implementation, ease of mappability, and general widespread support, the lingua franca is latitude/longitude-aligned minimum bounding rectangles, or bounding boxes for short.
   1. Notwithstanding requirement 2 above, to support interoperability, bounding boxes must be defined in a standard SRS, e.g., WGS84 latitude/longitude coordinates. (It is reasonably easy to compute such bounding boxes from commonly-used cylindrical and polar projections.)
   2. In principle, bounding boxes are deterministically computable from primary shapes; nevertheless, bounding boxes must explicitly accompany all primary shapes in instance documents. To fail in this regard is to place the burden of computing bounding boxes on the very geometry consumers that are incapable of doing so: those that rely on bounding boxes because they're incapable of operating on more complex shapes.
   3. Bounding boxes must be defined in a manner that supports geodetic continuity, that is, in a manner that recognizes that the Earth is, topologically, a sphere. In particular, there must be no discontinuity that bounding boxes are not allowed to cross such as, in many geometry languages, the ±180° meridian.

The Open GIS Consortium's Geography Markup Language (GML), version 3.0, is one well-known attempt to define a standard geometry langauge. It is a comprehensive specification having many desirable characteristics, but it suffers from two defects that are shared by many of the aforementioned geometry languages. First, in balancing the concerns of consumers of the language, who generally prefer uniformity and simplicity, versus producers, who generally prefer expressiveness and flexibility, GML weighs heavily in favor of producers. It defines many, many possible shapes and shape-related options. The effect of this imbalance is that, in practice, consumers can not and do not accept but an idiosyncratic fraction of the entire GML language. The second defect is that GML does not meet any of the conditions of requirement 3 above.

The XML schema below represents a first effort at defining a geometry language that addresses these concerns. The language is a profile of GML, that is, a subset and logical restriction of GML such that any instance document that adheres to the language below also adheres to GML and can be interpreted by any GML consumer.

This deliberately simple geometry language supports just three possible shapes: points, polylines ("linestrings" in GML parlance), and simple (i.e., self-intersection-free and hole-free) polygons. Each shape is represented in the language by both an XML schema type (e.g., PolygonType) and an XML element (e.g., <Polygon>). However, the intention of the language is that only schema type AbstractFeatureType be referenced by application schemas; this usage forces a bounding box to be associated with every shape in instance documents. SRSs can be declared using the srsName attribute.

The above geometry language, expressed as a profile of GML, has a number of nice properties, not the least of which is that it weeds out 99% of the 600-plus-page GML specification. However, there are a number of serious deficiencies which are still unresolved:

• To satisfy requirement 3(i), the bounding box SRS must be standardized to, for example, WGS84 latitude/longitude coordinates. If the above language were an independent specification, such a requirement could be stated as part of the specification itself; an explicit declaration of the SRS need not be present in instance documents or even in the schema. But to avoid ambiguity as a profile of GML, all SRSs must be made explicit, and GML makes this possible by allowing an srsName attribute to be placed on the <Envelope> element. Unfortunately, at the time of this work, there appears to be no standard means of referring to SRSs.
• In GML, an <Envelope> element "defines an extent using a pair of positions defining opposite corners," that is, using a pair of minimum and maximum coordinate values. A consequence of being defined this way, as opposed to being defined in terms of explicitly-labeled east and west boundaries, is that it is not possible to describe a bounding box that crosses the ±180° meridian (or other discontinuity).
  If east/west bounding coordinates are mapped to minimum/maximum coordinates according to their values, then a bounding box such as Russia's will be misinterpreted (its east bounding coordinate, being less than its west, will be considered the minimum coordinate value), with the result that the GML envelope will describe the longitudinal complement of the desired bounding box. Always mapping the west (east) bounding coordinate to the minimum (maximum) coordinate value, even when west is numerically greater than east, would solve the problem (this is effectively equivalent to explicitly labeling the east and west boundaries), but the GML specification gives no indication that this is admissible or that SRSs may employ such modular arithmetic.
  It seems that the only unambiguous and correct method of encoding a bounding box that crosses the ±180° meridian is to convert the bounding box to a whole-world band. But this loss of shape fidelity results in many false positives by spatial search engines and is unacceptable.
• The language is both clumsy and misleading. It is clumsy because, to satisfy requirement 3(ii), application schemas that use the language must restrict their use to the AbstractFeatureType element type. Thus, instead of being able to say

  <element name="my-element" type="gml:PolygonType"/>

  the application schema must say

  <element name="my-element">
  <complexType>
    <complexContent>
      <extension base="gml:AbstractFeatureType"/>
    </complexContent>
  </complexType>
</element>

  But notice in the above that the ability has been lost to restrict the possible shapes <my-element> can take on to, say, polygons. The geometry language is further misleading because declarations such as PolygonType and <Polygon> are publicly visible, and application schemas will naturally assume that they can be directly referenced. An alternative approach would be to abandon AbstractFeatureType altogether, and use GML's <metaDataProperty> element for storing associated bounding boxes. In this approach, an application could say

  <element name="my-element" type="gml:PolygonType"/>

  and an instance document would look like

  <my-element>
  <gml:metaDataProperty>
    <gml:GenericMetaData>
      <gml:boundedBy>
        <gml:Envelope>
          <gml:coordinates>...</gml:coordinates>
        </gml:Envelope>
      </gml:boundedBy>
    </gml:GenericMetaData>
  </gml:metaDataProperty>
  <gml:exterior>
    ...
  </gml:exterior>
</my-element>

• Whether the language should support aggregate shapes (i.e., sets of disjoint shapes treated as first-order shapes)—and if so, which kinds—is an open question. On the one hand, aggregate shapes are desirable because they can offer vastly greater fidelity to true region shapes: consider the footprint of the United States described as an aggregate of three shapes (contiguous 48 states; Alaska; Hawaii) versus as a convex hull or bounding box of those shapes. On the other hand, aggregate shapes bring concomitantly large increases in interface and implementation complexity. Then again, if the language were to support aggregates, consumers would always have the option of falling back to bounding boxes.

Finally, below is an extension to the above geometry language that adds a disk shape (defined by center and radius) and several convenience declarations. As an extension, it is necessarily incompatible with GML.