Print This Post

GeoWorld: Exploring Schema Constructs in KML

Issue Date: August — 2008, Posted On: 9/1/2008

Building the GeoWeb by Ron Lake

This is Part II in a series of “Building the GeoWeb” columns comparing the schema constructs found in Keyhole Markup Language (KML) and Geography Markup Language (GML). In the first column (see “Exploring Schema Constructs in KML,” GeoWorld, May 2008, page 20), I introduced a reference example of an aircraft FlightLine and discussed its possible realization in KML. In this final installment, I’ll look at the same FlightLine, but in GML.

It should be noted that GML doesn’t contain a schema-defining mechanism within GML itself, but rather uses another schema language. At the present time (and for the foreseeable future), this is the W3C XML schema, but DTD and RDF schema were used for this purpose in GML 1.0. In the future, GML might be seen in Relax or some other schema language not yet defined.

Schemas play a much deeper role in GML than in KML. The following is a possible GML Application Schema for the FlightLine object introduced in the previous column:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  <schema targetNamespace="http://www.aviation.org" xmlns:abc="http://www.aviation.org"
   xmlns:gml="http://schemas.opengis.org/gml" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <element name="FlightLine" type="abc:FlightLineType" substitutionGroup="gml:_Feature"/>
    <complexType name="FlightLineType">
      <complexContent>
        <extension base="gml:AbstractFeatureType">
          <sequence>
            <element name="classification" type="abc:classificationType"/>
            <element name="operator" type="xs:string"/>
            <element name="flightNumber" type="xs:int"/>
            <element name="departsFrom" type="xs:string"/>
            <element name="arrivesAt" type="xs:string"/>
            <element name="flightPath" type="gml:CurvePropertyType"/>
            <element name="flightZoneRight" type="gml:CurvePropertyType" minOccurs="0"/>
            <element name="flightZoneLeft" type="gml:CurvePropertyType" minOccurs="0"/>
          </sequence>
        </extension>
      </complexContent>
    </complexType>
    <simpleType name="classificationType" base="xs:string">
      <enumeration value="commercial_scheduled"/>
      <enumeration value="commercial_charter"/>
      <enumeration value="private"/>
    </simpleType>
  </schema>

 

Such a schema definition could be referenced in KML (via ExtendedData) or otherwise support GML instances that would look like the following:

1
2
3
4
5
6
7
8
9
10
11
12
  <abc:FlightLine gml:id="BA85">
    <abc:classification>commercial scheduled</abc:classification>
    <abc:operator>British Airways</abc:operator>
    <abc:flightNumber>85</abc:flightNumber>
    <abc:departsFrom>London</abc:departsFrom>
    <abc:arrivesAt>Vancouver</abc:arrivesAt>
    <abc:flightPath>
      <gml:LineString srsName="urn:x-ogp:def:geodetic-crs:EPSG:4202">
        <gml:posList>51.5 0.1 49.3338 -123.0261</gml:posList>
      </gml:LineString>
    </abc:flightPath>
  </abc:FlightLine>

Note that in the GML definition:
• Everything is defined in a separate namespace
• FlightLine is an independent object (feature)
• LineString lives in a specific coordinate system
• The role (flightPath) of the LineString in relation to the FlightLine is specified in the schema
• An enumerated type is used to describe the FlightLine “classification”

Adding Complexity

This is, of course, a simple example, but what if it becomes more complex? Suppose you have a list of city airports, and you wish to replace the arrivesAt and departsFrom property values by the airports rather than the cities, and then describe these airports by their geodetic location.

In GML, the first step would be to define a new schema for Airports and related objects. Because this vocabulary might be controlled by another organization, another namespace is used. The GML schema might look like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
  <element name="Airport" type="def:AirportType" substitutionGroup="gml:_Feature"/>
  <complexType name="AirportType">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element name="code" type="def:airportCodes"/>
          <element name="operator" type="xs:string"/>
          <element name="city" type="xs:string"/>
          <element name="location" type="gml:PointPropertyType"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

The FlightLine schema now is changed to use reference pointers to the Airports, and a new “city” property is added. The departsFrom and arrivesAt property schemas now become:

1
2
3
4
  <element name="departsFrom" type="def:simpleReferenceType"/>
  <complexType name="simpleReferenceType">
    <attribute ref="xlink:href"/>
  </complexType>

An instance now looks like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
  <abc:FlightLine gml:id="BA85">
    <abc:classification>commercial scheduled</abc:classification>
    <abc:operator>British Airways</abc:operator>
    <abc:flightNumber>85</abc:flightNumber>
    <abc:departsFrom xlink:href="http://www.aviation.org/worldairports#LHR"/>
    <abc:arrivesAt xlink:href="http://www.aviation.org/worldairports#YVR"/>
    <abc:flightPath>
      <gml:LineString srsName="urn:x-ogp:def:geodetic-crs:EPSG:4202">
        <gml:posList> … coordinates … </gml:posList>
      </gml:LineString>
    </abc:flightPath>
  </abc:FlightLine>
  <def:Airport gml:id="LHR">
    <def:code>LHR</def:code>
    <def:operator>BAA</def:operator>
    <def:city>London</def:city>
    <def:location>
      <gml:Point srsName="urn:x-ogp:def:geodetic-crs:EPSG:4326">
        <gml:pos>51.487222 -0.466667</gml:pos>
      </gml:Point>
    </def:location>
  </def:Airport>
  <def:Airport gml:id="YVR">
    <def:code>LHR</def:code>
    <def:operator>Vancouver International Airport Authority</def:operator>
    <def:city>Vancouver</def:city>
    <def:location>
      <gml:Point srsName="urn:x-ogp:def:geodetic-crs:EPSG:4326">
        <gml:pos>49.193889 -123.184444</gml:pos>
      </gml:Point>
    </def:location>
  </def:Airport>

How would this be done in KML? A user would need to create Placemarks for the Airports as well as a new schema definition for Airport:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
  <Document>
    <Schema id="Airport">
      <SimpleField type="string" name="code"/>
      <SimpleField type="string" name="operator"/>
      <SimpleField type="string" name="city"/>
    </Schema>
  </Document>
  <Placemark id="YVR">
    <ExtendedData>
      <SchemaData schemaURL="http://www.aviation.org/airports.kml#Airport">
        <SimpleData type="code">YVR</SimpleData>
        <SimpleData type="operator">Vancouver Airport Authority</SimpleData>
        <SimpleData type="city">Vancouver</SimpleData>
      </SchemaData>
    </ExtendedData>
    <Point>
      <coordinates>-123.184444,49.193889</coordinates>
    </Point>
  </Placemark>

 

Note, however, that I removed the properties departsFrom and arrivesAt from the schema, because there’s no support in SimpleField for URLs. Furthermore, the link in NetworkLink is a URL, and one can expect that any KML consumer must dereference (fetch) the URL when seen—whether this makes sense or not.

It can’t be known from the schema for this ExtendedData, in this Placemark instance, that there’s a property arrivesAt nor departsFrom—these aren’t part of the Placemark’s definition. It should be clear that a user can’t talk about a FlightLine or Airport Placemark at all—although they may associate ExtendedData information with particular Placemark instances.

Representation and Presentation

In KML, users can’t create geographic objects as they can in GML, but they can use the schema construct to add user-defined attributes to objects for visualization in an Earth browser such as Google Earth.

Also note that in GML, one can define a library of data types that can be further extended using extension or composition, whereas KML only allows the user-defined data embedded in a KML document as a whole.

KML elements aren’t intended to be used in the content of user-defined elements. Most KML elements are required to appear in certain context; they’re not allowed to be used anywhere else.

Although KML types can’t be used to describe a user’s elements, they can have their own vocabularies (described by something other than KML) embedded in KML. Such embedded XML is usually ignored by the KML processor, with the exception of templates used mainly for documentation in balloons.

This discussion isn’t criticism of either language, but it reflects the different objectives of the two languages: GML is intended primarily for geographic data representation, and KML is intended for geographic data presentation.

Read the article on their website: GeoWorld.

Download the PDF file:  GeoWorld – Exploring Schema Constructs in KML August 2008.pdf