Chiming in on KML Metadata

Everyone else is doing it, so I thought I might as well jump on the bandwagon with everyone’s new favorite geodata topic: KML Metadata.

I’m going to try and keep this short and sweet, since so many other people are already commenting on it.  Notably, the folks at Platial who propose its use for attribution information.  There’s also Google’s knowledge base article on the topic.  Although I think Paul Ramsey summed up some of the various opinions and comments on the matter well in his recent blog post.

Long story short, yes, there are real issues that need to be addressed, but let’s think before this turns into a monster.  KML was already becoming the standard way to store and transport geodata around the web, and it’s recent introduction into the OGC standards process has further cemented that.  One of the reasons that FortiusOne ultimately decided to support KML import in the short term, instead of GML or GML Simple Features profile was because it was simple.  It was one file that you needed for import, and you didn’t need to pull down a separate application-specific schema for more complex files.

KML’s Schema element handles this nicely.  The only restriction is that, as of right now, according to the documentation: “… the only value for parent is ‘Placemark.’”

This works wonderfully for our purposes.  Namely, importing geodata with attribute structures on each individual record.  This does not explicitly solve the attribution issue, and, frankly, I think the suggestion put forward by Platial re: the use of the Metadata element is a sound one, although for something as universal as attribution information, a top level element or elements to handle it explicitly might be called for, but whatever gets the job done, really.

What sort of scares me is in Google’s own example.  By their definition, the contents of the Metadata element are ignored by the viewer, but preserved in the file otherwise.  And their example is the tagging of air temperature data (using the ObsKML schema) to a Placemark with a polygon geometry inside of it…. huh?  I don’t know if this was just some example that got pulled out of a hat and was not intended to be overly serious, but please, please, nobody start doing that.

As it stands right now, things aren’t exactly perfect in the world of geodata and and geospatial analysis, but let’s face it, they could be a lot worse.  A lot of us, FortiusOne included, are trying to make things better and open things up in such a way that these sorts of problems can be approached by as many people as possible.

Starting a trend wherein the de-facto standard is for publishers to use their own application-specific derivation of the KML schema in such a way that the application-specific pieces of the data are inherently incomprehensible to generic data viewers doesn’t help a whole lot of people, IMHO.  Right now, I can do something like:

[other kml goes here ...]
<Schema name=“City” parent=“Placemark”>

<SimpleField name=“Name” type=“string”/>
<SimpleField name=“Population” type=“int”/>

</Schema>
<City>

<Name>Nowheretown</Name>
<Population>3</Population>

</City>[other kml goes here ...]

And what I will get is:

• Structured data that a generic KML consumer like GeoCommons can use in a productive way
• Something that still shows up properly in Google Earth (you even get nice little lists with the field names and their values)
• A single file that defines what little custom schema it needs
• Something that is SIMPLE

Key word there: SIMPLE.  Yes, there probably is a place for more structured and complex application schemas, but those are really the exception to the rule in my mind.  Don’t we want to stick with something that solves as many problems to as many people as is humanly possible without making everyone’s lives harder?

There are still many uses for something like the KML Metadata tag, but let’s be very wary of making things unduly complex so that everyone benefits.

Flexibility is good, but just because you can do something doesn’t mean you should.  My car has a luggage rack that might make a nice mounting point for some JATO rockets, and using it for such could potentially cut my commute time down.  However, it probably isn’t a terribly great idea for me to do so in the grand scheme of things. (editors note: apologies if that example was a little nonsensical and out of left field, but I really just wanted to work a rocket car into this somehow)

After all, what good is publishing your data if only you,  somebody, or some machine that had to explicitly learn how to, can read it?

Just my $0.02, flame away, I’m off to find some JATO rockets

Technorati Tags: geocommons, geodata, geoiq, KML, google, Metadata