Geotagging Photos with Picasa and Google Earth

Geotagged photos

A few weeks ago, I went on a hike to Treasure Island, and I thought it’d be a good opportunity to try out the state of the art in simple photo geotagging, so that people could see photos of my trip on a map. My first test involved:

  1. Uploading the photos to Flickr using FlickrExport for iPhoto
  2. Finding the spot for each for photo in Google Earth, creating a placemark, and copying the latitude and longitude into geo:lat= and geo:lon= tags on the Flickr image.
  3. Using Scott The Hobo’s Flickr Photoset Maps to turn the geotagged photoset into an online map.

The resulting map is pretty nice, sluggish Yahoo map aside, and the process wasn’t too painful. The worst pain point was the cut-and-paste geocoding process.

However, since Google just released a whole slew of geographic updates, not to mention a barebones (but snappy) photo hosting service, I thought I’d give it a try using Google tools.

First step: get the photos into Picasa, Google’s excellent free Windows photo organizer. I used FlickrDown to download the photoset from Flickr to my Windows box. It was simple, though I was sad that there was no way to preserve my photos’ tags. I then downloaded the new version of Picasa from the Picasa Web Albums site. (You need to get this specific version to be able to do the fancy stuff I’m about to describe.) Picasa immediately found and imported the downloaded photos—so far, so good.

Next, I went through and geotagged the photos using Picasa’s integration with Google Earth 4. I highlighted some photos in Picasa and selected the Geotag With Google Earth option hidden away in the Tools menu.

Geotag Menu

This took me to a slick geotagging interface in Earth.

Earth Geotagging

Basically, you just drag and zoom around in Google Earth until the crosshairs (which are anchored to the middle of the display) are resting on the point that you want to tag the photo with. Then you just hit the Geotag button, the view bounces to give you visual feedback, and it moves on to the next photo. This was so much more pleasant than manually copying the location to Flickr. When I was done, it brought me back to Picasa. The photos all had little crosshair icons in the corner, indicating that they had been geotagged, and a quick look at the Properties dialog seemed to indicate that the location had been added to the image’s EXIF data.

Properties dialog

Now that the images were geotagged, I found that I could use the View in Google Earth... option to see the photo on the map. It seems that this is implemented using some sort of dynamic folder in Google Earth called Picasa Link that constantly queries Picasa for images with geotags in their EXIF—so effectively, you can browse your Picasa library geographically using Earth! I tried adding a random geotagged phonecam image from the web, and sure enough, it showed up on Earth.

OK, so now that I had found geotagged image bliss, how could I share it? I tried the Export to Google Earth File option in the ToolsGeotag menu, which yielded a nice Google Earth KMZ file with the photos embedded.

Since Google Maps recently added support for viewing KML files, I decided to see if I could view my photos there. The results were not so hot.

Maps KML failure

As you can see, it wasn’t a total bust—the locations show up correctly—but the actual photos were nowhere to be found.

Since I’d seen examples of photos on maps, I was sure it could be done—maybe they just wanted the photos to be linked from the web. The Google Earth UI didn’t seem to give me any way to replace the photos with web links to photos. However, KML is a straightforward XML format—hand-editing ahoy!


(Incidentally, I was hoping that when I uploaded the images from Picasa to my Picasa Web Album account, it would do something smart. Sadly, Web Albums didn’t show any recognition that the images were geotagged, not even in the EXIF section. I’m sure that they’ll eventually sort that out, maybe by automatically generating KML links to Maps.)

Back to the hand-editing; first I had to unzip the KMZ file that Picasa had generated. (It’s just a normal zip file, rename the .kmz to .zip and you should be able to unzip it normally.) The only file that I needed was the doc.kml file; the rest of the archive just contained the photos and thumbnails. I stripped out all the style stuff at the top of the file, since Maps didn’t seem to be paying attention to the icons anyway. Then I replaced the contents of the description tag in each placemark with an image reference and link to the images on my Picasa Web Album. Then I uploaded the KML file, and it worked!

Working map

The result isn’t quite as nice as my original map, because I didn’t immediately see a way to get smaller images out of Web Album, but it does the job.

The verdict: geotagging with Picasa and Google is a dream, viewing geotagged Picasa photos is awesome, but the web mapping part of the Google photo story needs work.

(Incidentally, while you’re checking out my Treasure Island album be sure to try pressing the left and right arrow keys while you’re looking at pictures—you can flip through photos really quickly in Picasa Web Album!)

MBTA Google Maps Experiment

MBTA Google Maps Experiment

Since Google so graciously released an API for their excellent mapper last week, I figured I’d take it for a spin. I had written some code to prise nearby stops and bus times from the MBTA’s handy trip planner a while back, and so I decided to glom them together and see what happened. Here’s the result.

Here’s how it works: You pan and zoom around the map until you find an area of Boston you’re interested in, and then click Recalculate Stops. The map will then update to show stops within a half-mile of the center of the map. You can click on any of these points to get the next three times for the routes at that stop. Seems to work for bus, subway, commuter rail, and ferry routes.

It’s vaguely useful for an afternoon’s work, though there are a few quirks:

  • Stops which are too close to each other may be impossible to click on (sometimes you can tell because their shadows look darker)–I’d probably have to write some code to combine these into a single marker.
  • The same subway line is often broken into separate listings. This is something that the trip planner does, perhaps to get around some sort of database limitation? In any case, this can probably be remedied with more code on my end.
  • Other than the subways, each route is listed only once per map, at the nearest stop. This means that even though the 87 might stop in several places within the mile-wide area being searched, you’ll only see the stop that’s nearest to the center of the map.
  • There’s no way to jump to a particular address. The Google Maps API currently doesn’t do geocoding, though I could integrate or the trip planner’s built-in geocoder given a little more time.
  • Clicking the Recalculate Stops button isn’t the smoothest thing in the world. My first attempt updated the query automatically when you panned the map, but that made things a bit too jumpy as you panned around to get a better look at the stops and surroundings. Needs more work.
  • The iconography and layout could be better.
  • I have no official connection with the MBTA, and they could break the scraping code that this depends on at any time. I hope they’ll be more flattered than offended if they find this.

All in all, the Maps API is pleasant to work with, though the way that Google binds API keys to individual directories keeps you from being able to just copy the source files from your test directory to your deployment directory. But that’s the most minor of nitpicks, given that you can dispense keys for all the directories you want. They’ve done a great job, and I think we’re going to see an even bigger wave of new mapping apps in the coming weeks.

More A9 Yellow Pages

Here are a couple other interesting bits about the A9 Yellow Pages:

While my previous post on the topic was more about the UI of the feature, I just noticed another interesting part of the page:

A9 Update Listing function

Clicking that button takes you to a fairly comprehensive set of web forms which allow the business owner or any random websurfer to contribute metadata about that business—things like phone numbers, email, website, hours of operation, and credit cards accepted. This, along with the fact that all of Amazon’s existing commenting and recommendation features are available for the businesses, made me realize that what they’re really doing here is planting the seeds for ownership of the real-world metadata game as thoroughly as they’ve captured the product-metadata space.

What’s the typical place to link to if you’re talking about a book or DVD online? Amazon. (I’ve even got a plugin on my WordPress installation that automates these sorts of links.) Amazon really realizes that they’re in the cataloging business as much as the product-shipping business—I don’t have a reference handy, but I remember Bezos saying that they could always make a business licensing their catalog (with all the rich comments, ratings, and other user-contributed metadata) if the “selling things” bit didn’t work out. Now they’re poised to become a definitive resource about local businesses (and other physical entities).

As good a job as I’m sure they’ll do with it, the fact remains that according to their license, Amazon’s dataset (including user contributions) is proprietary. (That could be one reason why they decided to run their own GPS photo trucks rather than employing pre-existing road-photo data sets.) They alone ultimately control what can be done with it. Wouldn’t it be better if we could find a way to collaboratively build similar systems without throwing our work over a proprietary wall in the process?

Fast Feedback

A9 Yellow Pages 1369

This morning’s buzz on the web seems to be centered around a9′s new Yellow Pages feature, which tries to show photos of the businesses alongside their results. How did they get all these photos? Basically, they had trucks with side-facing cameras and GPS units driving down the major commercial thoroughfares in a bunch of cities, and the system tries to roughly match up the geocoded address with the photos taken near that location. (As Russ Beattie points out, this has been done in Spain before, but not with this level of grace in the U.S.) If you know anything about GPS, you’ll realize that this process isn’t very exact, and indeed most of the photos of Cambridge businesses were about a block off their intended targets.

A9′s saving grace here is that they provide an incredibly painless way for users to correct the listings. At the bottom of the screenshot above, there’s a smooth javascript-driven row of images that you can use to pan down the street, and in a single click, assert that one of the particular photos is in fact the correct photo of the business—without going to another page, without signing in, without hassle. In my own projects like buskarma, I’ve learned the value of fast feedback—if you can present users with a minimal interface at the exact point at which they notice an inconsistency or failure of the system, you can often skim nice, targeted content improvements off the top of the user’s brain.

In A9′s case, once I corrected the entry shown above, it immediately started using that photo as the definitive one. It didn’t, however, update the thumbnail in the search results listing (I assume that’s cached). It also didn’t give me a way to assert that the photos were of the wrong side of the street for the business I was looking for. Finally, it didn’t make any attempt to re-interpolate the locations of the nearby businesses based on my assertion. Still, the mechanism is a great Wikipedia-style way of having the legions of web users who are undoubtedly kicking the tires of this service today improve the results as they go along.

Road Editor

Oh, and by the way, A9′s not the only one who’s been driving around with photo trucks. Peep this screenshot from a collaborative GIS demo that I helped put together for a northeastern state which just happened to have yearly drivethrough data for all of its state roads. Track me down at ETCon if you want to see it in action.

Mappr Interactive Demo

Mappr Alpha

Mappr, a new photo-mapping site that uses the Flickr image-sharing infrastructure to display photo thumbnails on a map, has just made an interactive demo available. At this stage, it appears to be limited to showing subsets of a fixed set of photo collections (refreshed daily) on a state-level map of the U.S. However, the end result is something that performs with compelling smoothness on my old iBook. (Though it naturally bogs down a bit more as you hit the “Thank you sir, may I have another” button.) They claim to be determining the location based on place name heuristics in the photos’ tags (and possibly descriptions?). Note also the red “2″ in the screenshot above, which appears to be an aggregation indicator. I’ll be watching this one closely as they develop its capabilities further.

(Update) Unsurprisingly, free-text geocoding is fraught with peril:

Paris, Texas?

IndyJunior Flash-based Travel Mapper

Have you ever wanted to see a map of your journeys, like the ones used to express travel time in old movies? After admiring the map on Dan Washburn’s Shanghai Diaries, I tracked down Bryan Boyer’s IndyJunior. Indy Junior is a simple Flash application that you can use to put a clickable travel map on your site. You create an XML file listing the latitude, longitude, date, and optionally notes and URL, for each place you visited, and the app will plot the locations on the map, with lines between them. As far as I can tell, the level of detail is limited to country outlines, but as long as you’re traveling far enough, the results should still look interesting.