KML Schema Rides Again

Posted on by

I just read the news about the new ExtendedData tag in KML 2.2. With one mighty stroke of the pen, Google has saved the Schema tag, and my sanity along with it!

What does it mean? Basically: KML can still act as a self-contained data exchange format, while getting rid of the nasty part of the original <Schema> tag that defined new elements on the fly.

To illustrate the changes, I’ll take you through my previous example of Sammy G Newt. Here he is in glorious colour under the new ExtendedData system:

Sammy in the sky with diamonds...

The first part of this new system is defining the schema; you can see how to do this here:

  <Schema name="newt" id="newt_schema">     
    <SimpleField name="id" type="int">
      <displayName><![CDATA[<b>ID</b>:]]></displayName>     
    </SimpleField>
    <SimpleField name="breed" type="string">
      <displayName><![CDATA[<b>Breed</b>:]]></displayName>     
    </SimpleField>
    <SimpleField name="slime_factor" type="double">
      <displayName><![CDATA[<b>Slime Factor</b>:]]></displayName>     
    </SimpleField>
    <SimpleField name="tail_length" type="int">
      <displayName><![CDATA[<b>Tail Length</b>:]]></displayName>     
    </SimpleField>
    <SimpleField name="relative_id" type="string" />
  </Schema>

Looks pretty basic, right? Not much has changed in the Schema tag, except that has name and id attributes, and there is now an optional displayName element for each field.

OK, now that you’ve got the schema, you want to create a BalloonStyle that takes advantage of that schema. Here’s mine:

   <BalloonStyle>
    <bgColor>ffffaa90</bgColor>
    <textColor>ffffffff</textColor>
    <text><![CDATA[
    <h1>$[name]</h1>
    <table>
      <tr>
        <td>$[newt/breed/displayName]</td>
        <td>$[newt/breed]</td>
      </tr>
      <tr>
        <td>$[newt/tail_length/displayName]</td>
        <td>$[newt/tail_length]</td>
      </tr>
      <tr>
        <td>$[newt/slime_factor/displayName]</td>
        <td>$[newt/slime_factor]</td>
      </tr>
      <tr>
       <td colspan="2"><img src="http://www.jasonbirch.com/files/jason_small.jpg?id=$[newt/id]" /></td>
      </tr>
    </table>
    <a href="#$[newt/relative_id];balloonFlyto">Please visit my Sister!</a>
    ]]></text>
   </BalloonStyle>

Can I hear the ah-ha’s?

There are a couple neat things here. First, it’s pretty obvious that if you want the data, you use the format $[nodeName/fieldName], and if you want the display name you use $[nodeName/fieldName/displayName]. Look close at the <a> tag though… I am using an identifier stored in the extended data area to link to a different record in the same KML file, using its ID. This will be great for “previous” and “next” applications among other things. This could just as easily have been used to point to a different Placemark within a remote KML file.

Now that we have a schema and a style, we can create some some content that references these:

  <Placemark id="sammyg">
   <name>Sammy G</name>
   <styleUrl>#newt_style_boy</styleUrl>
   <ExtendedData>
    <SchemaData schemaUrl="#newt_schema">
     <SimpleData name="id">36</SimpleData>
     <SimpleData name="breed">Common Orange Slitherer</SimpleData>
     <SimpleData name="slime_factor">7.2</SimpleData>
     <SimpleData name="tail_length">6</SimpleData>
     <SimpleData name="relative_id">phyllisk</SimpleData>
    </SchemaData>
   </ExtendedData>
   <Point>
    <coordinates>1.75,1.75,0</coordinates>
   </Point>
  </Placemark>

So, what’s special about this? Two things. First, I didn’t magically create any new KML tags on the fly. Second, you can see that I am referencing both the style and the schema by URL. This means that you can either store all of your schema, markup, and code in one file, or you can break them out into as many individual files as you would like. You can have a look at my completed example here:

One File:

Three files:

Anyway, this last-minute addition to KML 2.2 has made me pretty happy. If you have any questions or comments about it, be sure to chime in on the official thread.

-J

P.S. Another thing that I noticed in perusing the documentation is the ability to use atom tags to link from a KML entity back to its web representation. This is important because it adds another vector for Google to use when assigning relevance to KML files in spatial search. I’m not an AtomPub expert, but I would imagine that it could also be used to allow a smart client to update features on the fly?

4 thoughts on “KML Schema Rides Again”

  2. Thanks for the confirmation Sean. Amazing that anyone made it through to the end of one of my rambles :)

    I should have mentioned that this model looks structurally a lot like the one discussed for KML3 within the OGC, but with some refinements:

    http://highearthorbit.com/kml-3-kick-off-module-metadata/

    Also, I don’t think that you’d want to be creating placemarks without description tags in real life. The Balloon template is great for display in Google Earth but I’m thinking that the name and description will continue to be important for web spider indexing.

  4. Pingback: I Heart KML Schema! · Random Nodes: Jason Birch's geospatial ramblings