17 May 2007 - From GML 1.0 onwards - a brief history

GML was created to enable geospatial transactions on the web - that is the ability to change the content of a geospatial database in a vendor independent manner. While GML does enable traditional file based exchange of data (as in Spatial ETL) this was NOT the objective.

As many have pointed out, GML set out on a very difficult task, that of providing a means of representing real world phenomena in a manner that the could be shipped from place to place on the Internet - in effect from one database to another. As has also been pointed out the geometry encoding was one of the easier parts of the task.

In the development of GML 1.0 we were faced with a very clear problem. Users of geospatial information are very diverse and each community has its own vocabulary for talking about the world. While we can enforce specific primitives (geometry, time, topology etc) it seems presumptuous to assume that we could invent a universal schema that would allow the capture of anything under the sun. The first profile of GML 1.0 (GML 1.1) tried to do that. The difficulty with this approach were two fold namely 1. We created a schema language that would be used only in the GIS community and 2. We bound schema and instance in the same document. Neither of these seemed very attractive. As a result GML 1.2 and 1.3 profiles were created that allowed for user defined vocabularies, the first (1.2) using DTD and the second (1.3) using RDF/S.

As things developed, support for RDF/S waned and we switched to an implementation in XML Schema - while preserving the same structure as in GML 1.3 - namely things like properties are children of objects, that properties could be both object attributes and relationships, and that properties could be remote valued. All of those ideas remained in GML 2.0 via XML Schema and all of them remain in GML today.

So the change from GML 1.0 to GML 2.0 was much less abrupt than has been suggested - and we have by no means thrown away the roots in RDF.

The current GML specification (v3.2) uses the exact same model as GML 2.0 (which is essentially the same as GML 1.3) - and it allows for the creation of user vocabularies - which are either common to a pair of users or to an entire community.

To make this bit of history more concrete compare the following XML snippets, the first in GML 1.0 and the second in GML 2 and the third in GML 3.

<Feature typeName="Road">
    <description>M11</description>
    <property typeName="classification">motorway</property>
    <property typeName="number" type="integer">11</property>
    <geometricProperty typeName="linearGeometry">
        <LineString srsName="EPSG:4326">
            <coordinates>0.0,100.0 100.0,0.0</coordinates>
        </LineString>
    </geometricProperty>
</Feature>

Note that we cannot tell what is meant by the type names. Where is integer defined? or Classification Scheme?

<abc:Road>
    <gml:description>M11</gml:description>
    <abc:classification>motorway</abc:classification>
    <abc:number>11</abc:number>
    <abc:centerLine>
        <gml:LineString srsName="EPSG:4326">
            <gml:coordinates>0.0,100.0 100.0,0.0</gml: coordinates>
        </gml:LineString>
    </abc:centerLine>
</abc:Road>

Sample Snippet from GML 2.1.2 (with application schema)

Since this depends on a separate schema we can both determine the exact meaning of all of the types and we can validate this instance against the schema.

In GML 3.0 not much changes …

<abc:Road>
    <gml:description>M11</gml:description>
    <abc:classification>motorway</abc:classification>
    <abc:number>11</abc:number>
    <abc:centerLine>
        <gml:LineString srsName="EPSG:4326">
            <gml:posList>0.0 100.0 100.0 0.0</gml: posList>
        </gml:LineString>
    </abc:centerLine>
</abc:Road>

Sample Snippet from GML 3.1.1 (with application schema)

Note that the instance is much the same, the only change being the expression of coordinates in the XML-visible posList rather than the more opaque coordinates.

Comments

No comments yet.