Jeffrey’s “Geoencoding Support” Plugin for Lightroom

This plugin for Adobe Lightroom adds many new location-based features to Lightroom, and enhances or replaces some features Lightroom already has, including:

This plugin works in Lightroom 6/CC (and older versions as far back as Lightroom 3, though some features depend on the version of Lightroom).

The same download works for both Windows and Mac. See the box to the upper right for the download link (in orange) and installation instructions.

Table of Contents

This long page of documentation gives an overview of many of the plugin's features:


Once installed, most of the plugin's features are available via the File > Plugin Extras menu:

Geoencode...;  Fast Full-Catalog Proximity Search...;  Geoencode selected photos from Google Earth;  Pinpoint location in Google Earth;  View selected locations as KML in Google Earth;  View location at Google Maps;  View location at Yahoo! Maps;  View location at Yahoo! Japan Maps;  View location at Apple Maps;  View location at Flickr;  View location at Panoramio;  View location at;  View location at OpenStreetMap;  View location at OpenCycleMap;  View location at Multimap;  View location at WikiMapia;  View location at GeoHack (map-server directory);  View location at Microsoft Bing (old Web 2.0 style);  View location at Microsoft Bing (new snazzy interface);  View location at (Japan Only);  View location as OSGB36 (Great Britain only);  View location at Daum (Korea only);  View location at Géoportail (in French);  View location at Skog og landskap (Norway only);  View location at ICC (Catalonia only);  View location UTM coordinates;  View KML in...

The plugin's menu items are highlighted in red.... you can do quite a bit. (If the number of items is a bit overwhelming, you can configure the plugin to omit the menu items you don't need.)

The yellow arrow in the screenshot highlights the plugin's main menu item, Geoencode..., which brings up the Geoencoding dialog shown below. With it you can geoencode and reverse-geoencode your photos in various ways.

Personally, I use this geoencoding dialog so much that I assigned a keyboard shortcut to it. You can assign your own keyboard shortcuts, as described here.

The Main Geoencoding Dialog

This plugins's geoencoding dialog looks like this:

It has tabs for distinct tasks, with the dialog first opening up to the Tracklog tab, as shown above. Several tabs provide different methods to geoencoding photos (to assign latitude and longitude to photos), while other tabs provide for reverse geoencoding photos (filling in the city/state/country/location based upon the latitude and longitude).

The Tracklog Tab

Lightroom has tracklog support built in, but this plugin's tracklog support is far superior:

  • In addition to the latitude and longitude, this plugin actually fills in the altitude from the tracklog, which Lightroom's built-in support inexplicably ignores.
  • The plugin adds speed and bearing metadata to each image.
  • The plugin can automatically add map links (to a variety of online mapping services) to the metadata for each image, easily accessible via Library's Metadata panel (especially if you use my metadata-viewer preset builder to include the map link in the default metadata view Lightroom shows for each photo).
  • This plugin can handle multiple tracklogs at once.
  • This plugin has no built-in limit on the size of the tracklogs.
  • The plugin can handle almost any kind of tracklog format (not just GPX like Lightroom's built-in support) via automatic conversion with gpsbabel. The plugin also has built-in support for the incorrectly-formatted tracklog files produced by some popular phone location-tracking apps.
  • The handling of timezone offset is clear and actually works.
  • You can easily compensate for a camera clock that was off a bit.
  • You control the fuzziness for how close in time a photo can be affected by a tracklog data point.
  • You can easily view the tracklog in Google Earth.
  • You can automatically apply custom reverse-geoencode data as you apply the tracklog, so (for example) a photo taken at a park you frequent automatically gets the name of the park filled in to the location metadata item, as well as the city/state/country metadata items.
  • As of version 20161016.270, you can have the plugin try to fill in for certain kinds of gaps in a tracklog.

    The idea is that if you (for example) enter a restaurant for an hour, you might end up with an hour's gap in the tracklog, bookmarked by datapoints near the front door. In this case, a photo of your dessert taken half way in wouldn't normally get processed by the plugin, but using this fill in pauses feature set to (say) two hours and 100 meters, photos taken inside will at least get geoencoded to the entrance location. It's not ideal, but perhaps better than nothing.

    On the other hand, if you (for example) entered a subway and rode a long distance to where you had desert, then returned to emerge out from the same subway entrance, you'd not want to use this feature because the where you took the photo would be a great distance from the gap locations (the entrance and exit of the subway), even though those two locations are themselves close to each other.

This plugin supported tracklog geoencoding for years before Lightroom supported any kind of geoencoding. (I've geoencoded all my photos with it since 2008; Lightroom didn't get built-in geoencoding until 2012.) The passion and care I have for geoencoding comes out in the many features this plugin has.

The Static-Location Tab

The second tab of the Geoencoding Dialog is Static Location:

Here you can type in a latitude/longitude, cut-n-paste the URL from an online mapping service to grab the location currently shown there, import the current location from Google Earth, or import the location from the already-geoencoded most-selected image (which is useful for copying a location from one image to another or others).

This method of geoencoding was particularly useful before Lightroom added the Map Module in Lr4, but it can still be useful when you need to cut-n-paste a location from outside of Lightroom. The Help tab gives examples of some of the many ways you can indicate a location.

The Between-Points Tab

The next tab of the Geoencoding Dialog, which you'll likely never need, is Between Points:

This tab allows you to apply locations two photos between two points as if you were moving at a constant speed between them. It's useful only in fairly specific cases.

Reverse-Geoencoding Tab

The next tab of the Geoencoding Dialog is the powerful Reverse Geoencoding tab:

This is far superior to the reverse-geoencoding support built into Lightroom, so I always leave Lightroom's reverse-geoencoding support turned off (via the checkbox in the Metadata tab of Lightroom's Catalog Settings preferences dialog).

The plugin can reverse-geoencode via a service that Google most generously supplies, just as Lightroom's built-in support, but the plugin is much smarter about how it interprets and formats the results. Some of the smarts are exposed via options in the left half of the reverse-geoencoding tab.

In particular, the plugin can be configured to set the location metadata for each photo based upon the kind of data that Google returns, with priorities for each kind of name set to your liking.

The right half of the tab shows my personal settings for a powerful feature that Lightroom lacks completely: the ability to specify your own personal reverse-geoencoding locations. For example, on a private Google Maps map that you maintain in your browser, you might draw the outline around your kid's school and mark it with the name of the school. Then, when geoencoding with the plugin (or explicitly reverse-geoencoding with this tab), the name of the school will be inserted into the Location metadata for images located within the outline you drew.

The One-by-One Tab

The next tab of the Geoencoding Dialog is the sort-of-odd One by One tab:

This tab allows you to bring up a dialog where you can scroll through images one by one, geoencoding and reverse-geoencoding in various ways. It can be a bit kludgy because of the limits Lightroom places on a plugin's ability to create a dialog, but the plugin goes to great lengths to make it useful.

It's not a tab one needs for most workflows, but it can be convenient at times.

The Etc. Tab

The Etc tab has a few odd and ends:

This tab lets you do a few random extra things, including configure the kind of mapping URL gets associated with images geoencoded by the plugin (so that from Library you can just click on the link and see the location in your preferred mapping service).

The same mapping-site URL configuration applies to the View Location At Google and View Location At Yahoo! items in the File > Plugin Extras menu.

Extra Configuration and Keyboard Shortcuts

Besides the many configuration options in the tabs shown above, two overall configuration items are in the plugin manager, as highlighted by the arrows in this screenshot:

The yellow arrow highlights an option to use a smaller, terse geoencoding dialog. This may be required on systems with very small screens, as the default dialog may be too big to fully fit such systems.

The red arrow highlights the button that brings up a dialog allowing you to configure the items that appear in the Plugin Extras menu (as illustrated by the first screenshot on this page). The many View location at... items can be a distraction if you'll never use all of them, so this dialog allows you to omit ones you don't need from the menu. Here's what the dialog looks like on Windows:

The items at the bottom allow you to configure the plugin to work with any KML-handling app. The most notable KML-handling app is Google Earth, support for which is built in various way via items toward the top of the list.

The box at the left of each item appears only in the Windows version of the dialog, and allow you to set the keyboard shortcut letter for that item. See this link for more on how to set keyboard shortcuts under Windows.

It's much easier to set keyboard shortcuts on a Mac, and you don't need anything in this dialog to do it; scroll down half way on the same link for instructions.

Note: in order for changes to take effect after updating settings in this dialog, you have to reload the plugin (via the button in the plugin manager), or restart Lightroom. Also, in order to update settings in this dialog to begin with, the plugin must be able to write to its own code, which may not actually be possible depending on the folder permissions for wherever you've saved the plugin.

Inspecting Your Location Metadata

Lightroom's built-in Map Module is great for viewing your photos on a map. Adding to that, this plugin provides ways to view a photo's location in Google Earth and at 20+ online services. But the plugin provides more than just a location on a map... if you geoencode via the plugin's Tracklog tab, you also get altitude, speed, and bearing.

The plugin includes a convenient Geoencoding preset for the Metadata panel in Library and Map, as illustrated here:

It can be inconvenient to toggle between your normal metadata view (Default) and the Geoencoding view, so you may want to use my Metadata-Viewer Preset Editor plugin to select the metadata items you personally find useful, in the order you find them useful, with the names you find useful.

As an example, here's the view that I personally use in my day-to-day Lightroom work:

It includes plugin-specific items from this Geoencoding-support plugin, and from my Creative Commons plugin. It also renames many fields to match how I use them in my workflow, and orders and groups things to my liking.

Note: this doesn't seem to work on OSX 10.10 and later )-:

If you photograph in the same areas over the years, it can be very nice to quickly find other photos in your catalog from earlier visits to the same general area. The plugin's File > Plugin Extras > Geoencoding Support > Fast Full-Catalog Proximity Search menu item brings up the dialog:

which then creates a collection for you and fills it in as appropriate:

On a Mac this is extremely fast (100,000 images can be searched in a few seconds). On Windows it takes a couple of minutes, but that's still much faster than trying to do it with Lightroom's native support.

For more info, see The Joy of a Fast Photo Proximity Search in Lightroom.

Viewing Photos in Google Earth

Via the File > Plugin Extras > Geoencoding Support > View selected locations as KML in Google Earth menu item you get this dialog:

You can include photos and/or tracklogs (or neither, to just one location marker per photo). It creates a KML or KMZ file that you can share with others. The tracklog and some of the photos from My Mt. Hiei Climb Challenge 2014 outing appear in Google Earth like this:

You can see the tracklog in red, with thumbnails appearing where I took photos along the route. I'd clicked on one photo to open it up and show a larger version, along with some data about the photo.

The specific data about the photo to be shown is configured in the dialog's Custom photo description boxes, where you can specify each photo's title and caption be created using its own metadata (via the template tokens that my plugins support).

Other Google Earth Interaction

The File > Plugin Extras > Geoencoding Support menu contains two other Google Earth features:

  • Pinpoint location in Google Earth

    Sends the location of the currently-selected image to Google Earth.

  • Geoencode selected photos from Google Earth

    A self-explanatory item, this takes the current location at the center of your Google Earth view and applies it to the currently-selected image(s) in Lightroom. This is less valuable now that Lightroom supports drag-n-drop in the Map Module, but it may be useful if you prefer Google Earth to the Google Maps view that Lightroom uses. (Unfortunately, this feature doesn't seem to work for some Windows users.)

See A Better Center-Crosshair Target for Google Earth for something that makes interacting with specific locations in Google Earth much easier.

View Location At....

The File > Plugin Extras > Geoencoding Support menu contains many view location at items that send the location of the currently-selected image to an online mapping service, including:

  • View location at Google Maps
  • View location at Yahoo! Maps
  • View location at Yahoo! Japan Maps
  • View location at Apple Maps
  • View location at Flickr
  • View location at Panoramio
  • View location at
  • View location at OpenStreetMap
  • View location at OpenCycleMap
  • View location at Multimap
  • View location at WikiMapia
  • View location at GeoHack (map-server directory)
  • View location at Microsoft Bing (old Web 2.0 style)
  • View location at Microsoft Bing (new snazzy interface)
  • View location at (Japan Only)
  • View location as OSGB36 (Great Britain only)
  • View location at Daum (Korea only)
  • View location at Géoportail (in French)
  • View location at Skog og landskap (Norway only)
  • View location at ICC (Catalonia only)
  • View location's UTM coordinates

As mentioned earlier, you can configure which ones actually appear in your menu so that you can keep the list uncluttered for your workflow.

For the Google Maps and Yahoo! Maps items, you can configure which language they use via the configure urls button in the Etc. tab of the Geoencoding Dialog. For Google, you can also choose whether you want the normal street map, satellite, a hybrid view, or terrain, and whether you want the Photos layer turned on by default.

An Aside, on the Effort that I Put Into This Plugin.

Some of the View location at... items were surprisingly difficult to support.

Lightroom natively works with latitude and longitude, but that's not quite as standard as you might think. I, at least, was surprised to find out that latitude and longitude are not absolute concepts, but ideas whose practical meaning has changed over the years, both because measurement systems have improved over the years, and, well, continents actually drift (and, of course, the earth quakes).

For example, the standard of latitude and longitude used by most consumer products like Lightroom is called WGS 84. It's what GPS satellites and Google Maps use, which perhaps accounts for its popularity. But if you take a WGS 84 latitude and longitude from your GPS device or Lightroom, and plug it into the map at the venerable Japanese mapping service, it'll show you a location several hundred meters away. Just how far off, and in what direction, depends on the location.

The reason is that, which long predates Google's very existence, uses an old Japanese standard for latitude and longitude, which was set in stone figuratively (and literally) much earlier, when measurement systems weren't as accurate.

I suppose that by the time came around, the corpus of location data (the exact location of each road edge, business, street sign, etc.) was too entrenched in the old standard to update to WGS 84. Such an update would be arduous because it's not just a simple recalculation... you have to adjust for different errors made in different parts of the country.

In any case, I can't have the View location at feature of my plugin send the user a quarter mile away from the proper spot, so I had to build a system to translate the WGS 84 coordinates that Lightroom gives the plugin, to the Tokyo Datum coordinates that needs. Again, this is not a simple mathematical adjustment... the amount of error varies pseudo-randomly across the landscape of Japan. So, I built into the plugin a grid system of hundreds of sampled points across Japan, then interpolate the error for every photo's location to the nearest known grid error points. The result is that when the plugin sends you to a location at, the location is off at worst by only a couple of feet instead of a quarter mile.

Another tough one is sites that use UTM instead of latitude and longitude. The conversion is easier in that it's purely mathematical, but wow, the math is beyond my understanding. Thankfully, I don't have to understand it to program it, so the plugin can handle UTM coordinates.

Then we have Great Brittian's Ordnance Survey National Grid reference system which is another old system that can be related to WGS 84 via some very hairy math that I don't understand, but could implement.

Plugin Availability

This plugin is distributed as “donationware”. I have chosen to make it available for free — everyone can use it forever, without cost of any kind — but unless registered, its functionality is somewhat reduced after six weeks.

Registration is done via PayPal, and if you choose to register, it costs the minimum 1-cent PayPal fee; any amount you'd like to add beyond PayPal's sliding fees as a gift to me is completely optional, and completely appreciated.

Note: a Lightroom major upgrade, such as from Lr5 to Lr6, de-registers the plugin in the upgraded version, so if you want to maintain registration, a new ($0.01 if you like) registration code is needed in the upgraded version. It makes for a hassle every couple of years, I know. Sorry. See this note for details.

For details on plugin registration and on how I came into this hobby of Lightroom plugin development, see my Plugin Registration page.

Old Support Under Lightroom 2 and Lightroom 3
This section does not apply for Lightroom 4 and later

As described on the initial-release announcement in 2008, the plugin maintains “Shadow” GPS data, separate from any GPS data that may or may not be held in Lightroom's library database. The plugin has to do this because Adobe didn't add the ability for a plugin to update a photo's latitude and longitude until Lightroom 4, so for prior versions the plugin must maintain its own mapping.

The shadow data is recognized and used in a variety of situations, but not in others, so it's important to understand which is which.

These do understand the shadow GPS data:

The shadow GPS data is ignored in these situations:

  • Any image export in which the “Shadow GPS Injector” is not enabled.
  • The Metadata > Save Metadata to File command.
  • Web-gallery exports.
  • The “GPS” and “GPS Altitude” items in standard metadata views.

You can also write the shadow data into the original image files, which then can be read back into Lightroom as “real” GPS data that is understood everywhere.

Version History
( Update Log via RSS )


Perhaps fixed a complex bug with the "Between Points" feature related to timezones differing between the photos and the local computer.


Fixed the KML output when a filename had an ampersand in it.


Previous update broke the plugin in older versions of Lightroom, so fixed that.

Added bezel after fast full proximity search, and automatically switch to grid mode.


Added a momentary "Location copied to clipboard" bezel feedback when that function is invoked.

Upgraded to the embedded copy of ExifTool to version 10.50.


Woo-hoo, found a way to make the "Fast Full-Catalog Proximity Search" work again on OSX, *and* figured out how to make it work for Windows.


Upgraded to the embedded copy of ExifTool to version 10.40.

Added the following tokens to the template tokens that my plugins understand: Artworks, ArtworkTitle, ArtworkCopyright, ArtworkSource, ArtworkCreator, ArtworkDateCreated, ArtworkInventoryNum


Fix name-nesting issue with the KML preset dropdown.


Try to handle French lat/lon


Fixed a geoencoding bug WRT sparce tracklogs.


Updated links to


Added "ISO8601Date" to the template tokens that my plugins understand.

Now read/saves temperature from tracklogs, if present.

Google reverse geo seems to now be returning the state/province as a "point of interest" and as an "establishment", which seems incorrect (I've logged a bug here), so now these are ignored.

Added the ability to also set the IPTC-extension fields "Location Created" and "Location Shown".


Removed "View at Yahoo! Maps", 'cause it no longer exists.


Added the “Copy location to clipboard” plugin-extras menu item. Removed the Panoramio one.

Switch the log-sending mechanism to https.


Add some debug logging to "dismiss dialog when finished".


Be less aggressive about trying to avoid having to use a scrolling region. They're ugly, but allow stuff to fit on the screen.

The "Help" tab had gotten dorked on Windows.


Tidy up some reverse-geo results within the UK.

Added the ablity to use OpenStreetMap for reverse geocoding. I likely broke things splicing this in.

Added Weekday, Wday, weekday, and wday to the list of template tokens that my plugins understand.

Upgraded to the embedded copy of ExifTool to version 10.36.

Removed the old "Shadow Injector" post-process filter from Lr6 and beyond. It's used in Lr2/Lr3 to geoencode exported photos. Lightroom finally caught up with me in Lr4 and supported a native way for the plugin to do this, so it's not needed from Lr4. But in Lr4/Lr5 keep a spot for it to give folks time to gracefully upgrade their export presets and publish services. Finally get rid of it in Lr6 to reduce the accumulation of clutter.


Fixed a bug with the keyword tables in the LUA token.


Fix a bug in the new tracklog stuff.


Added automatic gap-filling to tracklog geoencoding.

Added the following tokens to the templates that my plugins understand: FileModYYYY, FileModYY, FileModMM, FileModDD, FileModHH, FileModMIN, FileModSS, FileYYYY, FileYY, FileMM, FileDD, FileHH, FileMIN, FileSS.

Upgraded to the embedded copy of ExifTool to version 10.26.


Added the {FilenameNumber} token to the templates that my plugins understand.

Upgraded to the embedded copy of ExifTool to version 10.20.


Extra debug logging to figure out a screen-size issue.


Fixed a font issue.


Brought the list of languages supported by the reverse-geocoding stuff in line with what Google now supports.


Updated the fast full-catalog proximity search dialog to allow a location to be pasted in, even if a geoencoded photo is selected.

Upgraded to the embedded copy of ExifTool to version 10.10.


Support the lat/lon format now given by Google Earth's "Copy View Location" (e.g. "35.024151° 135.762123°").

Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time.


When attempting the fast full-catalog proximity search, try to detect when it fails due to the database being locked.

Fixed an issue in the reverse geoencoding whereby an error could pop up if the network was down.

Added ChildOf and DescendantOf filters to the {Keywords} and {KeywordsAll} template tokens that my plugins understand.

Fixed how custom {People} formatting works with people keywords that have no birthday associated with them.


Special handling for reverse geocoding in the United Kingdom to have the second-level name (England, Scotland, etc.) fill in the "country" field. This seems to be more practially useful than having the "country" field be "United Kingdom" for all the various far-flung areas of The Realm. The "country code" remains "GB" for all.

For the same reason, for Greator London, have the "State" be London and the City be the Borough.


Special handling for reverse geocoding in Japan: for some reason Google has started to return bus stops with high-level tags like "point of interest". These are now removed because bus stops are not really points of interest.

Upgraded to the embedded copy of ExifTool to version 10.00.

Added {SpeedKPH} and {SpeedMPH} to the list of template tokens supported by my plugins.

The {People} token wasn't working properly for some keywords without a registered birthday.

20150815.260 Some combinations of tracklogs and photo times would cause error messages.
20150703.259 Photo times are such a rat's nest in Lightroom. If a photo's time has been updated in Lightroom, sometimes you see the corrected time, sometimes the original uncorrected time. It turns out that the "Geoencoding" metadata-viewer tagset was showing the original uncorrected time, so this fixes that.

Added an option to export (as KML) the data currently stored in your "Personal Mapping Locations" in the "Reverse Geo" tab. It turns out that Google Maps now stores references to your custom maps in Google Drive, and if you unwittingly delete these references not knowing that doing so also deletes your custom maps, your data is gone. I have first-hand knowledge of the surprise thise causes. Anyway, this new option allows you to recover the data that the plugin had cached.

20150522.257 Added Japanese-government elevation maps to the View At menu.

Updated the reading of personal-location-mappings KML URLs to also handle KMZ data, which Google has started unilaterally returning.

When loading a tracklog, display the location/city where it starts.


Reworked the "Geoencode from Google Earth" to also work with Earth Pro.

In the POODLE-vunerability dialog, display a raw URL of a page on my site that discusses the issue, so that folks can be independently sure that the dialog is indeed from me and not malware.


Fix to the date_diff() function supported by the LUA template token.

Updated the camera-name code to try to guess the actual camera model of Hasselblad H5D files, since in their infinite wisdom Hasselblad decided to encode three distinct models with the same internal code, making it impossible to know for sure what camera produced a given image file.

20141219.253 Google started adding "-ken", "-shi", and "-fu" suffixes to some Japanese state/city names, so they've been added to the list of suffixes to ignore when that option is selected.
20141210.252 Registration was broken on Lr2

The raw result went missing from the one-by-one reverse geoencoding dialog in the last update. Now back. Added a way to search/filter as well.

Added some debug logging to track down a reverse-geocoding issue.


Try harder to glean the "Location" from Google reverse-geocoding data.


Adds a new per-image bit of metadata: the timezone in which to interpret the photo-taken time. You can inspect (and set/update) this metadata in the Library metadata panel when selecting the "All Plugin Metadata" or "Geoencoding" views, or by adding it to your custom view built with my Metadata-Viewer Preset Editor plugin.

Geoencoding via a tracklog sets the timezone, preserving the information we needed anyway for the tracklog read.

Added some new items to the list of world timezones.

Added the ability (in the "Etc." tab) to guess timezones based upon the time and location of a photo.

Upgraded to the embedded copy of ExifTool to version 9.76.

20141019.247 Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists.
20140923.246 Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token.
20140917.245 Don't croak if given a KML file without polygons.
20140902.244 New build system
20140808.243 Added "Adjust Bearing" operation to the "Etc." tab.

Made the {GPSAltitude}, {Altitude}, and {GPSCoordinates} tokens subject to the geo-privacy settings like the other geo-related tokens.

20140731.241 Registration fix for Lr5.6
20140729.240 Previous updates broke support on Lightroom 2
20140722.239 Update to recognize "new" Google Maps urls

Fixed an issue with Creative-Cloud revalidation.


Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed.

20140710.236 Sigh, had a bug in the Creative-Cloud support.

Now supports Lr5.5+ Creative-Cloud Installs.

20140704.234 Sigh, introduced an error for some folks with the rebuild the other day.
20140630.233 added some extra debug logging to track down an issue with reverse geocoding.
20140630.232 Build-system update

Added "Subway Station" to list of possible sources of location data that Google can return.

Fixed a problem that showed up when canceling out of a bulk-reverse operation.


Added some notes to the "Help" tab of the Geoencoding Dialog, to coincide with having actually documented this plugin on my web site (finally, after almost six years!).


Added date_diff() and raw_time_diff() functions to the special {LUA} token understood by the plugin.


Upgraded to the embedded copy of ExifTool to version 9.60.

20140531.227 When combining a street name and street number while reverse-geocoding a location, try to follow the various conventions used around the world.

Added the ability to flush plugin data for selected photos.

Upgraded to the embedded copy of ExifTool to version 9.53.


Added new tokens to the template language the plugin understands: LrVersion, LrVersionMajor, LrVersionMinor, LrVersionRevision, LrVersionBuild, Location, CatalogName, CatalogPath, OperatingSystem, OS

Added new token filters: NS and LO

20140505.224 Fixed "Pinpoint Location in Google Earth"
20140423.223 Fix a location-related template-token bug introduced in a recent build.

Fixed a bug in the "smoother revalidation" stuff recently added.


Google's "New" maps don't understand the URL format its Classic maps has used for years, but I've figured out a kludge that allows the plugin go generate Google Maps urls that work with both Classic and New. If you want to apply those URLs to the plugin's Map Url metadata for all your previously-geoencoded photos, select them then visit the "Etc" tab of the Geoencoding dialog and "Set Map URLs".


The geoencoding dialog wasn't fitting on the smallest screens, so I tightened things up a bit.

Discovered that some of the fonts I used in the geoencoding dialog don't work on Windows.

The {Empty} template token wasn't working properly.

Make the revalidation process smoother, especially for folks using Lr5.4 and later.


Reverse-geocoding with a local KML file worked only when plugin debug logging was turned on; now works all the time.

Upgraded to the embedded copy of ExifTool to version 9.53.


Return support for filling in the country code. With the local KML data, the first line of the location description can now be in the form country code / country / state / city as well as the old country / state / city. Where the country code is not supplied, it'll be derived from a table built in to the plugin, or, failing that, via the reverse-geoencoding results from Google.

20140301.217 A local KML file's location was not being applied in some cases.

The new location stuff in the Geoencoding dialog caused the dialog to be too big for some small screens, so now on very small screens the whole tab is put into a scrollable window. Lightroom gives little option but for this to be really ugly, but it's better than not being able to see part of the dialog.

Fixed a "street address" bug.


Added "Street address range" and "Street name" to the list of "location" items one can use when reverse geoencoding, and fixed "Street address", which had been broken. So now a location might return "1234 Main St." for the "Street Address", or failing that, someting like "1234-1255 Main St." for the "Street address range". In either case (or when no address or range is known beyond the street name) "Street name" gets "Main St."


Completely redid the bulk reverse geoencoding code from scratch... prior code could in some cases not apply the local KML file properly. Everything's now much cleaner and more efficient internally.

Upgraded to the embedded copy of ExifTool to version 9.46.

Added support for Apple Maps (the OSX App if you have it, the web site if not).

When geoencoding from a tracklog, round the bearing to the nearest degree, so we get -90° instead of -89.999999778064°, for example.


Fix a reverse-geo KML file-reading bug introduced yesterday.


Added the ability to import/export reverse-geo settings.

Overlapping regions wouldn't always properly prefer the smallest matching region when applying via tracklog.

Fixed some bugs with network KML files, and enhanced how the plugins works with Google network KML files.


Update for OS X Mavricks.

20131031.210 The new fast proximity search added in 20130929.206 would finish silently (wouldn't report "no images found") if there were none in range, but some were sort of close.

Added the ability to reference personal reverse-geo data via Network KML. Google maps now allows you to maintain personal maps with your locations of interest marked with your own labels, so the plugin can now take advantage of that. See this page for more details.

Updated the Image::ExifTool library to version 9.39.

Stopped setting location to "?" when it couldn't be determined from Google; now just leave it blank.

Enhanced the quality of the reverse geocoding "location" data gleaned from Google.

Added ability to link to maps.

Removed Wikipedia and YouTube options from Map-link layers (because Google removed support for them).

Made the conversion to the British Ordnance Survey National Grid internal to the plugin, thanks to the kind work published by Chris Veness here.

Fixed a bug that showed up in Lr2.

20131003.208 Added the ability for Windows users to set the keyboard-accelerator for plugin-extra items.
20131002.207 The "location" field wasn't being updated properly in reverse-geocoding.

Added a new "File > Plugin Extras" menu item: "Fast Full-Catalog Proximity Search", to isolate all photos in your catalog that are geoencoded within X distance of the current photo.

In Lightroom 5 on OSX it's ridiculously fast (a second or two). On Windows or older versions of Lightroom, it takes longer... two and a half minutes to search 130,000 photos on my circa 2010 laptop.

20130927.205 My new "ellipsoidal geometry" code didn't work for some tracklogs.
20130926.204 Oops, fix a bug introduced in the previous update

The token-examples dialog had been broken. Also deprecated 'Folder' and 'Path' tokens in preference to 'FolderName' and 'FolderPath' tokens.

A fix for the previous update.


Google has turned off the old "Version 2" reverse geo-lookup, so I've removed it as an option. All reverse lookups now use the current Version 3 engine.

Changed all distance calculations from spherical geometry to ellipsoidal geometry, raising the level of accuracy from "way more than good enough" to "ridiculously overprecise". 🙂


Added ability to view locations in Catalonia at the Institut Cartogràfic de Catalunya.

Added the ability to display a location's UTM coordinates.

Better handle dates on some non-photo images.

Fixed the KW/KWE tables in template tokens; they had been broken when using load for the script.

Updated the Image::ExifTool library to version 9.35.

Google killed Latitude, so removed support for it.

20130613.200 Better support for plugin revalidation.
20130611.199 Yet another Lr5 update
20130524.198 Apparently, a recent change broke things on Lr2, which some folks apparently still use.
20130501.197 Update for Lr5
20130412.196 Build system update.
20130328.195 Fix for the registration system.

Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType.

20130209.193 More build-system maintenance
20130206.192 Tweak for my registration system

Upgraded to the embedded copy of ExifTool to version 9.15.


Added support for Yahoo Japan maps (which are very good in Japan)

Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters.

Upgraded to the embedded copy of ExifTool to version 9.09.

20121009.189 Work around a Lightroom 4.2 bug that resulted in an error when first upgrading a Lr3 catalog with Lr4.2.

Fixed a problem that showed up in the error-report reporting of tracklog start/end times when multiple tracklogs were loaded in the wrong order.

Added a JPEG-quality setting to the “Export as KML” dialog, and actually made the image-size setting work.

Added a progress dialog to the KML-file generation even when not generating inline images, if the number of files to process is large.


Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link.

20120818.186 Updated map-url format for
20120723.184 Removed an artificial limit I had on the number of tracklogs that can be loaded at any one time.
20120703.183 Added OpenStreetMap and OpenCycleMap to the kinds of urls you can assign to geoencoded photos.
20120628.182 De-encoding was broken in Lr2/Lr3.
20120614.181 Added a bunch of extra logging to try to track down some slowness in the Lr3 writeback process.
20120610.180 Apparently I need to sort the results from Google Latitude myself.

Added the ability to download a GPX tracklog from the web, and to create a GPX tracklog from Google Latitude data. The Google Latitude data is pretty bad (low frequency and low accuracy), but it's better than nothing if you have it and nothing else.


Update to handle the Mac App Store version of Lightroom.


Show a nicer error message if the network appears to be down when reverse geocoding.

Yikes, Lr2 registrations were broken again.


In Lr4+, added the ability to fill in elevation data from Google for geoencoded images. See the “Etc” tab of the plugin's geoencoding dialog.


Added support for Google's “v3” mapping API, which offers different reverse-geoencode results. Whether “different” is better or worse depends on the location and one's taste. You can switch to it in the “Reverse Geo” tab.

Tweak for Lr4.1RC2.


Enhanced the send-log dialog to hopefully make reports more meaningful to me, yielding, I hope, the ability to respond more sensibly to more reports.

Added some extra debug logging.

20120330.174 Update to handle 4.1RC
20120314.173 Tidy up a few bugs introduced recently.
20120313.172 Reworked the date/timezone handling to better handle complex situations where the camera's clock, the photo location, and the processing in Lightroom are all in different timezones. Also be more explicit in the Tracklog tab about what timezone is being used for the display of photo and tracklog times.
20120309.171 Update to the debug logging to better track down timing issues that might arise.
20120307.170 In the GPSBabel config area, added some suggestions for known devices, and on OSX, made it possible to configure the use of GPSBabel by pointing the plugin at the GPSBabel app.
20120304.169 Fixed a problem with Lr2 that I introduced in the previous build.
20120228.168 More Lr4 work

The "Between Endpoints" geoencoding could produce widely wrong results with certain timezone settings.


Massive Update

Note: upgrading to this version causes Lightroom to throw up the silly “Your catalog must be updated before it can be used with the following plug-in” dialog because I've changed how some of the underlying data is arranged.

Additionally, when first using in Lr4, the plugin now migrates the old "Shadow Data" to native Lightroom location data, and all traces of "shadow data" and the even kludgier "writeback" are gone (in Lr4).

Made “speed” and “bearing” user updatable, and “speed” searchable. (This is the guilty party for the silly catalog-must-be-updated message.)

Added the ability to search for locations via name/address/description, just like the search box in Google Maps.

More on the march toward Lr4, including upheaval in the code to handle Lightroom APIs being discontinued in Lr4. I also made the “Shadow Injector” do nothing in Lr4... I didn't remove it completely because doing so would disable publish services and export presets that had used it, so now it's just a no-op. Remove it at your leasure.

Added the {AspectRatio} token to the token templates understood by the plugin, and added the Length=num filter.

Moved the “Tracklog” tab to the front.

Fixed a bug in recognizing cut-n-pasted locations that I introduced into the previous build.

"View as KML" would fail if some images had no timestamps.

When building a KML with a tracklog, you can now opt to preserve the tracklog altitude (rather than blindly clamp to terrain), which is useful for flights.

In the one-by-one window, "copy from above" changes didn't stick.

"View Error Report" button could appear even if there were no errors.

Better handling when cut-n-pasting location values into the dialog input fields.


More tweaks for behind-the-scenes catalog access in Lr4.


Better handle cut-n-pasted static locations, and recognize additional location types.


More tweaks for Lr4b.

Updated Image::ExifTool to version 8.75.


Added some Lr4-specific debugging.

Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta

20111207.162 Had issues with the registration button sometimes not showing
20111207.161 Writing back the shadow data to the master image files could fail in edge cases.

“View Photos as Tracklog in Google Earth” didn't work if titles had an ampersand.

Added the ability to fill in shadow data from real Exif data, on the “Etc.” tab.


Notice changes to the tracklog “fuzziness” even if it's still the active data field. Previously, the old value was being used if the field was not committed when geoencoding started.

When doing a plugin upgrade, offer the ability to flush all the old copies of the plugin.

Updated Image::ExifTool to version 8.68.

Added a system-clock check and reports to the user if the system clock is more than a minute out of date. An incorrect system clock can cause problems with various kinds of communication and authentication with some of my plugins, so I've just gone ahead and added this to every plugin.


Allow the shadow injector to go ahead and inject data even if other metadata is being omitted. In this case, it injects normal GPS data as well, if there's normal data but not shadow data.

20111012.157 When geoencoding from Google Earth, try to detect when Google Earth has just started and returned a default location, and give the user a chance to abort using that default location (since the user likely wanted to use something else, or didn't intend to launch Google Earth in the first place).
20110928.156 Plugin would lock up if the same location was used for both ends of the “between endpoints” geoencoding method.
20110813.155 The Error Report could crash when used with tracklogs that spanned a long period of time, but with gaps of no data greater than a week or more.

Trying to bulk reverse-encode a photo that wasn't geoencoded in the first place caused an error.

Fix a race condition that sometimes caused an error while updating the catalog.

20110615.153 Disabling the new KML support neglected to flush the cache of already geoencoded locations, so it appeared that the KML stuff was still enabled.
20110613.152 Somewhere along the line the filter for which images to process (with/without real/shadow data) got removed from the Write Back tab. This update adds it back.
20110613.151 Don't need a placemark description for it to be recognized.
20110527.149 Fixed some boo-boos introduced in the previous update.
20110526.148 Big update for reverse geocoding. Please see “Enhanced Reverse Geocoding With a Custom Map of Locations of Personal Interest” on my blog for details.

Added Australian territory postal-codes to the “expand to full names” support during reverse geocoding.

20110513.146 Still trying to fix crashes due to bad static presets...
20110430.144 The bulk-reverse-geoencoding dialog didn't offer the “apply to all” when only “location” was selected.
20110422.143 Still trying to fix crashes due to bad static presets...
20110421.142 The XMP-writeback process was not respecting the lettercase of pre-existing XMP files on case-insensitive file systems.
20110411.141 Trying to fix crashes due to bad static presets...

Added support for automatic filling in of the “location” during reverse geoencoding. It's rarely useful in my tests, but maybe it's just unuseful for the locations I happen to work with...

Upgraded to the embedded copy of ExifTool to version 8.50

20110311.139 Added support.

Upgraded to the embedded copy of ExifTool to version 8.40.

In the reverse geocoding dialog, am now more aggressive about filling in the “location” box with an address or the like.

Handle tracklogs with negative altitude, and display negative altitudes to the nearest decimeter rather than nearest meter (because they're likely accurate depth readings taken during a scuba dive).

For Lr3+, changed the “small dialog for small screen” stuff to allow automatic screen-size detection, and defaulted to that. If the main screen seems small, the terse version of the dialog is shown. As with Lr2, the option is shown in the plugin manager.

20110113.137 Added {CroppedWidth} and {CroppedHeight} to the template tokens used by my plugins.
20101107.136 Added Skog og landskap (Norway only) to the list of “View at..” menu items.

The “Geoencode selected photos from Google Earth” feature I added a month ago wasn't undoable, which created a danger if you made a keyboard shortcut for it and bumped it by accident. If you do that now, you can simply undo it.

Made the revalidation process much simpler, doing away with the silly need for a revalidation file.

20100820.134 Discovered a bug in my plugin build system that caused horribly difficult-to-track-down errors in one plugin, so am pushing out rebuilt versions of all plugins just in case.
20100818.133 Added support for Géoportail.

Re-enabled image thumbs in the one-by-one dialog for Lr3.2 (currently available as a release candidate).

Added code to allow plugin revalidation after having been locked due to a bad Lightroom serial number.


Added a new Plugin Extras item “Geoencode selected photos from Google Earth”, which is a dialog-less method to immediately encode the selected photos with the location currently pinpointed in Google Earth. It doesn't do any writeback or reverse-location lookup to set the city/state/country, but you can do those in one shot with the normal geoencoding dialog, after having set the location for the individual photos.

On Windows ALT-F S R invokes it. On a Mac, you can set your own keyboard shortcut as you like: see the comments for version 20100620.128 below, but the command is three spaces followed by “Geoencode selected photos from Google Earth”.

20100625.130 Yikes, shaking out some more build issues.
20100624.129 Discovered a nasty build bug; pushing a new version in case it affects this plugin.

(Windows Only) Made it so that ALT-F S E; works as a keyboard shortcut for “Pinpoint in Google Earth” (along with ALT-F S G for “Geoencode”). Lr2 users will need to do some background setup, but thanks to the efforts of the author of that post, Adobe built it in to Lr3.

(Mac Only) It's a breeze to enable keyboard shortcuts of your choosing; just visit System Preferences > Keyboard > Application Shortcuts and add one for Lightroom. For Lr3, prepend three spaces to the menu item you want to shortcut to, so to make a shortcut for geoencoding, enter “   Geoencode...” (that's three spaces followed by “Geoencode” followed by three periods).

20100612.127 Oops, reverse-geoencoding dialog had broken.
20100611.126 Fixed a bug that several people had reported recently, but that I just let slip through the cracks while overwhelmed with preparations for Lr3: that automatic writeback didn't work the first time through on an image. Fixed. Also made it so that the progress bar will work again on Mac.

This version can be registered in Lightroom 3. It can run in Lightroom 2 or Lightroom 3; it does not work in the Lr3 betas.

It uses my new registration system when run on Lightroom 3, which avoids some of the silly issues of the old one. Please take care to note the details on the registration page: use of this version (or later) of the plugin in Lightroom 3 requires a new registration code, even if you had registered some older version of the plugin.


No longer try to have the writeback operation done by one process on Windows; there seems to be a memory leak somewhere that causes it to abort after a few very large images.

Updated the “View in Google Earth” to read “View selected locations as KML in Google Earth”, and added a new “Pinpoint Location in Google Earth” for quick jump-to-this-location use.

LR3: if exactly one image is selected when “View as KML...” is invoked, the plugin now asks whether to process one image or all filmstrip images.

Fix an error-reporting problem for when Google throttles one's reverse-geoencoding. Attempt to self-throttle to avoid Google having to wag its finger at us.

More tweaks in how the reverse-Geoencoding data from Google is parsed, to try to extract more information from the data.

20100423.123 Fixing an “attempt to compare number with nil” bug that I introduced in the previous version.

Don't attempt to write-back shadow data to video files, and quietly don't try to inject gps data into video files during export.


Updated the static geoencoing stuff to recognize additional latitude/longitude formats.

Added the ability to use a custom per-photo description when creating KML/KMZ files. It uses the template tokens that my other plugins use (including some things that are not yet documented... nb can be used in a conditional to check for non-blank items). There's no preset/preview mechanism yet; I know it's needed.

Updated the static-location preset mechanism to allow replacing presets (instead of adding) when loading from a file.

20100418.119 For reasons I don't understand, Google Earth doesn't seem to like non-ASCII image filenames, so the plugin now works around that.
20100411.118 Added the ability to view locations at Daum (Korea). Note: you must restart LR after installing this version for the new “view at Daum” functionality to work.
20100402.117 Should fix KMZ-creation on 64-bit Win7, I hope.
20100329.116 Added extra logging to try to track down a problem with between-endpoint geoencoding.

Lots of cleanup from v112's big updates, such that the new KML stuff might actually work now.

The “view KML in app” option had issues on OSX... fixed them. Added the ability to set up two extra axillary “view KML in app” applications (making a total of three) and tied them into the new KML dialog, and added the ability to set the title of each's menu entry. Note: you must restart Lightroom once after upgrading to or past this version for the new menu items to work.

Removed the “View location at MS Live Maps” item, since that now just redirects to Bing.

20100316.114 Yikes, a typo broke some operations for some Windows users. Fixed.
20100316.113 Had neglected to enable KMZ zipping on Windows.

First crack at real KML output, with embedded photos and an overlaid tracklog. Select some geoencoded photos then File > Plugin Extras > View Locations in Google Earth and a dialog will pop up offering all kinds of options. It's still a work in progress, but I wanted to kick it out.

Wholesale changes that attempt to honor the user's locale settings for numeric display (e.g. Europeans writing 3,14156 for pi). I've probably missed some spots, so let me know if you find some.


Be a bit smarter about reading the altitude from Google Earth, and pop up a warning dialog if the terrain layer seems to be turned off.

Fixed the “invalid function for sorting” error that had been reported a few times.

20100306.110 Added “import location from Google Earth” for the between-endpoints start and end locations.

Added a cancel button to the GPSBabel config dialog, and disabled the “OK” button if an error is detected in the input.

Fixed the spelling of “Great Britain”. Sorry 'bout that. Spelling has never been my 4-tay.

20100124.108 Reverted some changes in the logging code that seems to be causing “attempt to index upvalue ‘?’ (a boolean value)” errors for some. As far as I can tell from looking at the code, it's one of those “can't be happening” types of things, so I'm sorta' stumped as to why it's happening.

Added a checkbox to indicate whether files updated via the “write back” operation should have their modification times updated, or preserved. The default is to preserve the modification time (that is, to leave it as it was before), which is what the plugin used to do. Those with backup software that looks at file-modification dates may want to uncheck this option.

Added a “View as OSGB” option that shows the British Grid reference for the photo's location, using one of the online tools provided by Dale Abbey.

Made the “copy from above” and “copy from below” items in the interactive one-by-one page copy everything int the row, not just the latitude and longitude.

A few fixes in the one-by-one page for LR3.

Allow three-letter and three-digit country codes, in addition to the two-letter codes that were allowed before.


Added the ability to select what version of Google Earth the plugin should use. Added the new Microsoft Bing Maps (requires Silverlight) as one of the “View at...” options.

Completely changed how the one-click upgrade applies the newly-downloaded zip file, in the hopes that it'll work for more people. Rather than unzipping over the old copy, it now unzips to a temporary folder, then moves the old folder out of the way and the new folder into place. Prior versions' folders are now maintained (with the version number in the folder) in case you want to revert a version; you may want to clear them out from time to time. Of course, it won't take affect until you try to upgrade after having upgraded to or beyond this version.

20100102.105 Added Bing to the list of urls that can be configured to be automatically associated to each image.
20100101.104 Added Microsoft Bing to the “View at...” list.
20091216.103 Fixed a bug that gave the tracklog-filename-input box the attention span of a toddler, making any attempt to type a tracklog filename by hand a frustrating experience.
20091205.102 Minor internal debugging tweaks.
20091121.101 The various “View at...” items in the Plugin Extras menu didn't work in the LR3 beta. They do now.
20091108.100 More heuristics to try to coax better city/state/country results from the reverse-geoencoding data that Google (kindly) provides.
20091106.99 Fixed a second boo-boo with reverse geoencoding. Still not sure what the problem actually was (which is a bit unsettling), but I've worked around it for the moment. This is also the first build from my new build environment, so hopefully things go smoothly....
20091103.98 Oops, had a boo-boo in the previous push that sort of stopped the plugin from working. Fixed that, and a few other issues with the new things I added yesterday.
20091102.97 Reverse-geoencoding tweaks, including options to strip “City”, “Province of”, etc. from non-US names, and to strip macrons from Japanese names.
20091027.96 Lots more updates in the “Interactive” tab for LR3b. I haven't figured out how to get thumbnails in LR3b yet, so I've removed them from the UI in LR3b.
20091027.95 More LR3b updates. In LR3b, if you get an error in LR3b, “Attempt to access property “data” that's not declared in Info.lua”, when opening the Geoencoding dialog, just try again. There seems to be a race condition of some kind in LR3b that sometimes causes this problem. It seems to pop up only when “Reload plug-in on each export” is turned on in the plugin manager, and there's no benefit to normal users to having that enabled (it's a developer tool), so leave it unchecked.
20091022.94 Added a first draft of some rudimentary support for Lightroom 3 Beta. See this important note about plugin support in Lightroom 3 Beta and Lightroom 3, including future plans for features and my registration system.
20091019.93 Fixed a bug that caused a crash when trying to write back GPS data to master images whose full path contained “$” or “@”.

Implemented a few kind suggestions from Peter Krogh. The “dismiss dialog when finished” checkbox is now sticky on a per-tab basis. I added location/city/state/country to the “Geoencoding” metadata-viewer preset, and renamed the geoencoding dialog's “Cancel” button to “Dismiss”.

20090927.91 The plugin didn't do well launching Google Earth if its location on disk changed.

Fixed what I consider a bug in Google Maps, whereby they focus on nearby (and sometimes not so near by) “points of interest” when directed to a specific location, instead of focusing on the specific location. In one case they were focusing on a point 50 miles away! Finally figured out a way around it (by prefixing the latitude and longitude with “loc:”).

Made the UI for importing from Google Earth a bit better, disabling the button while it's working to let you know that it's working.

Now handles locations of the form “12°34′56.78″N, 23°45′67.89″W” in the static input location. (It mostly already did, but didn't recognize some of the many quote-like Unicode characters, so missed some forms that one might cut-n-paste from some websites.)

In the reverse-geoencoding dialog, the full address text (as returned form Google) is now selectable. On a Mac, it's the same text as before, but selectable. On Windows, I had to put it into a text input edit field to make it selectable.

Adjusted the mouse interaction with the thumbnails in the one-by-one dialog, having a simple click bring up a larger version. On Windows, control-click rotates the thumbnail. (Can't seem to get thumbnail rotation working on a Mac.)

Be more clear in the UI about when a tracklog is in the process of being inspected.

(Sorry to everyone who couldn't contact my server for the last few days... it had “issues”, that are now fixed.)

20090808.89 The release contains a change in the heuristics for reverse geocoding, favoring the “LocalityName” over the “SubAdministrativeAreaName” when two otherwise equal records contain them. Reverse geocoding is a messy, vague business because the data is messy and vague. (But at least it's there... I appreciate Google collecting the data so I don't have to.)
20090807.88 Fixed an error that popped up during reverse geoencoding. Also fixed some text-input-field wrapping issues on OSX.
20090729.87 Fixed a few misspellings in the dialogs.

Added a simple Tracklog Error Report so that you can see why images weren't geoencoded with a tracklog.


For Windows, added a keyboard accelerator for the “Geoencoding” Plugin-Extras menu item, which will become usable after you follow the instructions on the Accelerate Access to Lightroom Plugin Extras post at There's also info there for Mac users on how to set up your own arbitrary keyboard shortcuts.

Fixed that the “add map url to shadow metadata” item in the geoencoding screen would sometimes become disabled when it shouldn't.

Made the small-screen option (selectable from the Plugin Manager) reasonable again. I had forgot about it when I added all the instructions in the interactive geoencoding / reverse geocoding tab.

Some general tidying up of the dialog, thanks to suggestions from Tim Armes (author himself of half a dozen plugins for Lightroom).

20090701.84 Added some extra logging to the Google Earth interaction, to help debug when it's not working. Fixed a bug that caused the country code not to stick during reverse geoencoding if the country itself didn't change.

Upgrading the built-in version of ExifTool to include support for DNG 1.3, required to work with for DNGs made with Lightroom 1.4.

Enhanced the one-click upgrade stuff quite a bit, now detecting ahead of time when it will fail because the plugin is installed where Lightroom can't write (if Lightroom can't write to it, it can't update itself). I also added a progress bar, and now download in smaller chunks to avoid 'out of memory' errors on the larger plugins. Do remember that this new functionality becomes available after you upgrade to or past this version, when you then upgrade with it.

20090630.82 Put in checks to see whether the plugin is installed in a place that Lightroom can write. If it is, the “Configure Plugin-Extras Menu Items” button is enabled in the Plugin Manager. If not, a note is place there instead.

Added NDT (Newfoundland Daylight Time) to the list of timezones.


Well, with my boy spending the weekend on a trip with his grandparents, what I thought might be a short bit of tinkering this morning turned into a full day of tinkering....

  • The elevation was not being properly read from some tracklogs.... fixed.

  • Enhanced how the Google reverse-geocode results are interpreted. Some “city” fields that might have been left blank before may now get filled in.

  • I renamed the tab that allows you to interactively geoencode – and to reverse geocode – to “Interactive”.

  • Tweaked the UI a lot, especially under OSX where it got some long-needed TLC. Some of the effects I was able to create are hoe-hum at best, but are downright miraculous in the context of Lightroom's infrastructure limitations.

  • Added an option to select the language for reverse-gocoding results. Google's reverse-geocode stuff supports about 37 languages. (It seems that “Kyoto” in Hindi is “[c;]e;\a;]e;Π”; in Italian, it's “Prefettura di Kyd;to”.)

  • In the Interactive dialog, the red arrow that marks the most-recently-interacted-with photo would sometimes show up on two photos. Fixed that.

  • Disabled the ENTER key in the Interactive dialog... it was too easy to exit the dialog inadvertently.

  • I added the ability to set the two-letter country code in the Interactive dialog, and also fill it in when reverse-geocoding. For good measure, I also added a box so you can enter the “location” as well (e.g. “The Louvre”, “Heian Shrine”, “Grand Canyon”, “Larry's house”...). It's there for convenience, but it (the location field) is never filled in automatically by the reverse geocoding.

  • Added a note at the top of the Interactive dialog reporting how many images have changes, how many are geoencoded, and how many have full city/state/country. I still need to work on a filter, but the semantics of a filter are not obvious, so I've got to think about it a bit more.

  • I don't like how Google's reverse-geocode reports states as codes (e.g. “CA” instead of “California”). I prefer “California”, so I added an option that when turned on does the conversion. At the moment, it converts US States and Canadian Provinces, both in English and French. Let me know if other conversions would be interesting.


Added a “View KML in application” item to the Plug-in Extras Menu Configuration dialog. It's exactly like “View locations in Google Earth”, except it lets you pick the application to view a KML file. (When you invoke it, a KML file will be made for the selected photos that are geoencoded, and then your selected application will be launched, with the KML filename as its only argument.)

This item defaults to unselected, of course, but it may be included in the Plugin Extras' menu after you fill in the application.

20090530.78 Doh, fixed an “ENDPOINT_METHOD_IS_ENABLED” error I introduced in the previous version.

Fixed an esoteric bug on Windows that caused some location presets to be replaced by separator lines in the display.

Shortened the tab text on Macs (i.e. “Geoencode From Tracklog” becomes just “Tracklog”) because if all the tab text can't fit, OSX just chops it off.

Added a “view in Google Earth” link next to the “view on map” link in the tab for static geoencoding.

Now detects when a tracklog has trackpoints, but without timestamps, and reports that in the error message. Timestamps are required for geoencoding, of course.


Finally releasing something I've been working on for a long time now... a new tab that allows interactive geoencoding of a bunch of images at once (best with Google Earth running in a separate window!) and reverse geocoding, which attempts to use Google's service to fill in the city/state/country based upon a geoencoded location.

It sits as the new “Reverse Geocode +” tab in the Geoencoding dialog.

I've been working on this for ages, and in one sense it's quite polished (it has a lot of features), but one must remember that “polished” is still within the context of Lightroom's plugin API, which severely restricts many aspects of the UI. For example, the API doesn't give any way for plugins to get image thumbnails, so I have to go to disk and try to pluck one from Lightroom's preview cache. I usually get one, but I have no information about whether the image has been rotated in Lightroom (so I might not display it properly), and it could be old, and hence not reflect a recent crop or other recent develop change.

Most users don't know or care about these restrictions... they just want something that works. I try my best, but often it's not enough. I hope the API fills out in the coming years.

Anyway, in the next few days I'll get around to making screen shots and putting out some documentation, so at this point it's for the adventurous only who want to try to figure it out on their own. Hopefully I've designed it well enough that it's easy to use, but we'll see. Also, I'm quite sure there are plenty of bugs, so there'll be version churn for the next while. (If you find bugs, or have suggestions, please send them via email or, when appropriate, via the “Send Log to Jeffrey” button in the Plugin Manager.)

Have fun.

This version also has a fix for a bug that broke “import location from Google Earth” for some non-English Windows systems.

20090521.75 Fixed a “loadstring” error some users got. There are also a lot of changes under the hood to support some big new features that will be added soon; hopefully, none of the current functionality got broken....
20090518.74 For some reason, parts of the plugin fail when you try to export a photo with an altitude along the lines of -0.000000004756275857 meters. For some reason, people have been geoencoding photos with altitudes like that. Odd. Not sure what's going on, but now the plugin won't die.

Added a “show crosshair target in Google Earth” button. Once it's in Google Earth the first time, you can move it to My Places so that it's always there at your disposal. Or just let it go unsaved and re-press the button the next time you want it.

IMPORTANT NOTE FOR MAC USERS: It seems that the recently-released Google Earth 5 has dropped support for AppleScript, which means that the “import location from Google Earth” no longer works. If you wish to use that feature, you'll have to remain at (or go back to) Google Earth 4.3.


Yikes, broke support for some tracklogs in the previous push, sorry. Fixed.

“Import Location from Google Earth” was failing for some Mac users. I've greatly simplified how the plugin goes about this on the Mac, so hopefully it should now work for everyone.

Some minor UI fixes as well: added a “clear” button to the tracklog tab, and have the two “import” buttons in the static-location tab (from active image, from Google Earth) first clear out the location input boxes, so that it's more apparent when the import fails. Also rounded the altitude value returned from Google Earth to the nearest meter, because altitude values like “497.27464629276251748” include juuuuuust a few more digits than are mathematically significant.


I made it so that tracklogs that have trackpoint times without timezones will have those times interpreted in the same timezone as the photos. Any remotely reasonable GPS device will keep tracklogs with times specifically identified as UTC, but it seems there are plenty of unreasonable devices that write times without any timezone. I figure that such devices are writing whatever they think the local time is (do they even sync time from the GPS satellites?), so I use the timezone selected for interpreting the photo times (because I guess it'll be local time). A warning note is shown when this happens, which is an indication to you that whatever created your tracklog is broken. But at least now you can probably use it.

The tracklog info text was getting cut off. Fixed.

I renamed the plugin's label in the Plugin Manager from “GPS Support” to “Geoencoding Support” on the Mac, and because that wouldn't fit on Windows, “Geocoding Support”. GPS-tracklog support is just one subset of what this plugin does, so I thought the name should reflect that.

20090510.70 Added a link in the Plugin Manager to the plugin's update-log RSS feed.
20090510.69 Added OpenStreetMap to the “View At..” list. Fixed parsing of reverse-geocoding stuff.... some apostrophes were not coming out properly.
20090506.68 The Google Earth integration didn't work for Mac users with international settings that use a “,” as the fractional separator. Fixed it.
20090504.67 I gave the Geoencoding dialog layout some TLC. All the new functionality I'd added lately got hacked into the dialog fairly haphazardly, so I spent some time today to place things in a more reasonable layout. I also paid attention to the “small dialog for small screen” mode, which you can set in the Plugin Manager. It now fits in 800×600, at least on my Mac laptop.
20090504.66 I actually used the “between endpoints” feature for the first time today on real photos (as opposed to just testing), and discovered that I must have introduced a bug sometime since I last tested it. Fixed.
20090427.65 Added “import location from Google Earth” to the Windows version as well.

Added an “import location from Google Earth” to the “Geoencode Static Location” tab, on Macs. Still working on the Windows version.

Also fixed a bug “no script by the name...” bug that popped up in the previous version.


Added, a value add to Google Maps, to the “View location at...” list because wow, it's cool. I also added Wikimedia's GeoHack server, which acts like a directory of mapping/satellite sites. It's amazing to look at the same location in a dozen different satellite views.

Also tweaked out the plugin tries to update itself during the one-click upgrade process, to hopefully get things working for those few Windows users that have never had it work. Crossing fingers. We'll see.

20090425.62 Updated how the url is created, using an incantation that ends up leaving a red circle to mark the photo location.

Added two more “View location at...” menu items: one for and another for Microsoft Live Maps.

I also finally figured out a way to let the user pick and choose which items they want to have in the “Plug-in Extras” menu, so you can now do that via the “Configure Plug-in Extras menu items” button in the Plugin Manager. (It's in the Plugin Manager because current Lightroom plugin-infrastructure limitations require that you reload the plugin for changes to take effect, and you can only do that from within the Plugin Manager, so having it here makes it as smooth as possible.)

Note: if this menu-item configuration fails, the whole plugin may find itself disabled, at which point you'd have to do a manual reinstall. I've taken extensive precautions to reduce the chances that this might happen, but lacking sufficient hooks in the API, I can't guarantee it.

20090418.60 This version fixes a bunch of errors that cropped up with the experimental features added in the previous version. Also, the “add map url to shadow metadata” is disabled if you're flushing shadow data at the same time you're geoencoding, to highlight that it makes no sense to bother with that if it's going to be deleted right away. Also, internally, I now optimize that situation so that the plugin doesn't waste time writing soon-to-be-deleted shadow data.

Two sort of experimental features added this time. The first is the ability to keep the dialog open even after starting the geoencoding action, in case you want to do something else right away when it's done. It should be okay, but I've not tested every possibility.

I also updated the “between endpoints” so that it can also be used to “fill in” locations in a set of partially-geoencoded images. How it works depends on the “How to do it” setting at the bottom of the dialog:

  • Process all selected images
    This ignores any GPS data that the images might already have, and blindly fills in data by interpolating from the endpoints (interpolation is based upon location and time).

  • Process only those images that do not have “real” Exif GPS data.
    This is like the option above except that images that already have “real” GPS data (as opposed to shadow data added by an earlier application of this plugin) are not modified, and their geoencoded locations serve as the endpoints between which shadow GPS data is generated for images without real GPS data. Any shadow GPS data that images might have already had is ignored.

  • Process only images that still have no GPS data
    This treats any image with GPS data (“real” or shadow) as an endpoints between which to interpolate for images that have no GPS data. Images with any GPS data at all are not modified.

So, the second or third option would be used to “fill in” images that didn't get GPS info during a session in which some did. In these cases, the “Import locations from first/last images selected” probably makes a lot of sense.

In all cases, whatever endpoints are used for any particular photo, the interpolation is based upon a straight-line constant-speed movement between endpoints. This is almost certainly not accurate, but there's not much else that could be done automatically like this.

20090415.58 Fixed bugs that could have caused image corruption when writing to very large files such as PSDs and TIFFs in the hundreds-of-megabyte range. Parts of the plugin that update GPS data directly in image files (both the “shadow injector” during export, and the “writeback” operation) now write to a temporary file, then replace the original only if the write succeeded. As a byproduct of this change, the whole image doesn't need to be in memory at once, and so “out of memory” errors should be a thing of the past. Thanks to the exiftool author for his help in addressing this.

A common request has been to make the “Location” metadata item clickable, to bring you to Google Maps, just like the “real” GPS metadata item. My reply has always been that the Lightroom plugin infrastructure doesn't allow that for custom plugin metadata, and indeed it doesn't, but this morning a “Duh!” light went off in my head and I realized that if you don't mind having an ugly map url display right there among the metadata, Lightroom does allow that to be clicked, so I could simply insert such a url metadata item at the same I geoencode.

So, I added another custom metadata item to the plugin (and as such, when you upgrade, you'll get one of those stupid “plugins wants to update the catalog” warnings) and an option to add a map url as you geoencode. I also added the ability to configure what kind of map url gets added.... Google or Yahoo!, which country/language, satellite or map, etc.

(I'll eventually use the same configuration in my Proximity-Search plugin.)

In order to allow you to add the map url to previously-geoencoded items, I added an “Etc.” tab to the Geoencoding dialog, which contains a “Set Map URLs” button. It can be used to set the map url on all selected images that have shadow GPS data, and/or to reset the map url (in case you changed the map-url configuration).

And thus is how I spent my birthday. 🙂

The next version of my metadata viewer preset builder plugin will support this new metadata field, but for those wishing to update their tagsets by hand, the key is

20090411.56 I guess not many people use the “View at Panoramio” plugin-extra menu item, because I realized today that it's been broken for quite a while. It's fixed, but I really wish the plugin architecture allowed me to make them user configurable, so that you could have only the ones you use.
20090402.55 Fruits, already, from the debugging enhancement in the release a few minutes ago. It turns out that during GPS writeback, exiftool might bail on an image due to some unrelated issues with the image. I've now turned on the “ignore minor errors” flag, so that it can get on with what's important.

Updated the tracklog-parsing code to try to be a bit smart about what a comma means in the input string. Prior to this, a comma was a simple separator (you can specify multiple tracklogs, if you separate their filenames by commas), but that broke if a tracklog filename actually contained a comma. Now, I treat a comma as a separator only if it has what looks like dot, followed by a file extension right before it. Thus, if your filename is .../meetup with Larry, Moe, and Curly.gpx, the commas are properly treated as part of the filename.

Also, on the debugging front, it turns out that I wasn't reporting the error properly if the embedded exiftool wasn't able to write the image file during shadow-GPS injection. I think it'll now properly report the error returned by exiftool.

20090402.53 The built-in tracklog reader can now understand “routepoints” and non-UTC times. It seems that the iPhone App “GPS Log” creates gpx files of this flavor.
20090401.52 Fixed a bug that caused some spurious errors to be reported while geoencoding from a tracklog. Also fixed a bug that disallowed “View Locations in Google Earth” if images had no timestamp.
20090327.51 Added a little feature to clear out the list of location presets for someone who needs it. If the file clear-presets.txt exists in the plugin folder when the plugin is loaded, presets are flushed and the file is removed so that they won't be flushed the next time.

Wow, it turns out that the “Write Back” process was putting a “GPS Timestamp” that was off by a 31 days. This huge mistake is a result of a stupid typo on my part, compounded by a pathetic lack of testing, also on my part. I'm really sorry. I'm mortified, actually.

Thanks to Paolo Savonuzzi for noticing the problem, enduring a flurry of back-and-forth emails, and providing many megabytes of uploads until I finally got my head screwed on right.

If you've done a “Write Back” operation on images that were geoencoded with my plugin via a tracklog, you can correct the mistake by rewriting them with this or a later version. You'll want to be sure to “Save Matadata To File” before you do this write back to ensure that the write-back does not obliterate all your develop changes!! Sorry for the hassle.

20090314.49 Added an option to create a smaller geoencoding dialog, for those with very small screens. It's usable even at 800×600. It does this by eliding some instructions and warnings, using shorter (more cryptic) labels, etc. You'll fine a new checkbox in the Plugin Manager to enable small-screen mode.
20090313.48 It seems that PayPal doesn't give everyone a “Unique Transaction ID” in the registration confirmation mail; some people get a “Receipt Number”. So, the registration dialog now accepts that as well.
20090301.47 Added user presets to the static-location tab, so you can easily refer to oft-used locations. (I thought this would be a quick half-hour addition, but geez, it took all weekend, and I'm still not happy with how unsettled the UI is.) Also, fixed a bug that caused a plugin crash if my server couldn't be reached during registration.
20090219.46 Fixes the “Access to undefined global: ReloadPluginFile” error. Sorry 'bout that. Also includes a few more UI tweaks.
20090216.45 I belatedly realized that most people who use my plugins probably don't follow my blog, so will be surprised to notice some day the note about registration. So now I've added a popup that should show up the first time someone upgrades from a non-donationware version to a donationware version, just to alert them to the situation. Less surprise is a good thing.

With this version I'm moving my plugins over to a “donationware” model, in which registration eventually becomes required (and an eventual donation hoped for :-). For details, see Lightroom Plugin Development: Now With Added Encouragement. (For info about what drove this decision, see What To Do When a Hobby Becomes Work?)

Plugins no longer expire, and correspondingly, I will not pay much attention to reports of bugs that have already been fixed, so please check your version and the version history before submitting bugs or feature requests.

There was a lot of internal upheaval in the code, so I expect that some boo-boos my surface. If something breaks for you with this version, please let me know, but until I fix it, feel free to revert to the previous version.

One bug fix in this release: I fixed, I think, the inability to write data to images whose filenames have non-ASCII characters. Working on this bug is a perfect example of why I'm moving to a donationware model: this non-ASCII-filename situation doesn't impact me, personally, but I spent 8+ hours today tracking down the problem (Windows is horrid) and MacGyvering a solution. I hope it works for everyone.

20090129.42 Yikes, if you invoked the “View in Google Earth” and the plugin had to ask you where Google Earth was because it couldn't figure it out itself, it didn't remember the location, so asked every time. Fixing a typo should take care of that. Also, a small housekeeping update for the new locales supported by Lightroom 2.3.
20090125.41 Corrected a few misspellings.

The shadow injector doesn't seem to work on Windows when the destination images are written to a \\hostname share, so I now disable the export if it detects this situation. If you map the share to a local drive letter, it should be able to work. If anyone knows why cygwin Perl can't access a filename like “\\host\path\file.jpg”, please let me know.

I also updated the injector section's synopsis (the “enabled”/“disabled” note that appears when the section is closed) to be more meaningful.


It turns out that my speed calculation had a pair of typos that caused its results to be off by a factor of almost 13(!).... but only when a photo's time does not fall directly on a tracklog point. I never noticed this because all my tracklogs are made at one-second intervals. Doh!

If you've used previous version of this plugin to geoencode photos taken at speed with tracklogs kept at anything other than a one-second interval, you may want to re-encode them to update the speed.

Note that you can apply more than one tracklog at a time, so it's a simple matter of selecting all the images and then selecting all the tracklogs, letting the plugin figure out which goes with what. Just be sure that all the images times are from the same timezone. Still, it's a pain, so sorry.

I also fixed a small issue with the “browse for tracklog” dialog.

20090120.38 It turns out that doesn't use the modern WGS-84 that most everyone else uses because MapFan uses the older “Tokyo Datum” geodetic that is off by 400-450 meters (which is pretty amazing that it's that close, because it was developed in 1918). Japan only moved to WGS-84 in 2002 with the introduction of JGD2000, but since MapFan predates that, they couldn't switch over without invalidating all their old URLs. (Of course, they could just change their URL format and key off that which geodetic to use.) Anyway, I the difference between the two is not constant, so I sampled every quarter-degree intersection in Japan to derive a huge grid of points and differentials, and now adjust appropriately, so the locations are now dead on. I'm sure no one but me cares about this, but there you have it.
20090116.37 It turns out that the automatic upgrade stuff doesn't work if the plugin folder has been renamed from its original. That should generally not happen, but it's possible, so the plugin now checks its own location reports the issue to the user if it finds it.

Figured out how to move some stuff around to conserve some height, making the Geoencoding dialog shorter. This'll help those with small screens.

Realized that the “New version available” notice never actually showed up, so fixed that.

Added the ability to automatically call GPSBabel on non-GPX tracklogs, if you have it installed and configure the plugin with the appropriate command-line arguments.

Added more debugging-log stuff to the 'Upgrade Now' button action, to try to understand why it doesn't work for some people.

20090111.35 Added “View Location at” to the list of “View at...” File-menu links. It works only for locations in Japan, but the quality of their maps is excellent – sometimes much better than even Google's.
20090110.34 Added a checkbox in the Plugin Manager to turn on enhanced debugging (more stuff in the plugin's debugging log), and added a button in the same place that sends your log to me. Particularly for “the upgrade button doesn't work” and “error while uploading” type issues, this should be useful for debugging.
20090107.33 Can now handle Google-map urls that result from an address lookup. Updated the ExifTool install that the plugin uses to Version 7.60, which corrects some problems that a few plugin users were seeing while working with certain Canon image files.
20081229.32 Can now write back XMP for images in folders whose names contain an apostrophe.
20081227.31 Now uses both waypoints and tracklog points if the GPX file has both. Spruced up the informational message displayed when the tracklog+fuzziness+skew doesn't cover any selected photo (to show how far away the tracklog is, and suggesting increased fuzziness or a timezone check, when appropriate).
20081225.30 This plugin's Christmas present is some additional error checking while attempting to open a tracklog file.
20081223.29 Bumping back the expiration date.
20081215.27 Properly handle interpolation between two points with the same latitude/longitude.
20081210.26 Fixed a problem whereby a tracklog was considered inappropriate for a group of images even if the “fuzz” should have been enough to allow it.
20081206.25 Didn't work with images that had no timestamp. Sorry. Fixed.
20081205.24 Oops, the “view locations in Google Earth” was broken unless you had all five of my export plugins installed (which means that it was likely broken for everyone but me.... oops!). Fixed.
20081204.23 Enhanced the “View location in Google Earth” in various ways:
  • You can apply it to multiple images: one .kml file will be created with placemarks for all the images.
  • The .kml filename is now derived from the image filename (the first image, timewise, if multiple are selected).
  • If the image has been uploaded to Flickr/Zenfolio/SmugMug/Facebook/PicasaWeb with one of my plugins, the url of the image is included in the placemark.
  • More info is included in the placemark, including title, caption, and date.
I also placed a “view tracklog in Google Earth” button in the “Geoencode from Tracklog” tab... it's just something I'm playing with.
20081204.22 Now handles waypoint GPX files as well.

In this version I completely redid how dates and times are interpreted, which affects how tracklogs are applied to images. It turns out that in previous versions, the plugin was off by an hour when applying images to the tracklog when the image timezone (the one you set via pulldown in the geoencoding dialog) does not represent daylight saving time, but the date of the image if interpreted on your current local computer-system time would be in daylight saving time. Arrrgh.

Let me rant for the moment and say that The EXIF standard for photographic metadata is MORONIC. It has all kinds of fields for image-related date/time pairs, but absolutely no provision to encode what timezone those date/time pairs have been expressed in. A few years ago, I asked a member of the committee who created this standard why there was no provision for timezones, to which he essentially replied “why would anyone need timezones?” (He actually replied, in much better English than the Japanese with which I asked, “We would appreciate if we could have more information about in what case did you feel inconveniency for the lack of time zone information and for what purpose do you utilize the time zone code.”). Arrrrggggh, if you have to ask.... (sigh).

Lightroom tries to overcome this basic inability for photos to identify when they were taken, but Lightroom, too, has its time-related issues.

In any case, I now do all the date conversions by hand, so to speak, and so hopefully it's correct, but at the same time, wholesale changes opens the door to new bugs....

20081126.20 Several things:
  • Having heard no issues of the plugin destroying data or raiding the liquor cabinet at night, I've gone ahead and removed the dire “THIS IS BETA” warnings.
  • I added, though, a warning to the “Write Data Back” tab to indicate that when you “Read Metadata From File” to suck in the GPS data, it could also erase any metadata changes you've made to the file, and/or any develop edits. I'm not exactly sure the situations where this happens, but if you make a habit of geoencoding right after image load, there's no problem.
  • Added the ability to write back changes to the image files as geoencoding happens.
  • Added more debugging stuff to the log to help track down issues.
20081124.19 Perhaps fixed a problem whereby the “Upgrade Now” button didn't work for some Windows users. We'll see whether it works when those users upgrade from this version to whatever version is next.
20081122.18 No problems from the upheaval recently, so pushing back the expiration a bit.
20081118.17 Be smarter about what folder to start with in the open-tracklog dialog.
20081117.16 Fixed “View location at Yahoo Maps”, which was actually sending the browser to Flickr. No other new functionality in this version, but a huge upheaval in the underlying code to repair an unfortunate design choice I made early on in the development that had limiting consequences I'd not foreseen. There are likely bugs introduced in this version, and as such, it has a short expiration date to encourage updates as those bugs are reported and fixed. If you do run into an error, please send (via email) the log referenced in the upper-right of the Plugin Manager. Thanks.
20081114.15 A file-related error message was not reporting the filename
20081113.14 Added “enabled” to the shadow-injector status line when the thing is enabled.
20081111.13 Fixed a potential crash related to reverse geocoding.
20081110.12 Bunch of stuff:
  • Handle tracklogs with sub-second time granularity.
  • Fixed a couple of bugs that caused a plugin crash.
  • Made it clear that the center of a Yahoo!/Google map url is what's used.
  • Made sure to ignore the SLL= part of a Google map url ('cause that's the original search location, not the center of the current map).
  • Removed the flashing from the data-writeback warning, because no problems reported yet.
  • Added the ability to import the location info from the active image into the static-location fields, so that you can easily copy a location from one image to a bunch by selecting the bunch and ensuring that the one with the location is the “most active”. When using the “between endpoints” tab, you can import from the first/last of the selected images.
  • Fixed a bug that caused the reverse geocoding of one of the start/end pair (of the “between endpoints” tab) to fail.
20081107.11 Oops, introduced an error in the previous push that disabled tracklog use altogether. Doh! Fixed.
20081104.10 The plugin would crash if pointed at an empty tracklog. Fixed.
20081102.9 Oops, fixed a major bug introduced in the previous release.
20081102.8 All kinds of changes, including a lot of internal twiddling. I've added a first pass at writing back the shadow data to image files. It seems to work, but I can't stress enough that you should save backups of images before you test it. The dialog is getting pretty big, but it still fits on my MacBook screen, so I have hope that it's not too big for anyone. I've also changed the database field that I use to access the photo time, as per this comment. The Exif standard is so flaky (or I am) that it's never clear what these almost-identical fields actually mean, so hopefully this'll all just work.
20081031.7 Just playing around, I added some reverse geocoding to some of the input things, so that after specifying a location, it'll try to describe that location. It uses Google Maps new reverse-geocoding stuff, which is sort of sketchy at this point, but it's sort of cool to see it pop up. When you load a tracklog, it'll try to describe the starting point, and also tell you how far away the furthest point of the tracklog is.
20081031.6 Attempting to work around a Lightroom problem that causes the shadow data to now show up in the “Geoencoding...” tagset. The result is that the tagset label is different (it's now the name of the plugin, “GPS Support”, rather than the more descriptive “Shadow GPS Data”, but that's the best I can do until I figure out what's tickling this problem.)
20081031.5 Yikes, introduced a bug in the previous release that broke the on-export injector.
20081030.4 Coded around a Lightroom bug that artificially capped the “fuzziness” value at 100 on a Mac
20081030.3 Now handles urls from non-US versions of Yahoo! Maps. Fixed a few bugs in the latitude/longitude parsing code, so that it now actually handles hand-written lat/long pairs the way it was documented to handle them before. Added “view on map” buttons near the lat/lon input boxes, so that you can verify that the location has been understood by the plugin. Added the ability to compensate for an incorrect camera clock when syncing to a tracklog. You should really just correct the image times in the first place, but I've added the compensation here for those wishing to use it.
20081030.2 Now properly handles the dialup version of Yahoo! Maps when accepting a url for a location.
20081029.1 Initial public beta release

The 30 most-recent comments (out of 488; see all), most recent last...

Hi Jeffrey

Can you please comment on how you keep your time zone data in sync when you edit files. I am using non-exif data, and every time I export to Photoshop and then re-import that photo to Lightroom, I have to remember to synchronize the metadata fields. This is basically an easy way to lose information, because if I forget to synchronize on import, then it is difficult or impossible to synchronize the data later. Do you have any tricks that I can learn from?

FWIW, I have been using the Instructions field to hold a string with the time zone, but this has its own set of issues. Among them, it is basically impossible to search this string in Lightroom. But at least that field is kept when I export to Photoshop and reimport into Lightroom.

Timezone stuff is so screwed up with image metadata. Sigh. The people who created the initial metadata standard (a consortium in Japan) were total idiots, and Adobe has continued the tradition. Sigh. To answer your question, I don’t know. The plugin keeps the timezone as a bit of private per-photo metadata, and it’ll be replicated to the copy if you “Render in Lightroom” when going to Photoshop, but beyond that maintenance is all manual. —Jeffrey

— comment by Alan Harper on September 27th, 2016 at 5:18am JST (7 months, 26 days ago) comment permalink

Hey Jeff – thanks for this plugin! I’m trying to use my tracklog to geocode some files and it’s failing on roughly half of them. The error report has things like:

Photo at 2:39 pm (Sat, Oct 1, 2016 UTC-4): 2016-10-01_0316.CR2
	Tracklog has datapoints 3 minutes (186 seconds) earlier, at: 43.950270, -79.973191
	                    and 5 minutes (284 seconds) later, at: 43.950245, -79.973195
	The two points are separated by 3 meters (3 yards).

But the recorder has points every 5 seconds, and that shows up in the raw data viewed as well. How come it isn’t finding these other points? I’ve verified the times of the files and the timezone to use, so I’m not sure what’s going on here… Any help appreciated!

I wonder whether it’s an issue with how the GPX file is created. Would you mind mailing it to me? —Jeffrey

— comment by Kaitlyn on October 3rd, 2016 at 12:27pm JST (7 months, 20 days ago) comment permalink

I’m getting the “Database locked” message too when I try to use the “Fast Full-Catalog Proximity Search.” I am using Lightroom CC 2015.6 and Mac OS X El Capitan 10.11.6. Let me know if I can help you track this down. This is the first time I have tried this command, so I wouldn’t know if it worked in the past.

It seems to have broken with OSX 10.10 or 10.11… not sure which. I’m digging around for a workaround….—Jeffrey

— comment by Alan Harper on October 9th, 2016 at 12:17am JST (7 months, 14 days ago) comment permalink

Hi Jeffrey,
Thanks for the great plugin!
Is there a way to embed the GPS data into the actual photos’ metadata?
A way that will not change the photos’ creation time?

Thanks from Israel!

I think if if you “Metadata > Save Metadata to File” it would do what you want, but I haven’t tested whether it leaves the file creation time alone. If not, you may need to then run an exiftool pass to reset the file date to the creation date. —Jeffrey

— comment by Koby on October 10th, 2016 at 5:00am JST (7 months, 13 days ago) comment permalink

Thanks Jeffrey!
It worked! and the creating time hasn’t changed!
Thank you very much! -Koby

— comment by Koby on October 11th, 2016 at 2:10am JST (7 months, 12 days ago) comment permalink

Hi Jeffrey,
I have a feature I think may be useful for your great geoencoding plugin:
When geoencoding the pictures from my last trip to Sicily I noticed some pictures didn’t get GPS data, due to lack of GPS data in some time intervals in the GPS log. I noticed that those pictures where mostly on occasions when I entered some shops or restaurants and the GPS signal was missing. But then the log resumes roughly from the point it left off when I left the shop (I saw a difference of about 3 meters on some occasions I’ve checked).
I wonder if you could add some mechanism that will identify cases where there’s no GPS data for some interval but the last location before this interval and the first location after this interval are very close to one another and in this case assume that the position stayed the same for the entire interval and therefore the plugin would give the entire interval the last known position (or interpolation between the points if you want to do the math :)). I would say 5 or 10 meters difference could be regarded as close enough, but this could be left as a parameter for the user to choose (because longer periods without GPS data could cause longer wakeup time for the GPS, so when you finally get out to clear sky during this time you walk longer distance from the shop/restaurant until the GPS has fix. I could try and measure some statistics from my last log to calculate distance for different periods of non GPS signal if you want me to).
If possible for you, and if you think this is useful (like I do), I would perhaps put this as an optional feature for the user to choose if he wants this or not (just in case some users won’t want this).
What do you think…?


The problem is that while you’re out of GPS range taking pictures, you could move very far from the last signal. For example, entering a subway system and moving to far-flung places underground, then returning back to the surface at the same station. The GPS pattern would look identical to the case you mention. It could be made as an option, but the effort doesn’t seem to justify the can of worms it’d open up, sorry. —Jeffrey

— comment by Koby on October 13th, 2016 at 7:10pm JST (7 months, 9 days ago) comment permalink

Thanks Jeffrey for your honest reply. I agree this can be confusing in some cases, but I think that in most cases this could be useful. I may try to write an offline tool that will receive a GPX file and will output a GPX file with GPS gaps filled. I would then be able to use this file as an input for your plugin.
Let me know if you find it useful and I will send you the tool if I succeed to do it.

You can co that easily with GPS Babel, if you like. —Jeffrey

— comment by Koby on October 14th, 2016 at 1:38am JST (7 months, 9 days ago) comment permalink

Do you mean GpsBabel has tools for filling GPS gaps, or should I use it just for reading/writting the GPX files…?
Thanks -Koby

You can use it to fill in gaps prior to loading the GPX file into the plugin. —Jeffrey

— comment by Koby on October 14th, 2016 at 9:51am JST (7 months, 9 days ago) comment permalink

Thanks Jeffrey! This looks great, but it implements a slightly different gap filling condition than the one I intended: It interpolates the points for any time gap that is more than the specified interval, regardless of the distance between the points…
This misses the point I intended.
I saw there’s an option to interpolate by distance, but saw only max distance and no min distance (i.e. interpolates if the distance is BIGGER than specified and not like I want it, if the distance is SMALLER than specified).
Do you know other operations in GPS Babel that can perform the condition the way I wanted it, which is much safer…?
Thanks! -Koby

Ah, good point. I’ve gone ahead and added it, though it defaults to being turned off. You’ll find it on the Tracklog tab. —Jeffrey

— comment by Koby on October 15th, 2016 at 6:06pm JST (7 months, 7 days ago) comment permalink

Thanks Jeffrey,
I’ve managed to write a small tool that does exactly what I wanted, using Python.
It can run as a command line and get the input and output GPX filenames, minimum time interval to fill, and maximum distance difference allowed to fill. I’ve checked it on my data and it worked fine.
Let me know if you want me to send it to you, in case you find it useful or can help other users.
I can compile it to EXE for users who don’t want to install Python on their machine.

— comment by Koby on October 16th, 2016 at 6:58pm JST (7 months, 6 days ago) comment permalink

Is there any way to pull GPS data from Flickr or other sites that are linked with lightroom and your other plugins? It seems that I have somehow lost all my geotagged data from lightroom, but it still remains on the web.

I haven’t built that, sorry. The “somehow lost all my geotagged data” sounds very scary… I hope you can get to the bottom of what happened! —Jeffrey

— comment by Jesse Niemand on October 24th, 2016 at 9:45pm JST (6 months, 29 days ago) comment permalink

Hi Jeffrey,

I’ve started using your LR plugin for reverse geocoding purposes. It does its job very well. Thank you for creating and sharing.
I’ve found out that openstreetmap data source performs better than google’s. Example:
You get a lot more detailed location with openstreetmap, than with google maps. From my example I get exact path and viewpoint with openstreetmap “viewpoint”:”Paklarić Fort”,”path”:”Paklarić Educational Trail”, while google returns only meaningless address. Is/Would it it be possible to change reverse geocoding provider in your plugin?

Kind regards from Slovenia,

I just added this in, though probably broke things doing so. Give it a try. —Jeffrey

— comment by Tadej on November 17th, 2016 at 5:08pm JST (6 months, 5 days ago) comment permalink

I’m in Spain and having a problem with UK reverse lookups. For example, with 53°54’12” N 1°42’20” W, the State/Province and Country both get filled with England. I was expecting the State/Province to be West Yorkshire. Many thanks and please keep up the good work.

Yeah, Google things the “country” is “United Kingdom” and “state” is “England”. I’ve special-cased a fix in the version I just released. Thanks for the report.—Jeffrey

— comment by Mike Naylor on November 24th, 2016 at 7:44pm JST (5 months, 28 days ago) comment permalink

UK Country and State/Province now working properly on latest release (20161126.273). Now, if only Google could be a little more accurate with the Sublocation.
Many thanks,
Mike in Spain.

— comment by Mike Naylor on November 26th, 2016 at 11:11pm JST (5 months, 26 days ago) comment permalink

After updating the buttons to do the geotagging seem to have disappeared. Any idea whats up?

Writing from va, usa.

Apparently the plugin thinks your screen is big enough… it’s probably an issue with how high-res screens are reported, which seems to be an issue in flux. I’ve just pushed a new version of the plugin that’s less aggressive here. —Jeffrey

— comment by Michael on November 29th, 2016 at 4:18am JST (5 months, 24 days ago) comment permalink

Just updated to 20161129.274 and now the Reverse Geo tag doesn’t fill the frame anymore, so it needs a scroll to get to the action button, no matter which Terse setting used. Plus, the “dismiss dialog when finished” checkbox has never had any effect for me.
Mike in Spain.

Unfortunately, Lightroom’s plugin infrastructure makes large dialogs problematic, and the best one can do design content that you hope will fit on every user’s screen (even though you have no information about their screen, how large their fonts are rendered, etc.). The end result is something that’s ugly for everyone, but also hopefully at least works for everyone. About “dismiss dialog when finished”, that’s a surprise. Could you give it a try with the new version I just pushed out (20161206.275 or later) and send a log if it doesn’t work? Thanks. —Jeffrey

— comment by Mike Naylor on December 4th, 2016 at 3:54am JST (5 months, 19 days ago) comment permalink

the latest update presents a dialog box that is too big for my screen (4k screen with mgnification)

There’s an option in the Plugin Manager that should force smaller dialogs if the plugin couldn’t detect it properly. —Jeffrey

— comment by john on December 11th, 2016 at 1:42am JST (5 months, 12 days ago) comment permalink

terse dialog screens is enabled… This worked before recent update…

Please send a plugin log along with a description (or perhaps a link to a screenshot). —Jeffrey

— comment by john on December 12th, 2016 at 3:12pm JST (5 months, 10 days ago) comment permalink

First of all – love the plugin! Makes my life a whole lot easier when I finally get around to geotagging my photo’s to be able to import more than one track!
Anyway, I was going to suggest using the OSM API, but see someone beat me to it – and it’s presence in the latest version is certainly welcome – it seems to provide a more reliable, sensible output here in my part of the UK (Plymouth).

I am however curious as to how the list of options for the “fill in location” option of reverse-geo are chosen? It seems to me that there’s a somewhat arbitrary list of not particularly useful things the plug-in is looking for, which in my case only results in one or two of them finding anything (normally road and suburb). As an example, a lot of my photos have been taken in a local national park (Dartmoor, specifically). Given the nature of National Parks, I would have thought they’d be a common option for “Location” tags, particularly among landscape/nature photographers.
Meanwhile the plug-in is looking for (among other things) “Electronics”, which from what I can tell from the OSM Wiki would only be looking for electronics shops; not generally somewhere I see a lot of photographers, except when parting with their money for a shiny new piece of glass!
Depending on how the list is chosen, I personally would be looking for; boundary=national_park, natural=peak, place=locality, place=town and maybe place=village.

From what I’ve seen of your blog, the natural=peak might be particularly useful for you, and I’m sure with a quick look through the OSM wiki you could find some more useful tags yourself (maybe temples/religious buildings in general?)

Thanks again for the excellent plug-in and I hope my feedback is helpful!

Not sure how Electronics got in there, so I’ve removed it. The plugin just asks OSM for info about a lat/lon pair, and OSM sends what it wants (including, apparently, info about electronics stores, but not mountain peaks). Not sure I can do much here. )-: —Jeffrey

— comment by Will on December 23rd, 2016 at 1:18pm JST (4 months, 30 days ago) comment permalink

Just installed latest version of plugin 20161206.275 under LR CC 2015.8 on Windows 10. Trying to Geoencode Static Location -> Import Location from Google Earth (Google Earth v. is running and pointed at my desired locatin) and plugin doesn’t seem to pick up coordinates. I’m happy to send more information and logs if you need them. Thanks.

Google Earth stopped supporting what the plugin is trying to use. It still seems to work for many lucky folks, but equally mysteriously doesn’t work for many others. I’ve never been able to figure out why. —Jeffrey

— comment by Sergey on December 29th, 2016 at 7:46pm JST (4 months, 24 days ago) comment permalink

My last request seems to have been lost : Geoportail has changed recently, breaking all previous links, an update is needed. Thanks.

Oops, yes, sorry, I missed it. I’ve update the plugin… it should work again. Thanks for the report.—Jeffrey

— comment by Alain on February 8th, 2017 at 5:53pm JST (3 months, 14 days ago) comment permalink

Thanks for the French “O” (Ouest/West). I can save time when manually copying/pasting locations. Not perfect as it used to be but that’s already something… Cheers

— comment by Greg on March 5th, 2017 at 8:33pm JST (2 months, 17 days ago) comment permalink

I’m using the latest version (20170309.284) and the Geoencode page won’t fit on my screen and has no scrollbars. It makes it a bit hard to click on the “Go ahead and do it” part of the form 🙁

I am running W10 home v1607 (Microsoft Windows [Version 10.0.14393]) fully patched and LR CC (2015.9) If you need more info, just let me know… I’d be happy to help get this working (obviously)

Hope to hear from you soon!


Would you mind sending a screenshot ( and a plugin log? The problem here is that Lightroom doesn’t make it easy to know how big something will appear on the screen, so the best I can do is come up with heuristics for what seems to work. Clearly it’s not working for your system. With high-res displays, sometimes the effective screen resolution is half that of the actual screen resolution, and that silently screws everything up. —Jeffrey

— comment by Brian Hampson on March 28th, 2017 at 3:51pm JST (1 month, 25 days ago) comment permalink

Self solved the above issue. (couldn’t figure out how to reply to a comment)

Windows 10 seems to think that I want things to be %150 of actual size on my 13″ laptop, so it at one point in the update cycle figured that was the setting it would apply (and tell me was recommended)

I reset the zoom to %100 for everything and lo and behold – things fit as they should. Perhaps this can serve as a word of warning for others that run across this.

Thanks again for an awesome plugin!

— comment by Brian Hampson on March 29th, 2017 at 11:04am JST (1 month, 25 days ago) comment permalink

I just wanted to say that Between Points is my favourite feature! How on Earth do you think no-one would ever use it? It’s essential for owners of cameras with no GPS installed! Pick two photos you KNOW locations for, and – after geocoding Between Points – just adjust photos’ locations manually, now that they’re roughly in the right area. It’s just too bad we can’t draw a spline on the map to define the path ;P
(Polish traveler here, BTW.)

My cameras don’t have GPS installed… I just make sure that their clock is correct, and then link up photo times with times in a tracklog I record on my phone or with a standalone GPS receiver. —Jeffrey

— comment by Sinus on April 9th, 2017 at 2:49am JST (1 month, 14 days ago) comment permalink

As a matter of fact, it would be a very useful addition if the Between function could:

(1) add a keyword (“geotag-between”, for example) for when a geotag is added using the function,
(2) be set to overwrite only geotags in photos that have the “geotag-between” keyword,
(3) upon detection of multiple manual geotags (not keyworded by (1)) split the job into segments and process each segment separately.
This way one could geotag a beginning and end photo out of 100, see them mapped in a straight line, guess the locations of several more photos basing on the Between mapping and correct them manually (removing the “geotag-between” keyword), and then re-run the whole set, now being split into several straight lines.

Of course, it’s already possible to do this by manually running the process on each section. This would merely make it easier. 🙂

— comment by Sinus on April 9th, 2017 at 4:51am JST (1 month, 14 days ago) comment permalink

1. Pretty sure there’s a minor bug in the View selected as KML in Google Earth. When the filename contains an & the KMZ is created okay but you get an invalid token error on load into Google Earth.

2. An option to create a KMZ file that loads into Google Maps instead of Google Earth would be nice. The current KMZ loads into Google Maps fine but you only get icons, not photos. If the plug in allowed writing the photos to the web (Google Drive or Dropbox or …) instead of local storage it might work??

Bill from Sedona, AZ, USA

You’re right about the first point; thanks for the heads up. I’ve just pushed a new version out. I’ll add the second item to the todo list, but realistically it probably won’t get attention any time soon, sorry. —Jeffrey

— comment by Bill Belvin on May 6th, 2017 at 7:57pm JST (2 weeks, 2 days ago) comment permalink

Hi Jeffrey,

Thanks for your blog and your pictures of Japan, and other places. I love it.

I use your plugin but have a problem to solve, if possible.

When shooting in B&W, I use a Garmin etrex Vista HCX and for each picture I generate a waypoint.
How can I use the .gdb or .gpx file with all the waypoints to geoencode the scanned pictures.

At present I use the route file to geoencode the pictures (date and time updated with jb CaptureTime to Exif)

Thanks again for your great job.

I don’t think waypoints have timestamps associated with them, so I don’t see an easy solution. You might manually view the waypoints in Google Earth, and copy/paste the location from there to the plugin. I don’t see a more-automated way without a tracklog. —Jeffrey

— comment by Roger on May 16th, 2017 at 4:46am JST (1 week ago) comment permalink

Hi Jeffrey,

I am looking for a solution to take the location fields that I have entered, street number, street, city and have a program find those addresses and add gps coordinates added to the metadata. I have, over the years, diligently added addresses to photos for a client, but not geotagged them. I use the primary address for the job even if I shoot the surrounding area. I could search each address in lightroom map module and drag the images on to the map, but I was hoping to automate this process somehow. Am I correct that I CANNOT do this with your plugin and if so, do you know if this is possible? Many thanks,

Yeah, sorry, I don’t see a way to automate it. )-: —Jeffrey

— comment by Oliver RR on May 17th, 2017 at 6:35am JST (5 days, 18 hours ago) comment permalink

Maybe a bit of an outside case, can’t think of any of your plugins that would handle it, but:

I have thousands of photos all taken in UTC+13 (NZ). I then traveled across multiple timezones, DST kicked in, and some regions didn’t observe DST… so they are all left in NZ time, when they should actually be adjusted. I applied geotagging given they were all a consistent timezone, but now I’m wondering if there is a way to dynamically correct all their capture times?

They have GPS data, EXIF data, and an input timezone of UTC+13. Any way they could be adjusted knowing this information through some online date tool or something?

It may be possible, but it’s not likely. Timezones change all the time (their areas and the rules that govern their time), so for a location-to-timezone service to be accurate, it’d have to have a complex geopolitical history database. In any case, this conjecture doesn’t help you now. For that, it might make sense to view your photos via the Map Module, where you can visually pick out photos that are in such-and-such a timezone, saving them to a collection and updating their time in bulk… —Jeffrey

— comment by Kaitlyn on May 19th, 2017 at 6:01am JST (3 days, 19 hours ago) comment permalink
Leave a comment...

All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.

You can use basic HTML; be sure to close tags properly.

Subscribe without commenting