This page describes some experimental Google Earth data feeds that I've made available for a few region-based Flickr groups. If you have Google Earth installed, and a high-bandwidth 'net connection, the following KML links will overlay some photos on the globe, where the photos are public, posted to one of the selected Flickr group pools below, and tagged with their location.
Note: Please be aware that this is a work in progress, and that the usability and reliability of these feeds should be improved in the future.
Links below are to Flickr pages, followed by the link for Google Earth. If you don't have Google Earth, you can still check out the photos via Flickr's Web interface by following the 'map' link.
Flickr is a popular photo-sharing service owned by Yahoo. Their photo organizer has a facility for "tagging" a photo with its location, allowing you to see it using Yahoo maps displayed within Flickr. Since they also allow external software to read this information, we can write tools that display photos in other ways. All we have here is the result of reading some photo descriptions from the Flickr site, and generating files that Google Earth can understand.
I've posted a few screenshots to Flickr.
The images here are of Buenos Aires, and also show some great 3d models and maps from Ezequiel Galotti's Argentina 3D work.
No claim to originality here. Here's how this version works. This bit is for technical developers, programmers and the terminally curious.
The software is all available online if you're interested in the detail. There isn't much to it. It's a hack. The basic idea here was to experiment with an approach to consuming photo data that was neutral between Web service and "data dump" approaches. If we have a local repository of photo metadata (from Flickr eg. via Aaron Straup Cope's Net::Flickr::Backup, or from elsewhere), we should also be able to generate maps, 3d globe overlays, HTML pages etc., regardless of where the data comes from.
So what we've tried here (and big thanks to Danny Ayers for XSLT help) is the idea of using W3C's SPARQL RDF query interface as a datasource abstraction. SPARQL provides a language for querying aggregated Web data, structured in terms of the RDF graph data model. It looks a bit like SQL, in that it begins with the word "SELECT" and returns tables of fieldname/value bindings. The use cases and protocol documents are worth a look if you're interested in this area. Here we focus on the idea that many Flickr Web Service API calls result in a structure very similar to a SPARQL resultset. Basically, a set of "hits", each one of which carries a collection of field/value pairs.
What we've done is convert Flickr's data structures into one that might have come from running a SPARQL RDF query. We didn't even write the query yet. But we imagine that we have one that returns a table of results with named fields as columns, and each photo corresponding to one row.
SPARQL comes with a simple XML format for representing such tables of results, the SPARQL Query Results XML Format. There is also a version of the format expressed as JSON (ie. a scripting-language friendly subset of Javascript): see the Serializing SPARQL Query Results in JSON spec.
At the moment, what we do is run Danny's XSLT to generate JSON in the SPARQL idiom. And then consume the JSON in a Ruby script. Since Flickr itself also offers a JSON resultset format, this might appear rather longwinded and bloodyminded. Why not just generate the KML from code than runs directly over Flickr's own JSON? Basically, because we don't want to be bothering Flickr's Web Service so frequently. It's better to put a little bit of abstraction between code that generate user interface, and code that knows about a particular datasource.
The working hypothesis here is that RDF/SPARQL can provide such an abstraction, and that a cleaned-up successor to this code should be able to do interesting things with RDF data from running something like the Perl CPAN Net::Flickr::Backup tool against a Flickr pool. And that this could run from local machine, without the need to have a local implementation of the Flickr Web Service APIs. Or we might not be using Flickr at all. Geotags might come from elsewhere, eg. a little Perl code can reconcile GPS tracklogs with timestamped-photos.
Here is a Flickr API response in XML. What might this look like, if we pretend it was the result of running a SPARQL query against some RDF? Here are XML and JSON versions of this structure.
TODO: compare/contrast with Flickr's native JSON output
Currently, when we get more than 250 photos back from querying Flickr, it comes in several pages. At the moment we stop at the first page, ... but it would be nice to represent all photos from a group. At this point I think we should drop XSLT, and write adaptor code that consumes JSON and wraps the result of several "pages" of photo descriptions to look like SPARQL JSON. I'd also like to offer ability to run something like this tool for more ad-hoc groups (eg. several Flickr pools, or a person plus their friends). At some point this will mean moving to a more dynamic KML generation strategy (the current system rebuilds 6 KML files on a crontab schedule). There is also plenty more that could be done to improve the Google Earth KML side of things. Perhaps representing people and groups as fictional GE "features" orbiting in space, for example? Suggestions as ever welcomed...
Maybe this deserves a Flickr group for discussion / development?
Where to begin? Everyone's putting photos on maps... a few background links...