Wednesday, April 21, 2010
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.
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.
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.
Friday, April 2, 2010
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.