29 Jun 2007 - Where GML was right .. and wrong

In a recent blog (see http://cfis.savagexi.com/articles/2007/05/01/lost-in-abstraction-what-went-wrong-with-gml) Charlie Savage (ex Smallworld) argues that GML started out and then went wrong - became too abstract and too complex. I think there is some truth in that, although I think the truth is different than what Charlie suggests - that is there things that are complex and hard to do in GML, but they are NOT in my view the one's he alludes to.

Abstraction and Schemas

One of the earliest issues we considered in the development of GML (see http://www.galdosinc.com/archives/315 ) was whether or not to use a static schema or not to describe objects in the real world. If I want to describe a road or bridge or a lake - I will need to describe its shape of course - but also other characteristics of the object - maybe the number of lanes on the bridge, its type (suspension, pontoon etc) and so on. This is creating a model of what a bridge is. Doing this, as Charlie rightly notes, is a hard problem. I fully agree that at least at the outset, creating the geometry was the easy bit. Now the question is how should we go about this?

One approach is to use a Static Schema as in GML 1.1. This approach is also that of the <Schema> tag in KML, or even better in the language Obix . Now let's be clear - what we are doing is creating a schema language full stop. We are specifying kinds of objects, their properties and the types of those properties and that more or less is what a schema language is for. So we had to ask ourselves, why should the geo world do that? If geo is to be mainstream it needs to use the schema tools of the wider IT world - web world whatever and not just make them up. Now, at that time of course we did not have 200 million GE users to think about - but even today I think this holds true, not because it cannot be done, but simply because much of the information connected with geo anything must come from somewhere else - from the non-geo world. So we experimented with our own schema language in GML 1.1.

For the reasons just mentioned, in GML 1.2 we looked at using DTD as the schema language, but that had an awful lot of constraints. In GML 1.3 we said ok let's use another schema language, namely RDFS. This was not without problems, but now we were somewhat plugged into a wider world. Then XML Schema started to mature and we elected to use it, as there were a lot more tools (both closed and open source) to create XML Schemas than there were for RDFS, and this is still true today.

IS this approach of creating a schema more abstract? I don't think so. It is just that the schema and instance can stand apart. But of course it is true that instead of saying directly in GML "this is how to encode a road" (which is what a schema language does) we say you do this by using XML Schema in this way.

GML and XML Schema

So if GML uses XML Schema to create its models of the world - does it constrain XML Schema in any way? The answer is YES. In GML, a model of something in the world, a road, a bridge) is encoded as an XML element with XML children. These children are the properties or characteristics of the road. A schema for such a thing can thus be VERY simple. For example I might describe a road (no geometry, no topology) by writing:

<?xml version="1.0" encoding="UTF-8"?>

<schema xmlns:app="http://www.galdosinc.com/app" xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.galdosinc.com/app" elementFormDefault="qualified">    <import namespace="http://www.opengis.net/gml" schemaLocation="gml-3.1.1.xsd"/>

  <import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlinks.xsd"/>

    <element name="Road" substitutionGroup="gml:_Feature">

      <complexType>

        <complexContent>

          <extension base="gml:AbstractFeatureType">

            <sequence>

              <element name="numberOfLanes" type="int" default="2"/>

              <element name="surfaceType" type="string"/>

              <element name="classification" type="string"/>

            </sequence>

          </extension>

        </complexContent>

      </complexType>

    </element>

  </schema> 

The only tricky bit here is the need to derive by extension from gml:AbstractFeatureType. This asserts that this thing is a feature, just like using the <Feature> tag in GML 1.1. The schema is otherwise easy to read and understand. This is the prototype for ALL GML Application Schemas. Everything is Objects and their properties. Here an Object is a Road and its properties are numberOfLanes, surfaceType, classification.

Using GML in KML

Having created our little schema (we need a registry of these - eh!) we can take a corresponding instance and put it inside a KML instance as follows:

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://earth.google.com/kml/2.1" xmlns:app="http://www.galdosinc.com/app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://earth.google.com/kml/2.1 http://code.google.com/apis/kml/schema/kml21.xsd http://www.galdosinc.com/app xsd/app.xsd">

  <Document>

    <name>My Road Collection</name>

      <open>1</open> 

      <Placemark>

        <name>Road01</name>

        <visibility>true</visibility>

        <description>This is my road.</description>

        <!– Instance Metadata elements–>

        <Metadata>

          <app:Road>

          <app:numberOfLanes>4</app:numberOfLanes>

          <app:surfaceType>asphalt</app:surfaceType>

          <app:classification>highway</app:classification>

        </app:Road>

      </Metadata>

      <LineString>

        <extrude>0</extrude>

        <tessellate>0</tessellate>

        <altitudeMode>absolute</altitudeMode>

        <coordinates>-122.92413711548,49.213392157629,116 -122.94602394104,49.201392074073,49 -122.94731140137,49.201448156003,54 -122.95349121094,49.198027041895,38 -122.9559803009,49.198083127641,38 -122.9591345787,49.199653502702,39 -122.96185970306,49.202261336839,38 -122.96550750732,49.203537162583,15 -122.96739578247,49.204013836283,19 -122.96730995178,49.204392368006,19 -122.96833992004,49.205317655576,27 -122.96840429306,49.205780292868,40 -122.97065734863,49.205822350589,37 -122.97522783279,49.205051286686,12 -122.97748088837,49.204490505387,5 -122.97844648361,49.203943737497,5 -122.98177242279,49.202121134201,6 -122.98722267151,49.199134723599,5 -122.99496889114,49.194900160957,4 -123.00020456314,49.198938427384,6 -123.00323009491,49.200004026042,4 -123.00453901291,49.200200318028,5 -123.01009654999,49.200172276363,6 -123.01258563995,49.200144234683,5 -123.01443099976,49.200452692293,8</coordinates>

      </LineString>

    </Placemark> 

  </Document>

</kml> 

Now surely that is not so painful. Remember you make the schema as complex as you need and NO MORE. GML can be restricted.

Referencing Things Elsewhere

Borrowing from RDF, GML has from earliest days allowed content to be referenced through href links (it uses the xlink specification to specify the attribute names and roles). Any GML property can be made to refer to remote content, as illustrated by the very simple example:

First we do things in-line:

<Road>

    <classification>highway</classification>

</Road>

Next the property classification is made remote:

<Road>

    <classification xlink:href = http://www.comgeo.org/roadclasses#access/>

</Road>

Now anything - geometry, topology etc. can be remoted in this fashion.

Intended for the Web?

Charlie makes the comment that GML was not intended for the Web, and in more, recent and somewhat conciliatory and reflective blog, that this is understandable since it was designed for bigger and harder problems like disaster management or homeland security.

To this I would ask the question .. "Why are the bigger problems NOT for the web" - the whole point at the OGC was tp push the Web to enable dealing with these bigger problems. Now, I know that Charlie means the Web in terms of the neo-geo fast evolution, collaborative development side of things. Here I would agree that we did not specifically design GML with this group of developers in mind, but by restricting (GML is a swiss army knife) these objectives can be met also - just look at GeoRSS GML if you want simple.

So yes - intended for the Web - but for both BIG and small problems.

I should also point out that his claim that WFS/GML live in a world only of thick clients with nary a browser in sight is simple false. Almost all demonstrations of these technologies only use browser based clients. Need I also point out that the marvelous Google Earth (and I think it is indeed marvelous!) is a "thick" application.

KML or GML

Charlie also says mind share is shifting to KML. Well I think there never was a mind share for GML in the sense of a mapping language. I think it is safe to say that KML and GML serve different roles - and I think we will see this complementary grow. It is not an either-or proposition. If you decide KML is a data language then you have lots of work to do - and you will end up in more or less the same place as GML.

Standards Kill Innovation

If we mean by innovation the creation of new things - I think this is a hard argument to make. Even Charlie now asserts that the OGC (and other processes) have led to a torrent of innovation. I would hasten to add that the sort of maps being demonstrated by Feature Server were created in GML 1. more than 7 years ago. The map below (generated using GML v1.2 and SVG) dates from 1999. This is the display from the browser.

GML/SVG Map from 1999

One might claim that the problem of OGC and other standards bodies is that there is "too much innovaton"

What is true and the OGC is working hard to deal with this issue - is that the innovation happens largely by OGC members - although the development of GeoRSS shows that there is a great deal of flexibility on this side as well. So pitch in and help change things - inside or outside - we are all wanting to move in the same direction. Come to the GeoWeb 2007 (see http://www.geoweb.org ) or write a comment at http://www.geowebblog.org or add your blog to the blog roll. Let's build the GeoWeb!!

Comments

No comments yet.