How KML Succeeds and Fails as a Web Format
KML is linked. It is self-descriptive, and can rely entirely on following of links to obtain more information, whether that is styles or additional data.
However, the most common way of packaging KML is as KMZ — which is sort of like packaging an HTML page inside a zip file with all of its component parts. When this is done, web-based tools — like the Javascript support in browsers — lose all access to the data other than through a server side proxy (and even that isn’t a trivial thing to achieve). Styling information and related parts are not stored as separate resources on the web. The information available in the KML has suddenly become just another application-specific format.
If this were uncommon, it wouldn’t be such a shame; it’s certainly possible to distribute data like this for use cases where it is necessary, including offline use and other use cases. However, this is not a limited situation — in fact, more than 80% of KML made available on the web tends to be primarily available as KMZ. This packaging of KML leaves much to be desired, and limits the use of such data in web-based tools.
The web already has ways to compress data — gzip-based compression is common on many web servers (a tradeoff of CPU time for bandwidth), and works fine in all KML clients I’m aware of (including Google Earth and Google Maps). This lets your data exist on the web of resources and documents, rather than in a zipped up bundle.
My interest in this matter should be obvious: I work with mapping on the web. Ideally, I work with tools that don’t require server-side code — every piece of server side code you have to build is another heavy requirements placed on the users of any software. Browsers, as a common platform across which developers can code, are a worthwhile target, and trapping your data in KMZ hides it from browsers.
Free your KML! Publish on the Web! Don’t use KMZ!
February 1st, 2010 at 11:47 am
KML isn’t well linked – how do you link to a specific placemark? Maybe that is just a function of the user agent behaviour, but the “geoweb” browser I’ve been using doesn’t support that.
Regarding compression – a very good point – leave the compression / decompression to the web server and client, but then you have to deal with resource (image) references using full URLs, not relative – which might also be related to the geoweb browser behaviour.
February 1st, 2010 at 1:27 pm
I concur. But as you mentioned – it’s too late in the game to ‘Free you KML’.
The web at large lives and dies by the goods and bads of HTML and JavaScript. And the geoweb with KML and KMZ.
February 1st, 2010 at 2:57 pm
The EPUB of the “GeoWeb”?
February 2nd, 2010 at 1:50 pm
“web-based tools — like the Javascript support in browsers — lose all access to the data”
There’s a popular ActionScript 3 unzip library which is being used for .kmzs, so it’s not quite all. In general, though, yes, I’d agree.
February 3rd, 2010 at 5:39 am
GZip/Deflate encoded KML may “work” with Google Earth but only, if I understand correctly, because Google Earth isn’t sending an appropriate accept-encoding header and is getting served uncompressed content instead. If this has changed recently, I’d LOVE to know about it.
Although KMZ (zip) is sub-optimal, and a pain in the ass for developers, it’s also a necessary evil for performance in many use cases. For instance, while I use KML for individual resources, any query that has the potential to return hundreds of rows uses a KMZ representation.
February 3rd, 2010 at 10:52 am
I think the area that kmz files excel in, other than compression, is offline access to resources. I’ve worked with some folks that just hand out a kmz file to their (disconnected) field agents and they work off that. All images and so forth are included in the kmz.
February 13th, 2010 at 3:42 am
Many web servers (Apache and nginx) can send pre-compressed data. So, if you have both file.kml and file.kml.gz, server will send former or latter depeding on cilent’s capabilites, without any significant CPU load.
February 18th, 2010 at 7:29 am
To be fair KMZ does allow people to send GE content via email. This feature is a massive advantage for GE as a platform making it much more familiar to people. To drop KMZ entirely there would need to be some sort of secure alternative mechanism to do this.
It may be difficult to make a proxy, but surely that is exactly what is needed.