I’m spending a couple of days in Chicago and wanted to visit a couple of the Festival of Maps exhibits. However, the only interface, as I mentioned before, is their flash map. Well, I wrote a small script to pull the information from their “printer-friendly” pages and generated this very useful Chicago Festival of Maps KML.

It’s also available via Mapufacture if you want to embed the map in your blog, get the GeoRSS, or mix in with another map you may have for say, other events and sights in Chicago.

I imported the KML file into my GPS receiver - which is pretty cool, and Mapufacture Mobile lets me use my N95 to find nearby locations. The original KML even has the address and phone number as KML elements, although no KML parser I’ve run across makes us of that info… yet. The iPhone Maps application loads ‘most’ of the markers, but doesn’t pull out the phoneNumber elements either.

Unfortunately, neither MGMaps (using OpenStreetMap tiles) nor GoogleMaps Mobile let me pull in KML - MGMaps complains and GoogleMaps Mobile just doesn’t have that bit of functionality. Perhaps they’re both waiting for OGC-KML ‘Mobile Profile’

Of course, a Dash would be a really good fit for this KML as well.

Today Google gave a couple of presentations on the current state of KML to the OGC Technical Committee meeting in Boulder, Colorado. The purpose of these particular presentations were to put forth KML2.2 as an OGC best practices. KML still belongs to Google, but is in the process of moving to belong to the OGC and therefore be an open standard.

The big ‘announcement’ was that Google will be releasing an open-source KML library in C++ that implements and tracks the standard as it progresses. By providing a reference library it allows developers to more easily keep up to date with KML without having to maintain their own library and track standards changes.

Assumedly bindings could be written to make use of libkml in other languages like Ruby or Python.

This is smart for Google, and any publisher/consumer, as it helps ensure that clients and servers are properly using KML and there aren’t various mixed versions beings published.

The library is expected to be available the first quarter of 2008 - and available under an as yet to be determined open-source license.

As I mentioned previously - I’m continuing the KML 3 discussion and blog posts to the Mapufacture blog starting with KML Module: Services. Very soon Mapufacture will start implementing some of the proposed changes as a testbed for trying out the new KML formats and capabilities. When it’s available, I’ll blog about how to start playing with it.

So if you want to continue playing along, track on over to the Mapufacture blog, or just toss the RSS or Atom feed into your reader and you’ll probably not notice the difference.

Wondering where all the action is in the updating of KML to 2.x/3? You can easily follow along or join the conversation using these very simple methods:

• Subscribe to del.icio.us, technorati, or your other aggregator of choice using the tag ‘ogckml’
• If you don’t want to clog your RSS Reader, then just check out the OGC Network KML aggregator that is already collecting all these links
• Tag your own blog posts or bookmarks to demos, stories, posts, or ideas using ‘ogckml’
• Join the #kml IRC channel on irc.freenode.net. IRC - it’s really cool (again)
• Join the GeoWeb REST mailing list/group for discussion on KML, and building a RESTful GeoWeb

Also - I’ll be moving my particular commentary over to the Mapufacture Blog, since that’s the company that I’m actually participating as a member of, and also where we’ll be implementing the new specs. My next posts will discuss using KML to link to external services such as OpenSearch-Geo, WFS, WMS, and more.

Continuing my series on the OGC KML 3 kick-off, lets talk a little bit about Metadata.

To date, metadata in KML has been somewhat confusing, ill-defined, and just kind of “wishy-washy”. This is the effect of several causes. First, KML is ‘lightweight’ and has been used by many mappers that haven’t had an interest in adding richer information to their pretty maps - yet. This is changing, as the concept of mapping, geography, and information is becoming easier to do and the concept more clear, more users are looking for how to include extra information about their geodata.

Another problem is the term Metadata, which has different meanings in different spheres. In GIS, Metadata are the supporting information that describe the data set: when it was created, who did the collecting, how complete is it, what are the license terms, keywords, coverage, and so on. The Federal Geographic Data Committee (FGDC) gives definition. For an example, check out the Baton Rouge GIS Metadata for Lots, 2004, East Baton Rouge Parish, Louisiana.

By contrast, programmers and general users have learned to refer to Metadata that is more generically “data about data”. This typically means just extra information that goes with the data, instead of primarily about the data. Examples include categories, tags, number of lanes for road, building type, and so on. GIS practitioners refer to these as attributes instead of metadata.

Anyways, the result has been that people often just become confused when talking with one another because of a different vocabulary. In the end, everyone just wants to be able to describe their data and add more information to it than just the strict geometry. See what the Dublin Core Metadata Initiative has done for HTML and RSS.

What’s the current situation?

Many developers have started pushing the envelope of what is possible in KML, and more directly, what Google Earth supports natively. Mano Marks at the Google Developer Knowledge Database provided a good document on how to possibly use XML in the Metadata tag.

Chris at FortiusOne has been blogging a lot about the how it is currently possible to use Metadata in KML 2.1 for thematic mapping. Jason Birch has found some really intriguing uses of the Schema tags that Google Earth actually uses for styling balloons.

Getting back to KML 3 and the OGC Technical Committee, one thing that seems difficult about the current KML Schema and Metadata support is that it allows (requires) users to define and use their own tags, or elements. Using Jason Birch’s example, he’s defined a schema for newts:

<Newt>
   <name>Sammy G</name>
   <styleUrl>http://www.jasonbirch.com/files/kml_schema_style.kml#newt_style</styleUrl>
   <Point>
     <coordinates>1.75,1.75,0</coordinates>
   </Point>
   <newt_id>36</newt_id>
   <newt_breed>Common Orange Slitherer</newt_breed>
   <newt_slime_factor>7.2</newt_slime_factor>
   <newt_tail_length>6</newt_tail_length>
 </Newt>

This is really powerful, but what this now requires is that any KML client or library that wishes to support metadata now has to delve into some fairly complex XML creation and parsing. The <newt/> was created on the fly in the schema definition, which the client will have to parse and then use to parse the rest of the document to extract any information at all. A client couldn’t simply say “I don’t understand Metadata” and still successfully get the geometry out of the KML document.

This is especially important using the concept of modules that allow KML implementations to only include pertinent areas of functionality. If a mobile phone client want to display markers, but isn’t going to use Metadata it shouldn’t be required to implement the complex Schema parsing just to get at the markers.

Don’t remove my schema tags!

I personally have heard this a couple of times, and fear not, we’re not talking about doing away with Metadata or ’schema tags’. Instead, we’re considering just simplifying how they’re used. Primarily, we want to support lightweight addition of additional data without requiring you to use that data to understand the underlying geometry.

To illustrate, check out the example document at the OGC Network. Returning to Jason’s example, we’re going to define the Schema (to provide for more ’strictness’ to make XML-heads happy)

<Schema name="newt_data">
    <SimpleField type="int" name="newt_id"></SimpleField>
    <SimpleField type="string" name="newt_breed"></SimpleField>
    <SimpleField type="decimal" name="newt_slime_factor"></SimpleField>
    <SimpleField type="decimal" name="newt_tail_length"></SimpleField>
</Schema>

And then our actual placemark can use these attributes:

<Placemark class="newt" id="sammyg_newt">
  <name>Sammy G</name>
  <gml:Point>
    <gml:pos>1.75 1.75 0</gml:pos>
  </gml:Point>
  <link type="application/html" href="http://mynewtfarm.com/list#sammyg_newt"/>
  <Metadata class="newt_data">
    <property name="newt_id">36</property>
    <property name="newt_breed">Common Orange Slitherer</property>
    <property name="newt_slime_factor">7.2</property>
    <property name="newt_tail_length">6</property>
  </Metadata>
</Placemark>

What this now allows is for someone to easily add metadata, or attributes, without requiring a client to use it to just show a marker where ‘Sammy’ currently is located. In addition, the metadata could be more complex than just a simple string or numeric value if required.

But I want my real Metadata

While KML is a lightweight geospatial interchange format, it shouldn’t restrict users from referencing more formal data formats as necessary. In fact, it would be straight-forward to publish a simple KML file referencing all of your more complex geodata and then let users choose which data they want to investigate.

Using the <atom:link>, we can easily reference a related document that includes a full GML Metadata description.

<Placemark id="newt_10">
  <atom:link rel="related" type="application/xml+gml" href="http://mygisserver.com/lizards/newt/10"/>
  <Point><pos>43 82</pos></Point>
</Placemark>

(Note: application/xml+gml isn’t a valid MIME type that I’m aware of, I’m just using it as an example of how you can indicate to an application what is at the endpoint)

This way, a developer can include lightweight attributes, or Metadata, but also reference richer Metadata as necessary.

We still have to look at how this affects styling - we want to allow for templating marker descriptions (BalloonStyle) and also possibly apply styling based on values of the Metadata. If you have some suggestions - we’d love to hear them.