Print This Post

GeoWorld: Exploring Schema Constructs in KML

Issue Date: May – 2008

Building the GeoWeb by Ron Lake


Many languages, including Keyhole Markup Language (KML) and Geography Markup Language (GML), use schema constructs to express a data model. "Building the GeoWeb" will explore the nature of these constructs as well as their role in each language to help researchers and application developers deploy these standards to their best advantage.

This first column will deal with KML, and a future column will tackle GML. To motivate and unify the discussion, I’ll employ a FlightLine object example that represents information about and associated with the path of a commercial aircraft. 

KML 2.2

Schemas in KML 2.2 are defined by the <Schema> element, which has the following syntax:

1
2
3
4
5
    <Schema name="string" id="ID">
      <SimpleField type="string" name="string">
        <displayName></displayName><!-- string -->
      </SimpleField>
    </Schema>

Therefore, I could define a FlightLine <Schema> that assumes all of the properties are of simple type (e.g., classification (commercial scheduled/commercial charter/private), airline, and departure and arrival cities) and write the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    <Schema name="FlightLine" id="p11">
      <SimpleField type="string" name="classification">
        <displayName></displayName>
      </SimpleField>
      <SimpleField type="string" name="operator">
        <displayName></displayName>
      </SimpleField>
      <SimpleField type="int" name="flightNumber">
        <displayName></displayName>
      </SimpleField>
      <SimpleField type="string" name="departsFrom">
        <displayName></displayName>
      </SimpleField>
      <SimpleField type="string" name="arrivesAt">
        <displayName></displayName>
      </SimpleField>
    </Schema>

This is consistent with KML’s objective to support the visualization of geographic data. But note two restrictions in this current schema construct:

1. No complex types.

2. No enumerated types defined by the schema builder (see "classification" in the example).

Placemarks

Now look at how this is used in a KML instance. The <Schema> element is the child of <Document>.

In many cases, this same Document would contain a related Placemark, but because I want to keep the definitions separate to explore the idea of a KML vocabulary, I’ll place the schema in a Document containing no Placemarks, as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    <kml xmlns="http://earth.google.com/kml/2.2">
      <Document id="FlightLineSchemaDef">
        <Schema name="FlightLine" id="FlightLine">
          <SimpleField type="string" name="classification">
            <displayName></displayName>
          </SimpleField>
          <SimpleField type="string" name="operator">
            <displayName></displayName>
          </SimpleField>
          <SimpleField type="int" name="flightNumber">
            <displayName></displayName>
          </SimpleField>
          <SimpleField type="string" name="departsFrom">
            <displayName></displayName>
          </SimpleField>
          <SimpleField type="string" name="arrivesAt">
            <displayName></displayName>
          </SimpleField>
        </Schema>
      </Document>
    </kml>

This file (document) then can be located on the Web, for example, at www.aviation.org/aviation.kml, referencing the contained <Schema> using www.aviation.org/aviation.kml#FlightLine. This can be done from any KML file that references the <Schema> using the <ExtendedData>|<SchemaData> construct.

For this, I can write something like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    <kml xmlns="http://earth.google.com/kml/2.2">
      <Placemark id="BA85">
        <name>Flight BA-85</name>
        <ExtendedData>
          <SchemaData schemaUrl="http://www.aviation.org/aviation.kml#FlightLine">
            <SimpleData name="classification">commercial airline</SimpleData>
            <SimpleData name="operator">British Airways</SimpleData>
            <SimpleData name="flightNumber">85</SimpleData>
            <SimpleData name="departsFrom">London</SimpleData>
            <SimpleData name="arrivesAt">Vancouver</SimpleData>
          </SchemaData>
        </ExtendedData>
        <LineString>
          <coordinates>0.1,51.5 -123.0261,49.3338</coordinates>
        </LineString>
      </Placemark>
    </kml>

The schema-defined information (ExtendedData) now is contained in a Placemark. But the following should be noted:


1. There’s no namespace assigned to the definitions—just a location for the schema. Moving the schema somewhere else could mean something different, or not—you can’t tell.

2. The role or meaning of the LineString in the FlightLine isn’t described. You don’t know whether it describes the path of the aircraft or a bounding limit on the flight zone. This could be improved by adding descriptive ID values (e.g., id = "flightPath", id = "flightLimitRight", id = "flightLimitLeft", etc.), but such items can’t be defined by the schema.

3. There’s no way to say that LineString belongs in the FlightLine definition, but Point or Polygon don’t belong. These aren’t part of the schema definition.

4. The coordinate reference system can’t be changed—there’s only the default coordinate reference system urn:x-ogp:def:geodetic-crs:EPSG:4326 with the latitude and longitude reversed relative to EPSG4326 (i.e., (long, lat) rather than (lat, long)).

5. There’s no way to add new geometries to KML to accommodate special curves such as Loxodromes or Geodesics.


External Schemas

The KML <ExtendedData> element also allows users to add content that isn’t part of KML. For example, the following KML file includes the above properties as child elements of <ExtendedData>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    <kml xmlns="http://earth.google.com/kml/2.2" xmlns:abc="http://www.aviation.org/">
      <Placemark id="BA85">
        <name>Flight BA-85</name>
        <ExtendedData>
          <abc:classification>commercial airline</abc:classification>
          <abc:operator>British Airways</abc:operator>
          <abc:flightNumber>85</abc:flightNumber>
          <abc:departsFrom>London</abc:departsFrom>
          <abc:arrivesAt>Vancouver</abc:arrivesAt>
        </ExtendedData>
        <LineString>
          <coordinates>0.1,51.5 -123.0261,49.3338</coordinates>
        </LineString>
      </Placemark>
    </kml>

 
But the content of <ExtendedData> isn’t KML nor defined by KML; it’s anything written in the namespace with prefix abc. KML doesn’t say anything about what’s to appear in the ExtendedData element, except that it’s XML and in a different namespace than KML.

"Place-Centric"

It should be apparent that KML provides flexible mechanisms for transporting data instances and rather limited ones for defining data models. This isn’t a criticism of KML, and it fits nicely into its role as the visualization language for Internet geography.

KML allows users to refer to external schema definitions (e.g., GML application schemas) and provides a restricted schema notion to describe the data associated with a visualization. KML is "place-centric" and allows users to associate data elements with a place. It would be wrong to think of KML as a data description language or talk of KML vocabularies.

Read the article on their website: GeoWorld.

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