Maps to KML?

People often ask me, can I take a Google Maps mashup, and make a KML file out of it (or in some other data format)? This question never comes from a Maps developer, only from people who see a cool mashup and want to overlay the data on their own map.

The short answer is: no, you can't.

The long answer is: no, you can't, and that would be wrong.

The longest answer is: no, you can't, unless the developer chooses to make a KML file available to you. It's possible, in fact, that they are using the KML file loaded onto their map using GeoXml or some other method. Otherwise, no, and it would be wrong.

I can understand the desire to do so. After all, a mashup is a combination of data from different sources, and a Google Maps API mashup is a mashup of data with Google's mapping API, in JavaScript, Flash, or just plain image URLs using the Static Maps API. And people often use public sources, or sources that are about things that are interesting or impacting lots of people, like Sports or the volcanic eruption in Iceland. Why wouldn't that be available to you?

First, from a moral point of view, the construction of that site belongs to the developer of that site. Usually, the data isn't presented to them raw, a certain amount of development has to happen to transform the data into a format usable for the app. In fact, they may have agreements with the data provider that they don't, or some license in the download from a public site restricts redistribution.

Of course, it's possible they just didn't think of it. Ping them, maybe they would do it for you just to be nice. Depends on the data of course.

Second, think about it from a technical point of view. Flash of course is it's own beast, and can write files. If the developer so chose, they could put a download data link or something. But as far as the JavaScript APIs go, JavaScript deliberately doesn't give you file access for security reasons. So a data file can't be taken from a JavaScript page. Nor has Google hidden an API inside the Google Maps API to allow other people to pull data out programatically. Again, that would be wrong.

I'm not saying that people can't look at your code and figure out your data sources, if you're the developer. If you want to protect that data source, you should design accordingly.

More thoughts on ARML

Sean Gillies commented on my last post on ARML:

Is there anything in the Wikitude namespace that isn't already provided by KML or Atom (KML uses a bunch of Atom elements already and should probably use more)?

It got me thinking a bit more about the subject. First, yes, he's right, if KML supported more Atom links, then everything could be more readily handled by Atom. Or by their KML equivalents. I'm not sure why there's an ar:description, which could be handled by a KML description, or a wikitude:providerUrl, which could be handled by an Atom link element.

I'm concerned too about the extensions. I'd rather have a larger initial set of tags that are optional than put too much on provider specific extensions. If ARML is to really thrive, it'll be because killer browsers come along early, and standard ARML is robust enough to do what most of them will want to do. And, if developers come up with really awesome ways in which ARML can be used that aren't conceived of by the creators of ARML. I'm not sure that Augmented Reality will thrive yet, but if cross-browser AR apps are going to work, the initial standard needs to be robust enough and flexible enough without extensions. I'm not saying they're can't be extensions, just that it has to be able to stand on it's own. Browsers can choose what to implement.

BTW, despite being a KML fan, I'm not saying that KML is necessarily the only way to specify the location. It's great to see it used this way, and it has a lot of potential for cross-platform integration that way. One option might be to actually wrap things in Atom like the Maps Data API does and have additional AR specific elements surface in the Atom.

Hopefully, we can talk more about this at WhereCamp tomorrow.