<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; geotag</title>
	<atom:link href="http://gidden.net/tom/tag/geotag/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Sun, 01 May 2011 10:35:37 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Meditations on #Locationgate</title>
		<link>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/</link>
		<comments>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/#comments</comments>
		<pubDate>Tue, 26 Apr 2011 14:48:08 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[Cellphone]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[gps]]></category>
		<category><![CDATA[gsm]]></category>
		<category><![CDATA[ios]]></category>
		<category><![CDATA[iphone]]></category>
		<category><![CDATA[itunes]]></category>
		<category><![CDATA[location]]></category>
		<category><![CDATA[mobile]]></category>
		<category><![CDATA[Mobile-phone]]></category>
		<category><![CDATA[mobile-phones]]></category>
		<category><![CDATA[privacy]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=171</guid>
		<description><![CDATA[Over the past week or so there's been a furore about location tracking in iOS. While it initially appeared to be a fresh discovery of machiavellian intrusion, the story's a bit more complicated than that.

The mainstream media caught wind of this story as a result of a blog post by Alasdair Allan and Pete Warden on April 20. They released an open-source app for grabbing the data from iTunes's iOS device backup files and displaying it on a map. It's a very neat hack, but it's really just taking a simple SQLite database called "consolidated.db" and doing some trivial queries on it.
Alex Levinson points out that this is not new information, though. Allan and Warden do get credit for producing pictures, though: without which the mainstream media would never understand or care.
Levinson also makes some other points, but I'm not sure I'm in complete agreement. For a start, the location data can be remarkably precise. The general belief is that the device is either storing the cell locations rather than the device locations -- a subtle but important distinction -- or it's storing the estimation of the device location based on the known cell location. I'm not sure. However, I've done what pretty much every geek has done this week and imported and converted the data into KML and a variety of other formats, and I've found (in the "CellLocationLocal" table) a row that is apparently the deduced location of an Orange UK Cell Tower (MCC 234, MNC 33, LAC 3103) in my front garden. (Suffice to say, it's not there.)
Will Clarke points out a response from Apple to an inquiry by Reps. Edward Markey (D-Mass.) and Joe Barton (R-Texas). I do vaguely remember something about this new location strategy last year, although I'm not sure whether it was from this or some of the developer information. At the time, I dismissed it, without considering the deeper ramifications.
To understand what's going on, you have to know a little history.
The original iPhone didn't have a GPS chip. Location services used two sources of information from the vicinity: finding nearby WiFi networks and nearby cell towers, and looking up their location with a service run by Skyhook and a separate service run by Google. Skyhook initially seeded their database by basically wardriving the USA, Europe and Japan, and then also accepted submissions from users. Google, presumably, picked up their data using their own wardrive, piggybacked on their Street View cars (and we know how that turned out for them!)
The system worked adequately for looking up nearby restaurants and the like, but not for navigation. iPhone 3G and above include a GPS chip, but even so, WiFi and GSM location is quicker, more power efficient, and better performing indoors and in urban environments. However, it requires Internet coverage to do the lookup. Caching is obviously an option, though.
When iOS 3.2 came out, the situation changed slightly: rather than using third-party databases -- one of which was run by their friend-turned-archenemy Google -- they chose to replace the lookup service with their own.
Here's the clever bit, though. Rather than wardriving the planet, they realised that they had about 40 million data collection devices already in the field: the iPhone itself. So now it's all done by crowdsourcing: the lookup goes both ways now. When your iPhone uses Apple to lookup the known location of WiFi and GSM sources, it can also supply its own GPS data back to Apple for future lookups by other users. F-Secure reports that the batches occur twice a day.
Technically, this is a fantastic idea. Unlike a wardriven service like Skyhook, this one is continually refreshed and expanded. It makes perfect sense. It's a very neat trick.
However, it's mindboggling that Apple thought this was something they could get away with without a clear opt-in by users. I'm sure in some countries, it's even a criminal act. I suspect Germany is one of those countries.
That's not to say that it's a secret: Apple did disclose the service in the updated Terms and Conditions of iOS which I'm sure everyone read(!), the Apple Privacy Policy and a misleading opt-in dialogue box talking about "anonymous diagnostic and usage information". However, it's not reasonable to expect every user to fully understand the connotations of what's going on. At no point does it say anything as obvious as "Oh, by the way, this means your device is continuously tracking its location."
So, why is this happening? It's not just the crowdsourcing, as that doesn't need to be stored once it's been done. Is it caching? It makes sense to cache the location data to an extent, but failing to clear the cache is a bit silly.
Of course, another possibility is that Steve Jobs is -- in fact -- The Dark Knight himself.

This would explain the leave of absence, I guess.
Forgetting the inevitable lawsuits and legal inquiries, did it not occur to Apple that there would be an almighty shitstorm if/when this became public knowledge? If they'd made a big deal of it and had Steve Jobs actually rave in a keynote about how their location database was constantly updated with your assistance, this wouldn't have been a big deal: a few contrarians and Android fans would have whined about it and how they'd never buy Apple again, but on the whole, it would have died down. There certainly would have been far less opportunity for legislators to bollock Apple for it.
This is Apple: a company that has meetings arguing over individual pixels on their UI designs, and yet it didn't occur to anyone to ask whether this whole scheme was morally right, legally right or diplomatically right? It didn't occur to them that it would actively turn customers against them? Are they really that boneheaded?
For me, the question is, do I care? I don't really care whether people will know roughly where I've been, and looking at previously-undiscovered maps of my Orlando vacation (Kennedy Space Center and Walt Disney World), a trip to Ahmedabad and my various jaunts around the UK has been pretty cool. I can, however, understand why others are upset about this, but I think it's mainly due to the surprise and lack of choice, rather than the actual tracking itself: if you knew it was happening, would it really be such a problem?]]></description>
		<wfw:commentRss>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Using Google Earth to geotag photos in Aperture 3</title>
		<link>http://gidden.net/tom/2011/01/08/using-google-earth-to-geotag-photos-in-aperture-3/</link>
		<comments>http://gidden.net/tom/2011/01/08/using-google-earth-to-geotag-photos-in-aperture-3/#comments</comments>
		<pubDate>Sat, 08 Jan 2011 19:08:15 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Techie]]></category>
		<category><![CDATA[aperture]]></category>
		<category><![CDATA[automator]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[google earth]]></category>
		<category><![CDATA[gps]]></category>
		<category><![CDATA[iphoto]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=144</guid>
		<description><![CDATA[After a couple of years of painful attempts to geotag all my photos, I've finally got something that might end up working: a small hack that grabs the current location from Google Earth and updates the selected images within Aperture (3.1).  This post explains it, and how to install it.

Sorry, but you're going to have to suffer a bit of a rant first:
This whole effort comes from my deep hatred of the Places feature in iPhoto '11 and Aperture 3. While I'm not a particularly good photographer, I do try to keep all my metadata neatly arranged and all my photos neatly geotagged. However, until recently, iPhoto hasn't even tried to make this possible. Instead, I'd geolocate the photo using a mixture of Google Earth and Flickr's map, and then try to copy those locations back to iPhoto with varying results. I started using bits of Perl and AppleScript, including a horrible kludge to construct a lookup table in SQLite between Flickr's metadata and iPhoto's catalogue and then use ExifTool to reapply the latitude/longitude data.
Incidentally, since then, I've found the promising PictSync app being written by Loghound.  It promises to eliminate the need to hacked-up scripts to do the Flickr-to-iPhoto metadata sync.  It's a bit rough around the edges at the moment, but it's getting better by the day.
However, even with PictSync, this approach only works for the 5-10% of photos I chose to upload to Flickr.  The lion's share of my 10,000-odd photos were untagged.
iPhoto '11 looked like it was going to sort all this out: the heralded Places feature looked easy, and even "fun". So, I made a special trip out to the Apple Store to buy iLife '11 when it was released.  Unfortunately, in my opinion, Places has a terrible UI: it's buggy and poorly documented, and even when it does what it's meant to do it's difficult to use.  You can see what they were trying to achieve and it's usable if all you're trying to do is locate a single image at a well-known Googleable location in the US, but it's a cow for everywhere else.
I finally cracked when I was trying to tag a 2002 business trip I took to Malmö, Sweden.  I managed to find all the locations, but getting these onto the photos with Places is a nightmare:  the only reliable method I've found is to convert all the locations to latitude and longitude in a text file, and then one-by-one, apply the location, resulting in a pointless Google lookup and a usually-wrong reverse geolocation.
Anyway, when the Mac App Store was launched this week, I cracked and paid the heavily-discounted £45 for Aperture 3, as I just can't stand using iPhoto '11 anymore. Anything's better than iPhoto '11... even iPhoto '09.
Unfortunately, Aperture 3 contains a version of Places that's obviously using a lot of the same code as the iPhoto '11 version.  It's broken.  It's badly documented.  It's got an incredibly frustrating feature where clicking an unlocated photo in Places will result in losing the current map location and showing the world instead: exactly the opposite of what you want when you're trying to label a set of photos one-by-one.
I tried some third-party plug-ins such as Maperture Pro from Übermind, which is a darn sight better than Places' interface for positioning photos, but it has a few UI problems of it's own: not least of which is the modal nature of the dialog box that stops the ability to zoom in on the image in question, making it hard to locate.  As a result, you have to be sure of the location before you browse.  Anyway, it's still not ideal, especially since I need to be able to browse Google Earth for the area, community labels and street view to be sure of where the photo is.
So, I think a possible way to solve this is to use Google Earth as the geotagging interface.  I couldn't find an existing plug-in to do this, so I fired up Automator and tried to remember how to use AppleScript (again).  The result is a small ".workflow" file that you can install as a Service, and then trigger from either Aperture or Google Earth.
To install:

Download this archive file containing the workflow
Uncompress it into a .workflow by double-clicking it (if your browser hasn't already done so)
Move it into the Services subfolder of your user's Library folder; OR you can double-click it to load it into Automator and then save it as a service.  It should then be installed automatically.
Launch System Preferences and select the Keyboard Shortcuts tab of the Keyboard preference pane
Use the "+" button to add a new Application Shortcut
Choose Aperture.app as the application
For the menu item, type Set Aperture GPS from Google Earth exactly. It must be exact or the shortcut will not work.
Choose a keyboard shortcut:  I use Cmd-G, which seems to be free in Aperture 3.1 and in Google Earth
Add another identical Application Shortcut, but with Google Earth.app as the application.


CAUTION: I HAVE NOT DONE MUCH (IF ANY TESTING) ON THIS UTILITY. USE AT YOUR OWN RISK. BACKUP YOUR APERTURE LIBRARY BEFORE ATTEMPTING TO USE IT.
To use, select one or more photos in Aperture, find the location for the photos in Google Earth, and hit the keyboard shortcut you chose.  By adding two shortcuts, you can activate it from either app.  Alternatively, you can go to the Services menu in either app and choose the workflow there.
In addition, I found a KMZ file that adds crosshairs to Google Earth by Jeffrey Friedl which makes the geotagging a bit more precise.
The script doesn't include any error checking -- or much of anything, really -- but you're welcome to use it, and even improve it if you like.  If you do improve it, please let me and other readers know using the Comments section below.
Here's to Steve Jobs actually spending more than five minutes trying to geotag some of his old photos with Aperture and realising how much it sucks!]]></description>
		<wfw:commentRss>http://gidden.net/tom/2011/01/08/using-google-earth-to-geotag-photos-in-aperture-3/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>iPhoto, Flickr and EXIF munging using Perl</title>
		<link>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</link>
		<comments>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/#comments</comments>
		<pubDate>Wed, 27 Dec 2006 18:21:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[albumdata.xml]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[exif]]></category>
		<category><![CDATA[flickr]]></category>
		<category><![CDATA[flickr::api]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[iptc]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mac::iphoto]]></category>
		<category><![CDATA[metadata]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[picasa]]></category>
		<category><![CDATA[scripting]]></category>
		<category><![CDATA[xmp]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</guid>
		<description><![CDATA[EXIF/IPTC/XMP tagging of GPS coordinates, folksonomy tags, and other goodness is a nice idea, but unfortunately, iPhoto and Flickr don't play too well together.  Couple this with the fact that any decent support those products now have is not included for photos already imported into them.  So, here are some notes resulting from some experimentation, along with the Perl code I wrote along the way.

(Note: for the rest of this post, I'll refer to all metadata stored in the image file itself such as EXIF, IPTC, XMP, etc. as "EXIF" data.  This isn't strictly correct.  However, using the term "metadata" could be confused with such data held in other files, such as iPhoto's own database.)
For Christmas, my dad bought my mum a decent photo printer: the Canon PIXMA iP5200R.  Very nice piece of kit, with good printouts, and most importantly, easy setup, with no CUPS and Windows -v- Mac issues.  Anyway, as an upshot of this, my dad wants some of my photos for building a Picasa library for her to print stuff from.  Specifically, the photos from the Caribbean holiday we had earlier in the year.
I've been playing with Picasa a bit, and I must say I love it.  It's what iPhoto should be.  It's a good deal faster for a start.  That's comparing my iBook G4 1GHz against my mum's Compaq Deskpro Pentium III 733MHz, which is a few years older.  Secondly, it doesn't use a horrible non-scalable monolithic database like iPhoto does.  Thirdly, it seems to deal with metadata a bit more sensibly.
On the downside, neither iPhoto or Picasa handle collaboration functions very well.  Both have publishing functions, and iPhoto has a read-only "sharing" function, but I mean the true sharing of photo libraries.  My mum and dad have separate computers, but they share a camera, so it would be incredibly useful to have a shared photo library which either could use.  On this count, Picasa wins slightly, because although it has no true sharing ability, there doesn't seem to be anything wrong with two copies of Picasa working on the same directory on a shared drive.  I'm not sure how it would handle conflicts though, due to the lack of locking.  For now, I'll advise my parents not to run it at the same time.
I usually manage all of my photos in iPhoto.  However, due to the lack of decent keywording and other metadata in iPhoto, I ended up adding a lot of metadata in Flickr instead.  As a result, my iPhoto library is woefully out-of-date with my Flickr library, even though it's far more complete as I only upload a subset of my photos to Flickr.  I specifically want to extract Flickr tags back into the files themselves, and ideally rip the Geotagging information I added within Flickr.
While iPhoto is drastically improved by Keyword Assistant, it doesn't store the keywords (read: tags) in EXIF form, but in its own database.  During this investigation I discovered that iPhoto does import keywords from EXIF, and also Geotagging info.  The fact that it doesn't manage EXIF is a fairly annoying flaw, and one that I hope they'll be fixing.  I've heard that Microsoft Vista now does sensible things with EXIF.  iPhoto is, quite frankly, falling far behind other solutions at this point, and I hope next month will bring a new iLife with an improved iPhoto.
So, I had a good look around the 'net for some utilities to try to clear up this mess.  I've had a play with things like Cal Henderson's Flickr::API and Dmytro Kovalov's Mac::iPhoto before, and they're not particularly mature.  Incidentally, Mac::iPhoto also seems currently broken.
Others have attempted using Applescripts.  The ones I found around the 'net are far too slow to cope with the ~8000 photo collection I have.  This is probably due to the sucky design and/or implementation of Apple Events in MacOS.
Instead, I've had a play with PerlObjCBridge, or whatever Apple's calling it.  In Perl, it's "use Foundation;".  This gives access to the Cocoa API within OS X, which I figure is probably the fastest way to manipulate Property Lists.  Since iPhoto stores at least a backup of the database in XML form (specifically Property List form) as "AlbumData.xml", we can use this to cross-reference the data.
The most critical link between my Flickr and iPhoto collection is missing.  This would be a link between each individual photo and its alter ego in the two different collections.  Since filenames aren't necessarily complete or preserved by either iPhoto or Flickr, this is relatively difficult to establish.
I've found that a reasonably good connection is between image creation time/dates.  By matching the EXIF timestamp data within the file stored by iPhoto with the EXIF data extracted from Flickr, you can get a reasonably good correlation.  At this point, it would be a nice idea to shove the Flickr URL for the image into the local EXIF data and get iPhoto to read it.  From then on, there would be an established link.
Well, I got about as far as adding the URL, tags and geocoding to the image, but I gave up when it came to getting iPhoto to read it.  There is a relatively obscure "rebuild" function in iPhoto, triggered by holding down Cmd and Opt while starting iPhoto.  This allows rebuilding of thumbnails and the binary databases (presumably) from the XML.  Unfortunately, it doesn't seem to reread the images for new metadata.  I think this would require actual modification of the AlbumData.xml file to work, which sounds like a far bigger job.
In the meantime, this proves that such a script is feasible, albeit painful.  At the moment, this is a run-once script, so it's not much use for regular usage.
SOURCE CODE:  I am supplying this code freely with the understanding that there is no warranty or guarantee.  Also, I'll go as far as to say that incorrect usage could quite easily delete your photos, destroy your Flickr account, upset Flickr, and kill your pets.  DO NOT USE THIS CODE UNLESS YOU UNDERSTAND IT COMPLETELY AND ARE WILLING TO TAKE RESPONSIBILITY FOR ANYTHING GOING WRONG.  For more details, read the README file.
The most recent version can be obtained from my Subversion repository: iphoto_flickr_exif_munge/.
I also apologise for the quality of some of the code.  It's far more experimental than I'd usually want to release, but I think it might be of use to someone like me in a similar situation.  Rather than just throwing it into the depths of my hard drive and forgetting it, I figure it's probably worth blogging.
My conclusion to all of this is that I really need to get my iBook replaced with something good enough to run Aperture or Lightroom, and then reimport the whole bloody lot.  Painful, to say the least.  I'm also hoping that Google get around to writing Picasa for the Mac.  I think I'd prefer it in the long term.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>

