Fixing HoudahGeo's City And State Reverse Geocoding

I've been looking into geotagging my photos and finally got around to purchasing a GPS logger. Initially, I just wanted a script to automate the merging of the latitude and longitude from the GPS log into each image's EXIF information, after which, I'd just import the images into Aperture as normal. But then I found out that even more useful would be to reverse geocode the images. This would mean the the IPTC fields for city, state and country would be automatically populated, saving me from the task of manually entering each in Aperture.

Well, HoudahGeo does it better and more elegantly than any other software out there. After downloading a demo and reading Brett Gross' write-up on Aperture and houdahGeo I was sold.

The one glitch is that HoudahGeo saves both the city and the state into the IPTC city field, separated by a comma and a space, e.g., Great River, New York. I sent an email to the developers and was told that the next version, 1.5, would have this fix. Until then, I've whipped up an Automator workflow with a bit of bash scripting that calls exiftool that splits the IPTC metadata properly and will work with cities and states with any characters, including spaces, but not commas. Here's the guts to the Split IPTC City And State Automator Script:

# This automator workflow is licensed under the GPL, v2
for f in "$@"
do
        CITYSTATE=`exiftool -City -s -s -s $f`
        CITY=${CITYSTATE%,*}
        STATE=${CITYSTATE#*, }
        exiftool -overwrite_original -City="$CITY" -Province-State="$STATE" $f
done

So my workflow is now:

1. Copy photos from memory card to temporary directory on my harddrive along with GPS log
2. Use HoudahGeo to tag each image with longitude, latitude and altitude, along with the city/state and country
3. Save the GPS log away in case I need it later
4. Run the Automator script on the images to fix the city/state issue (installing it as a Finder plugin is recommended)
5. Import the images into Aperture

Image (And File Handling) In Drupal 6 And Beyond

In the beginning (2002), there was Image, and everyone could create images as nodes and all was good, if a bit simplistic. (There was even IPTC and EXIF metadata support). After a little bit of time, you could even attach images to nodes. By 2006, images could be attached to nodes. (By now, Flexinode had been around for a while and CCK had been around for a bit, too.) CCK became the predominant way of creating content types, as opposed to writing a new module for each individual content type. ImageField, a CCK add-on, (released in July 2006) allowed images to be handled by CCK. This, combined with other CCK fields let you do all sorts of neat things like set up an online store with one field being the name of the object your are selling, another field being the description and another three or four fields for uploading images of the product. Or you could be an online newspaper and have anywhere from zero to several images per article. Each page (whether online store or newspaper) could be themed to layout the information appropriately with ImageCache creating derivative (read: resized and/or cropped) images.

Fast forward to 2008 and there's primarily two ways to get images in your Drupal site, with Lullabot's Image vs. ImageField and ImageCache being the definitive comparison between the two. If you were fine with images as nodes and had simple needs (gallery, photoblog, etc.) you probably went with (or continued using from back in 2002) Image. On the other hand, if you were creating tons of content types thanks to CCK, you probably jumped ship to ImageField.

Now, there's talk about merging Image with ImageField (and ImageCache), with a script to migrate from Image to ImageField. But it was also pointed out that one field to handle all uploaded files, images or not, should be the way to go and that this would be the end of ImageField. FileField, combined with FileField Image would handle everyone's imge handling needs (as well as other file types as well).

While some people think images need special handling (and they are right to a degree and FileField Image takes care of this) there is also the consideration that other file types need special handling, such as videos. Just like images have a need for derivative images, so do videos (original high resolution, low resolution, stored as a flash file and a thumbnail screencap to display in the page). Having one unified way of uploading files would mean less code to maintain and there might even be a reasonable chance of getting file (and potentially image) handling in core, the CCK way.

(For these reasons, I've decided to postpone a D6 release of MAQUM.)

Following Up On An Ask TUAW

On a recent TUAW, a reader asked about image metadata being handled such as keywords and the like on the Mac:

I wondered if you could give some insight / explanation into keyword tagging on the Mac. I'm a long-time Windows user contemplating switching, though I'm hesitant to do so b/c managing thousands of photos on Windows is so easy, especially with Vista's new Photo Gallery, which embeds tags (or keywords) right into the original file's metadata via XMP (Adobe's standard). I understand that iPhoto does NOT embed the keyword metadata into the original file, but - instead - stores it only in its own library, thus obviating the benefit of keywords should you move your photos elsewhere at some point (onto an external hard drive, for example, or another machine). Is there a good way to get the keyword/tag into the original file's metadata, a la Windows Vista? Does Aperture do this?

TUAW responded:

Well the first thing that comes to mind is that you could simply use Adobe Photoshop Lightroom on your Mac if you want to use the XMP metadata format. As it turns out (see this Macworld review) Aperture 1.5 is able to export XMP sidecar files, but not import them. So all things considered if XMP support is important to you I'd suggest just staying within Adobe applications and you should have cross-platform functionality unless Vista messes it up.

So I sent in this comment to them:

There was a question from a reader about how various applications, including Aperture, handle metadata, such as keywords. Aperture is indeed a non-destructive image editor/DAM application which in turn means that any keywords or other metadata (such as copyright information, photographer, city, state, country, etc) is stored in the Aperture database. It is also worth noting that if the metadata is embedded in the file, it is usually using the IPTC format [1]. If the reader makes the switch to Mac and Aperture, the reader has numerous export options including, as mentioned, the option to export the XMP sidecar [2] file. Your blogger neglected to mention in Aperture, if one exports the image version as a JPEG, the keywords, along with other metadata is embedded in the image in the industry standard IPTC format [1]. , which would then be readable by pretty much any other application. There's also a handy PDF that maps out how the IPTC field name maps to the Aperture field name [3]. (Whether iPhoto behaves in this manner is beyond me, I've never touched it.)

Hopefully this clears things up!

Metadata Aware Image Handling In Drupal

I've posted an RFC regarding the use of DAM applications and how Drupal can take advantage of them, basically, my wetdream for online image galleries. I've been toying with Aperture for a week and love it, it offers several things Lightroom doesn't, however both feel sluggish on my not too slow MacBook. Not sure which application I want to use yet, but it doesn't matter since MAQUM would work off EXIF and IPTC.