Menu

Mapping and Markup, Part 1

November 24, 2004

John E. Simpson

One frustration you can still hear vented when someone first comes to XML takes the form, "Yeah, but what about the real world?" or "Show me some real-world examples!" What the speaker often means by this is that he or she simply needs to see XML in action, in some form--some application--whose import is immediately obvious.

Few "real-world examples" can be realer than--well, than the real world. Most cultures have some convention for depicting geographic features in the form of maps. And all maps have one thing in common: they depict a hierarchy of information. Earth is made up of continents and oceans; each continent itself consists of smaller land masses (from the artificial, such as countries, to the natural--islands) and bodies of water; within each country you'll find sub-units (states or provinces); and so on.

To any reader of this column, the phrase "hierarchy of information" always suggests XML. In this case, a simple XML document might look something like the following:

<earth>
  <continent name="Antarctica"/>
  <continent name="Asia">
    <country name="China">
      <regions type="province">
        <region name="Anhui">
          [etc.]
        </region>
      </regions>
    </country>
    [etc.]
  </continent>
  [etc.]
</earth>

But while this hierarchy would ultimately grow to gigantic size, it wouldn't ever show you China or anyplace else.

The document is information-rich, all right, but you couldn't hand it to a fourth-grader, say, and expect that he'd intuitively know what it is. Ideally, what he'd see instead would be a fully-annotated map of the world. Let him use some kind of pointing device to narrow the field of vision down to areas or features of interest, to zoom in or out to varying levels of detail, and ultimately to display some or all of the information in the above document which pertains to the selected feature, at the selected scale.

Wouldn't that be real-world enough for just about anybody? And wouldn't it be cool?

GML: Real-world details in an XML document

Geography Markup Language (GML), now at Version 3.1, is a specification of the Open Geospatial Consortium (OGC). (This standards body was formerly known as the Open GIS Consortium--GIS being an acronym for Geographic Information Systems.) If you're used to W3C-sized specs--even behemoths like XML Schema--you'd better sit down before glancing at the GML "Recommendation Paper"; it's a monster, weighing in at over 600 PDF-formatted pages, supplemented by nearly three dozen separate schemas.

Why so big? Isn't describing a geographic feature pretty straightforward?

Well, no. While a human with a certain amount of native or other resources might recognize an address like "1005 Gravenstein Highway North, Sebastopol, CA 95472, USA" as an unambiguous "place" (the corporate headquarters of O'Reilly Media), it's really not a very useful description to someone unfamiliar with the area. (Given just that address, I'm not sure I myself could find my way there, even on a reasonably detailed map.)

A truly useful geographic "description" of the O'Reilly headquarters would include, at a minimum, X and Y coordinates on some universally accepted grid. But that's just a point in two-dimensional space, and very few addresses are really captured by a single point. Rather, what you'd need would be a polygon of points and the line segments joining them, and you'd need to provide some further context for that polygon among a myriad of others: the building and its grounds, parking lots, the road network, surrounding countryside, and ultimately the planet itself. Each of those polygons would have different geographic features as well. For instance, the area evoked by the pleasant phrase "surrounding countryside" needs not just X and Y coordinates but Z coordinates as well--comprising a potential infinity of grades and other topographic properties. Since GIS applications typically are used for such things as locating utilities connections beneath streets, a comprehensive XML-based GIS system must be able to capture such artificial details as well.

Note: The continent of Antarctica in the non-GML document above is accounted for in an empty element because the continent contains no countries. In the real world, though, describing the geography of Antarctica--by most measures the emptiest place in the world--could require an infinity of data. Defining the jagged reality of the continent's coastline in sufficient detail to navigate or explore it would take a "document" as big as the ice sheet itself.

Layered atop its capacity for GIS-type description, though, GML also includes an ambitious collection of non-GML XML technologies. For instance, it provides for hyperlinking (via XLink) geographic features to external, related resources. Among the supplementary schemas are two related to SMIL (Synchronized Multimedia Integration Language), enabling animation and other special effects to be applied to the presentation of the base geographic data. A couple of schemas allow you to add a temporal dimension to the geographic description of an object--permitting you, for example, to plot the track of an airplane as it flies over a country (that is, as its geographic coordinates change over time).

Core GML

At a minimum, any geographic or mapping standard must be able to describe the geometry of a given feature or object. That is, to map (say) a neighborhood of homes, the standard must be able to identify the start and end points of each street, the boundaries of each property, the slope of the terrain at any given point, and so on. At this level of minimum detail, none of the objects depicted--none of the points, lines, or polygons--have anything like a name or address. What you see isn't a map; it's simply an unlabeled (albeit structured) diagram.

Such basic geometric elements are provided for among the GML schemas, of course. For instance, among the basic building blocks of a GML-based diagram you might find numerous gml:Point, gml:_Curve, and gml:Polygon elements. Polygons, singly or in combination, might be assembled into gml:Surface elements. A gml:LineString element defines a group of one or more line segments, each identified with a pair of points (a start and an end point, each consisting of at least an X and Y coordinate), and so on.

In order to associate the unadorned diagram with the real-world feature(s) it represents, you'd also need to identify units of measure. For instance, given a line segment identified by the X,Y coordinate pairs 1,0 and 1,2, all we can say is that the line is vertical for a length of one unit. Does this line represent some feature which is one meter long? One kilometer? One foot?

What you've got so far isn't really a mapping system. It's the underpinnings of a vector-based drawing system. Indeed, basic SVG gives you as much, and if that's all you need, then you don't need to cloud your understanding with an additional standard beyond SVG.

Where a standard for describing geography truly starts to advance beyond one for describing geometry is in the use of coordinate reference systems. These convert the drawing to a true representation of terrain and human-made features. Do you want to use simple latitude and longitude to position the line in geographic space? Or, for compatibility with one or another local standard, do you want to use something like the British National Grid (BNG), developed by Britain's Ordnance Survey, World Geographic Reference System (GEOREF), or one of the North American Datum (NAD) systems?

Note: A simple overview of various coordinate reference systems is available online at the Geographer's Craft Project of the Department of Geography at the University of Colorado. While you're at it, be sure to look through some of the related material at the site, including overviews of map projections and GPS data; at the least, they'll give you some insight into why GML is such a large spec, even without the add-ons like XLink and SMIL.

With a few extra layerings of elements and attributes, you're now ready to create a real map--one in which instances of feature classes (such as roads and property parcels) are colored differently depending on their types (highways vs. lanes; public vs. private land); one in which features are labeled for human consumption and perhaps linked to more detailed text descriptions; one in which the diagram can be interacted with by panning, zooming, and converting to alternate media types (such as print vs. screen).

In Part 2 of this column, next month, we'll look more deeply into some of these more advanced features of GML. I'll introduce you to one of GML's principal authors--Ron Lake of Galdos Systems, who is to GML roughly what Tim Bray is to XML--and we'll take a brief look at some of the processing applications which have sprung up around the standard.