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.

The KML Core module includes the minimal subset of KML that would be expected for any implementation. Currently the elements of KML that would exist in Core include:

kml, Document, atom, Folder, Placemark, Link (and NetworkLink?), ScreenOverlay, TimeStamp, Geometry (see below)

This list was derived from the current KML 2.1 tags and signifies the general concepts we’re hoping to have in KML Core - allow a user to express location, time, and possibly link to another KML document or service. In addition, providing the current Atom support allows for attribution and other interesting things for linking to HTML and GeoRSS.

Geometry Markup

A couple of nearly given plans were laid out for for revisions to KML. The first is the markup of the geometry. OGC is well known for GML, and there are many tools that publish and consume GML. Having yet another geometry markup seems to be redundant and confusing. Therefore, KML 3 will use a minimal version of GML, GML Simple Features Profile. You can follow that link to the specification - but good luck finding an actual simple example or description of what it is.

To summarize, here is an example of a KML 2.2 point, and a GML Simple point:

<Point><coordinates>lon, lat[, alt]</coordinates></Point>        

<gml:Point><gml:pos>lat lon [alt]</gml:pos></gml:Point>

It’s mostly a simple markup difference. There is also the possibility that the gml: namespace prefix would be dropped and just be part of KML. GML provides for specifying the coordinate reference system (CRS), but for KML it is currently assumed to be EPSG4326 - that is to say, what you probably normally use for your map applications and off of your GPS receiver. Later I’ll put up a full comparison between all the current KML geometry markup and its comparable markup in GML.

Being a fan of simple markups myself (see GeoRSS Simple), as a developer I also understand that having a single (and simple) markup makes implementation and maintenance easier. KML already had embedded tags for locations and used a GML 2 like markup - so switching to GML 3 is fairly straight-forward.

As I mentioned in my previous post, the Agile Geography thread of OGC’s OWS-5 testbed is going to be more open. Therefore, I’ll summarize the two-day meeting we had earlier this week in Reston, VA, and where the current thoughts on KML 3 stand. However, keep in mind these are just the notes from the meeting and still in very active discussion (technical committees have telecons once per week, so we’ll be talking a lot).

Committee example documents will be posted on the OGC Network page in the “Mass Market” (now known as Agile Geography) section. The KML page lists current examples that we’re working on, so you can follow along there in addition to this blog.

First, the title of this post is “KML 3″, however, it’s not clear yet if this will be 3, or 2.x. Really, the point is moot, and probably in the end be more reflective of how much a change this first revision is. So don’t digress too much on my use of “KML 3″.

Breaking down to build up

One of the primary topics discussed, and nominally agreed upon, was how to define KML such that developers can build capabilities for certain parts of KML without having to implement support for the entire specification. This is important based on the OGC’s normal method of operation and use. By providing a spec, developers are expected to implement that entire spec and then get a stamp of approval that they meet the spec requirements. Then, users of the clients or libraries can feel confident that the features they expect are in fact implemented, and implemented correctly.

KML has a large number of features, from simple geometry markup, to 3-D models, image pyramids, lookAt, and so on. Expecting all KML clients to implement all parts is unreasonable. The simplest demonstration of that is comparing current KML clients: mobile, web map, 3D ’spinny globe’. There are certain aspects of KML that make sense on some of the clients, but not on others.

For other formats, such as GML, the OGC has first defined a full super-set of the spec, and then defined profiles, which are defined subsets of the full spec. From my (and the committees) perspective this can be confusing to developers and users because the first time they go and read up on GML, they get the 400+ page specifications document, balk, and walk-away (or have mild breakdowns).

Instead, for KML, we’re planning on defining a core minimal set for KML, and then put the other functionality into modules. Applications and clients can then use modules that are appropriate to their application.

To illustrate, a simple phone may just want locations and some simple metadata (or attributes) of that location. For example, nearby restaurants and their opening hours. As the client (or library) becomes richer then additional modules can be implemented. A Weblog extension may support styling (icons, line colors) for publishing KML from posts.

So, applications will be able to simply define what modules they support so that users can clearly understand the type of functionality they can expect. In addition, these libraries and applications can achieve OGC verification by implementing the defined feature set in the modules they use.

So what’s in each of these modules? I’ll discuss each of them in successive blog posts (to make them all more readable and keep any discussion grouped together).

There has recently been a lot of discussion around KML becoming part of the OGC and the future of GeoRSS and KML. Will GeoRSS use KML payloads, or vice versa? Will one just subsume the other? After speaking with a bunch of people at Where, and also thinking about various announcements and talks given by Google-ites, Geo-ers, and standards makers, I’m proposing the following practice for using GeoRSS and KML together along with other formats.

In the talk announcing KML submission to OGC, the phrase “KML is HTML for the geospatial web” was used. I think this is a perfectly apt analogy. To complete the analogy, (taking you back to your SAT days)

HTML : RSS :: KML : GeoRSS

The purpose of the following examples is to illustrate the use of GeoRSS to syndicate KML content, similar to RSS support in HTML. GeoRSS merely adds a geographic component to the common RSS that syndicates web content. KML similarly offers a geospatial alternative representation of HTML content.

Syndication

Therefore, as appropriate, GeoRSS should be used based on existing usages of RSS. This means providing a rel=”alternate” link in both HTML and KML files. Conversely, an Atom or RSS feed requires use of a ‘link’ element to reference the originating content of the syndication. A rel=”alternate” can then be used in a GeoRSS feed to reference the KML version of that content.

Within a GeoRSS file, the entire feed, or channel, can link to the content in type=”text/html” and type=”application/vnd.google-earth.kml+xml”. Within a single entry, the GeoRSS feed can then link to the specific anchor, or element, within the original HTML or KML content using an anchor in the href.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>KML GeoRSS Example</title>
  <link href="http://example.org/"/>
  <updated>2007-06-04T12:34:02Z</updated>
  <author>
    <name>Andrew Turner</name>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
  <link rel="alternate" type="test/html"
    href="http://example.org/"/>
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>

  <entry>
    <title>This is my first article</title>
    <link href="http://example.org/2007/06/04/article"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml kml">favorite park</a>.
    </summary>
    <link rel="alternate" type="application/vnd.google-earth.kml+xml"
     href="http://example.org/kml_georss.kml#article1"/>
  </entry>
</feed>

Documentation

Within an HTML file, the <head> element can contain alternate links to the KML representation as well as the GeoRSS syndication. Similarly, KML 2.2 can contain an <atom:link> alternate representation back to the original HTML content and GeoRSS syndication of the geospatial information. By using these links, a resource can offer multiple formats as appropriate, syndication for alerting users of updates to the content, or visualization for a richer geospatial view.

For a specific KML Placemark, an <atom:link> can be used to link to the original HTML element using the anchor support in the href. Conversely, the HTML element, similar to a GeoRSS item, can use an <a> element to link to the specific KML Placemark representation. This similarly allows for the documentation element to reference the richer visualization of the feature. Clicking this link would either launch a KML viewer, or the original HTML renderer could render the KML element inline, within the browser.

<html>
<head>
  <title>KML GeoRSS Example</title>
  <link rel="alternate" type="application/rss+xml"
    href="http://example.org/kml_georss.rss" title="GeoRSS feed for My Page">
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>
</head>

<body id="kml_georss">
    <h1>Example of KML, GeoRSS, and HTML being used together</h1>

    <h2 id="article1">This is my first article</h2>
    <p>KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark"    type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </p>

</body>
</html>

Notice that by using the type attribute in the <a> we can link to other KML elements, similar to an HTML document linking to elements in other HTML documents.

Visualization

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
  <name>kml_georss.kml</name>
  <atom:link type="text/html"
    href="http://example.com" title="My Page"></atom:link>
  <atom:link rel="alternate" type="application/rss+xml"
    href="http://example.com/kml_georss.rss" title="GeoRSS feed for My Page"></atom:link>
  <Placemark id="article1">
    <name>This is my first article</name>
    <atom:author>
      <atom:name>Andrew Turner</atom:name>
    </atom:author>
    <atom:link href="http://example.org/kml_georss.html#article1"></atom:link>
    <description>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </description>
    <Point>
      <coordinates>-122.370533,37.823842,0</coordinates>
    </Point>
  </Placemark>
</Document>
</kml>

Together, these suggestions allow for parallel use of KML and HTML for content, and GeoRSS for syndication (notification of updates) to that content. It keeps the GeoRSS as a pure markup of the new information, and keeps styling information in HTML and KML.

Here is a spiffy diagram to help illustrate linking the documents and articles together:

A last consideration about linking HTML content and KML content. Both formats are merely markups for storing and rendering information and not bound to a specific renderer (e.g. Firefox or GoogleEarth). However, it is still beneficial to link to a richer geospatial markup from an HTML file. <a> elements can optionally utilize the type attribute to specify the link follows to a KML file. It should explicitly noted that opening a link to a KML type should not necessarily open in GoogleEarth. Again, KML is just a richer geospatial markup of information.

For example, if a user is viewing a location from a GeoRSS file loaded in a 2D map representation, and link in the content points to a KML type, clicking this link should first open the location in the same 2D map representation. If the link is clicked in an HTML file, the appropriate MIME-type handler should be invoked. This is similar to a user clicking a link in an HTML document and opening the link in the HTML renderer.

Depending on the 2D map rendered, an optional “view in 3D” link could be offered to open the Placemark in GoogleEarth or other KML renderer.

OpenSearch

This proposal is just a suggestion, and doesn’t require a change to any of the included formats. In fact, it is just a recommendation for a common usage of these formats to provide for better user experience and linking together your content. Additionally, my previous discussion on OpenSearch Geo fits perfectly with this as you can specify search mechanism for the same content-types. So if you just want the recent changes, request the RSS. Then you could use those results (page) to query specific KML rich placemarks for visualizing.