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 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 , 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.

There are many questions out there about how KML, GML, GeoRSS, and others differ from one another and how they work together. The primary strength of KML is the ability to simply style, or visualize, geographic information. By comparison GeoRSS doesn’t support any styling, and GML uses SLD to add styling to the feature markup.

Sidebar: W[F,M]S

This also leads to interesting discussions about how KML fits into the OGC services. Two of the prevalent OGC OWS, WFS (Web Feature Service) and WMS (Web Mapping Service) differ in that WFS is supposed to supply just features, and WMS supplies visualizations. Typically, this has meant WMS supplies raster images – though at least one format, SVG, is still just ‘text’. Therefore, one may assume KML should be part of WFS – but instead it is being made part of WMS.

Personally, I think this distinction is tedious, and serves to confuse users. I understand that separating the two services makes it easier for developers, but this is an inverted approach and demonstrates that OGC standards are derived by developers and not many users.

Back to styling

Anyways, it is still apparent that styling is a key element of KML, and one that is desired to be solidified and strengthened in the future. There have been comments that while styling is useful, KML currently mingles features and style too closely. For example, to style a line in KML, you first define the style in your KML document head, but then have to explicitly reference that style from within the Placemark element.

KML does allow you to refer to another KML document for the style – so you could have a mapstyles.kml that you reference from your KML Placemarks. However you are fairly limited in what you can do with this styling and have to explicitly define it. Additionally, you can’t give cascading styling to your KML entities that might be grouped into Folders.

Therefore, the committee discussed looking at existing styling formats for ideas and possible use in KML. SLD (Styled Layer Descriptor) is the OGC standard for specifying the visualization and styling of features from OGC web services.

However, the thread is “Agile Geography”, and SLD+GML is not really consumable by the types of developers that are interested in KML. Another option that was discussed is adopting CSS3.

CSS offers a lot of very intriguing features that would benefit KML. The simple effect would be separating styling from the geometry. In KML 2.1, any Feature (abstract element for other KML elements) can have an id. Subsequently, KML3 could add a class attribute, like in HTML, that could loosely be used to give some categorization of the Feature (road, highway, animal, newt). Then, the CSS could reference these id, class, or even use selectors to apply styling to elements.

By way of example. Note, this is completely rough and is only an example of what might be possible with some sort of cascading-styling

roadstyles.kss

<kstyle>
    Placemark {
      font-size: 8px;
    }
    #roads {
      color: black;
      width: 2px;
    }
    .primary {
        color: blue;
        width: 4px;
    }
    .secondary {
      width: 1px;
    }
    Placemark[num_lanes=2] {
      width: 2px;
    }
</kstyle>

virginia_roads.kml

<kml>
  <styleUrl>http://mygeosite.com/roadstyles.kss</styleUrl>
  <Folder id="roads">
    <atom:author>
        <atom:name>VDOT</atom:name>
    </atom:author>
    <Placemark class="primary" id="I66">
      <gml:Point>
        <gml:pos>42, -83, 100</gml:pos>
      </gml:Point>
    </Placemark>
  </Folder>
</kml>

With my “web developer” hat, this seems really attractive. Using a language and markup I already know and have tools for. It also provides some really powerful capabilities for applying hierarchical styling, both through selectors, and also the ability to apply multiple stylesheets to a KML document. So there could be a stylesheet that is linked to by the document for roads, another for POI’s, and then I could apply my own default in my KML client application.

You may notice the Placemark[num_lanes=2]. CSS3 supports applying styles based on evaluating attributes of elements. So a CSS like this may allow you to easily create thematic maps based on the value of the metadata. However, we still need to figure out exactly how that would mesh with the Metadata module concept (coming up in future blog post).

There is still work to do evaluating the existing KML as well as SLD and some sort of CSS. Now would be a good time to speak up with your thoughts and use cases for how you would to style your data.