Jeffrey’s “Geoencoding Support” Plugin for Lightroom

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

This plugin works in Lightroom Classic, 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.

Note: the ability to import the current view location of Google Earth is spotty, and for mysterious reasons it simply doesn't work for some folks. I've spent considerable time trying to figure it out, but have been unable to.

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 an old view of the dialog; the plugin now has a tab to swap between Google and OpenStreetMap)

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 both Google and OpenStreetMap, though in order to use Google, you must create a developer's API key, and enter that into the plugin in the Plugin Manager. (The egregiously-complex steps needed to create the Google API key are beyond my ability to explain as of yet, sorry.)

The plugin's reverse geocoding is much smarter than Lightroom's built in reverse geocoding, 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.

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 Lr10 to Lr11 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 )


CachedImagePreviewsFile token.

Upgraded to the embedded copy of ExifTool to version 12.67.

20220627.356 Update the embedded version of sqlite3 for Windows.

Updated a bunch of the "View location at..." URLs to use HTTPS, where supported. Added "View at Apple Maps (via DuckDuckGo)".


Removed a bunch of debug logging that was slowing down the LUA token.Newline

Upgraded to the embedded copy of ExifTool to version 12.42.

20220210.353 Maybe work around a Windows XML-parsing bug.

Added the WEEKNUM token, along with DAYNUM, weeknum, and daynum.

Whack-a-mole with PayPal's random changes.


Warn when PayPal seems to have given a bogus code in the web-confirmation page.

20211018.350 Handle "between two endpoints" geoencoding when the two endpoints are almost exactly the same point.

Fixed a problem with the KML output.

Fixed that the Province template token did not respect the plugin-specific geo-privacy settings.

Upgraded to the embedded copy of ExifTool to version 12.25.

Fixed an issue with the {Newline} token, and added {Comma}, {Hyphen}, and {Space} for good measure.

Fixed a problem with filters on the {Keyword} token.


Added 'separated by' to the People token.

Added the ImageViewDirection and ImageViewBearing tokens.

Reworked the Keywords token to better accept filters.

working around 'constant table overflow' error


Added the PF filter to turn typographic fractions into plain-ASCII fractions.


Rebuilt zip.


Updates for Lr10.


Added the ability to write the "Speed" field in mph and knots.

Added the SpeedKnots token.


Worked around an "unknown key captureTime" error.


Added the {PlusCode} and {GeoHash} tokens.


Removed some of the "view at..." services that no longer seem to exist.

Added some of the "view at..." services to the "set map urls..." configuration.


Added "View Location at OpenTopoMap"

Added the ability to save one's Google API key in other than the system vault, to try to get around these inexplicable "CryptUnprotectData" errors some folks on Windows encounter.


Setting elevation from Google services sometimes didn't work the second time.


Fix a crash with reverse Geocoding.

Work around a Windows bug related to canceling out of the registration dialog.


A blind change that might help get around a mysterious Lightroom "CryptUnprotectData" error that some Windows users see. I'm not sure what part of the plugin might be related to that error, but taking an educated guess, and if correct, trying to at least mitigate the effects of the bug.

Make the tracklog-loading status updates a bit more verbose.

Added some extra debug logging to note whether the plugin is enabled.


Added some extra debug logging to try to track down a problem.


Upgraded to the embedded copy of ExifTool to version 11.70.


Added "View at".

Updated the OpenStreetMap reverse geocoding to get around a bug they have that renders the "state" incorrectly./p>

Added the {RelativeFolder} token.


About the custom Google API key, try to notice when it's invalid because billing hasn't been set up, and report that to the user.

Added the LensInfo template token.

Updated the Exposure token to allow customization.

More token work: added {Urls}, and updated {ISO} and {Copyright} to allow customization.


Updated links to


Updated the OpenStreetMap reverse search to provide more detail.


Fixed the SST1 and SST2 tokens.


Updated the PublishCollectionName token (and CollectionNames and CollectionFullNames) to remove the MIRROR: prefix from the name that mirrored collections within my Collection Publisher plugin automatically get.


Added functions uc(), ucFirst(), lc(), and lcFirst() to the LUA token.


Fixed a problem related to template tokens and photos without capture times.

Upgraded to the embedded copy of ExifTool to version 11.50.


Updated What3Words functionality.


Fix a typo.


The "Fill in location name from OpenStreetMap data" option was not being honored.

Added the GPSCoords token.

Report on the number of remote calls to Google/OpenStreetMap done during bulk reverse geocoding.

Added the ability to set a metadata field with the What3Words location of a photo.


Fix an "Unknown key: captureTime" crash.


Upgraded to the embedded copy of ExifTool to version 11.30.

Updated the keyword-related tokens to accept standard filters.

Work around a bug that sometimes causes plugins to be disabled when starting Lightroom via clicking on a catalog file.


Better handling of errors from OpenStreetMap.


Added the ability to use your own Google API key. See the plugin manager. No documentation yet.

20190124.319 Fixed the "ReverseOpenStreetMap:342" error.

Added "Direction" (the direction the camera is pointing) to the plugin's built-in field display set.


Added the TempC and TempF tokens.

Well, an era has come to an end. Google has started to charge for services that used to be, very kindly of them, free. Now, the charges for the reverse-lookup feature are hundreds of dollars a month, and I just can't sustain that. They do give a certain amount of free credit per month, so I'll try to turn on the reverse-lookup feature at the start of each month, but it'll get turned off once the free credit has been used.

Hopefully in the near future I'll be able to add a way for individual users to use their own billing account at Google with the plugin.


Fixed the "Fill Elevation from Google Mapping Services" function. It turns out that I have to pay for this now, so I'll have to disable it if it becomes onerous.


Updated catalog database-access routines to work better in older versions of Lightroom.


Added the PEOPLE variable to the LUA token.


Fixed a problem with the SpeedKPH token.


Updated the "View at Bing" stuff to work with Bing's current maps.


Updates for Lr8 (Lightroom Classic CC Version 8).

Added the special PP() function to the {LUA} token.

Added hierarchical options to the Keywords token.

Re-enabled the "Guess Timezone" feature (in the "Etc" tab) after Google shut it down for free accounts. I'll now be charged for it, so if it gets too much use, I'll have to shut it down, sorry.

Fixed an "attempt to index a nil value" error that I introduced in the previous version (sorry).


During reverse geocoding, the plugin had been filling in location names from Google even when not requested.

Highlight the "Bulk Reverse-Geocode Selected Images With Settings Below" button, which might otherwise feel visually hidden at the top of the dialog.


Try to work around a Lightroom bug related to photo timezones and how Lightroom handles accessing plugin data.

Added some extra debug logging.


Upgraded to the embedded copy of ExifTool to version 11.01.

Added the 'nicknames' modifier to the {People} token.

Added the SST1, SST2, and SS3 tokens to the template tokens that the plugin understands.


Input fields that accept a location can now handle a What3Words code and a Plus Code.


Fixed a problem with the input box for the fast full-catalog proximity search.


Try to avoid having unexpectedly-long error messages create too-big a dialog.




Added support for displaying and accepting What3Words codes.

Upgraded to the embedded copy of ExifTool to version 11.01.

Updates to handle new Google usage-quoata rules.

Clicking on the version number in the Plugin Manager now copies version info to the clipboard

Updated the PublishCollectionName token to allow numeric arguments along the lines of the CollectionName token.

Added the folowing template tokens: {home}, {desktop}, {temp}, {pictures}, {documents}, {IptcDateTaken}

Added the 'PCH' variable to the {LUA} tag.


Fixed a bug when 'Token Examples' invoked in certain situations.

Moved the actually-do-it button from the bottom of the reverse-geocode tab to the top.


Try to make the plugin-extras-config dialog fit on smaller screens.


Added Plus Codes to the list of location formats the plugin understands.


Fixed an issue with KML files and ampersands.

Upgraded to the embedded copy of ExifTool to version 10.82.

Added a bunch of token filters: F2D F2S F2X B2D B2S B2X S2X A2D A2S A2X


The values for 'bearing' that the plugin writes had been in the range of -180° to +180°; now it's properly in the range of 0° to 360°.


More bullet-proof parsing if user KML file.


Handle temperature interpolation better.


Oops, more Lr7 stuff.


Updates for Lightroom 7


The "photo between lines" feature of the KML-output stuff didn't respect all configuration options.

Better handle some character-encoding issues related to template tokens.

Allow the "If Exists" feature of Templat Tokens to work with the PluginProperty token.

Update registration support to handle a stupid bug at PayPal that PayPal refuses to fix )-:


Removed the "view at" for, and added and


Try to make database access (for fast full proximity search) more robust.


Fixed a bug introuded the other day in template tokens, related to Windows filenames.


Added the Newline template token.

Enhanced the FolderName token

Upgraded to the embedded copy of ExifTool to version 10.55.

Added the "only if it has a value" feature to template tokens.


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 637; see all), most recent last...

Hello Jeffrey

Thank you for your great set of LR plugins which I use a lot.

I am testing your geocoding plugin. It works fine, except that the time difference between camera and tracker app remains tricky and error prone. And time corrections need to be done manually.

Do you know about Gps4cam and its brilliant solution to this problem? This geocoding app automatically corrects camera times, and works even across time zones.
It works as follows: at the end of a trip you shoot a reference photo of an image produced by the gps4cam tracking app on your smartphone. The gps4cam desktop app then corrects all photo times and inserts the geotags using this reference photo. Do this with all cameras used during the trip and all photos are synchronised perfectly. I have been using it for years to time sync the pictures my wife and I take during our travels. Simply great.

Unfortunately gps4cam is no longer supported, and I am struggling to keep the desktop app running on a Windows7 (virtual) machine. Both the Windows and macOS desktop apps are still available, but they require an older version of Java. The Android app is still available, sadly the IOS version has been removed by Apple. I have unsuccessfully tried to contact the author with a view to explore ways of resurrecting the app.

I wonder if you would consider implementing this method in your plugin?

It would require a mini smartphone app to create the sync picture. Gps4cam generates a QR code containing date/time info as well as the full track. Sadly it seems to be in binary, not a text file, otherwise I would have sent you a test set to experiment with.

Grateful for your views,
Thank you,
Edwin Hermans

info on:

That sounds like a nice solution, but a lot of work to create. Perhaps consider what I do: take a photo of an accurate clock (e.g. the clock app on your smartphone). In Lightroom, select all photos from about the same time, and make the clock photo the “most selected” one. Then use Lightroom’s basic update-timestamp feature to adjust the time of the clock photo to the time shown in the clock photo; Lightroom will then adjust all the other images accordingly. —Jeffrey

— comment by Edwin Hermans on March 3rd, 2020 at 6:57pm JST (4 years, 5 months ago) comment permalink

Using it everyday since years, thanks.
Could you add View location at opentopomap ?

Added to the version that I just released. —Jeffrey

— comment by Alain on March 3rd, 2020 at 9:50pm JST (4 years, 5 months ago) comment permalink

I’m getting a “Plug-in ‘jf Geocoding Support’ performing shutdown tasks” alert more often with my larger catalogs in Lightroom. Usually, it is just a minute or two, but currently, the one has been on the screen for over 10 minutes. I love this tool, and I guess I can just cancel it – except this time, I’m getting the beachball – but I just want to make sure there is not something wrong with my catalog or the plugin that might be causing this issue.

The shutdown tasks should take just a fraction of a second, so if it’s taking a minute, something feels wrong. I don’t have any idea what that something might be, but perhaps start with checking the integrity of your catalog, and then optimizing it for good measure. —Jeffrey

— comment by Ian Aberle on March 7th, 2020 at 11:24am JST (4 years, 5 months ago) comment permalink

Hi Jeffrey,
I just installed the Geocoding Addin. Its just great! 🙂
But … 😉 is there a reason that the “Configure URLs” at “Set Map URLs” is not listing OpenTopo?

Thanks in advance & Best Regards

The reason is that the “Configure URLs…” stuff was developed before any of the “View at…” stuff was; I never thought to tie the two together. I’ve done that for some of them now, including OpenTopoMap, so if you update, it should work. Thanks for the idea. —Jeffrey

— comment by Guenther Bosch on March 22nd, 2020 at 3:05am JST (4 years, 4 months ago) comment permalink


With release 340 I was hoping that the weird errror message “There is something wrong in CryptUnprotectData” would be gone. No such luck. I am using LR Classic 9.2 on Windows 10 Pro 64. Bummer.

To avoid that error, you have to re-configure your Google API key, choosing “save to Lightroom preferences”… —Jeffrey

— comment by Phil Burton on March 26th, 2020 at 1:21pm JST (4 years, 4 months ago) comment permalink


I’m writing you from Bradenton, FL USA. Any chance of adding support for Azure’s reverse geocoding API? I’m asking as I get a monthly credit toward Azure services.


Probably not, sorry. Given the work it would entail, and the apparent lack of demand (present company excepted), it just doesn’t seem worth it. —Jeffrey

— comment by Mike on June 11th, 2020 at 8:29am JST (4 years, 1 month ago) comment permalink


I just want to express my deep appreciation for all the work you do with Lightroom plug-ins, including this one, and your dedication to supporting your users.

You (and John Beardsworth, John R Ellis and a few others) are the reason that I will probably never stop using Lightroom, unless Adobe tries to squeeze my wallet dry.

Phil Burton

— comment by Phil Burton on June 14th, 2020 at 1:39pm JST (4 years, 1 month ago) comment permalink

I can see that the plugin can read Plus Codes, but is there a way to embed plus codes into a field similar to the “fill w3w” button on the etc… tab?

Thank you!

You can use the Write Data Field feature of my Bag-o-Goodies plugin, using {PlusCode} within your template to get the Plus Code. (I just added this feature, so if you already have that plugin, please update it.) What3Words has to be here because it can’t be accessed from a template due to the nature of how What3Words is implemented. —Jeffrey

— comment by Ed on July 29th, 2020 at 1:51am JST (4 years ago) comment permalink

How can I get rid of the annoying alert that hangs a while each time I quit LR?

I feel your pain. In trying to work around a problem in Lightroom, the plugin has to do a super-quick (done in miliseconds) housekeeping task when Lightroom ends. I’ve no idea why Lightroom feels the need to throw up that dialog, nor why sometimes it hangs there for seconds for something that should be over and done faster than the blink of an eye. Sometimes it’s quick. Well, I shouldn’t say “no idea why”… I suspect that the delay is just the catalog database flushing to disk, and that sometimes because of that delay Lightroom doesn’t get around to clearing the dialog quickly. In other words, I suspect that the dialog is not actually making the shutdown take longer… it’s just putting a face on the delay that is already there. But in any case, it’s super frustrating. —Jeffrey

— comment by Alain on August 28th, 2020 at 10:34pm JST (3 years, 11 months ago) comment permalink

The latest geoencoding zip file (20201018.345) is empty. Can’t install.

It’s certainly not empty on my server; please give another try downloading. —Jeffrey

— comment by Scott on October 22nd, 2020 at 5:33am JST (3 years, 9 months ago) comment permalink

Your zip is corrupted and unable to open.

— comment by Todd on October 24th, 2020 at 3:47pm JST (3 years, 9 months ago) comment permalink

Hi Jeffrey,
something with is wrong. Chrome says something about of risk to download the file. And if i download the .zip (Chrome or Firefox), i can’t activate the plugin in LR.
Translation from German: An error occurred while reading the schema for the module “jf Geocoding Support”. The module is deactivated.

— comment by Urs on October 24th, 2020 at 5:25pm JST (3 years, 9 months ago) comment permalink

I have tried 5 times to download your LR10 compatible geocoding plugin and it never downloads fully — even after more than 1 hour. The .part file fills up to 7060KB and stops there. Of course the Zip file is 0 KB as mentioned in the previous comment (by Scott) and install is not possible

I really don’t think there’s a problem with the zip… if there were, I’d have literally thousands of complaints, instead of a few. What I don’t know is why there would be a few. Over the years I’ve gotten the occasional “the zip is corrupted” complaint, but it’s always been fixed by my suggesting to download with a different browser, or to unzip with a different tool, which suggests that the problem somehow lies in some fringe browsers/tools out there. But I don’t know. In any case, I just pushed out a new version (‘’). If you have the standard program called sum, its output for the zip should be “54779 7062“, so you can check to ensure that you’ve received it properly. —Jeffrey

— comment by Pierre Bely on October 26th, 2020 at 11:53pm JST (3 years, 9 months ago) comment permalink

You are right Jeffrey: nothing wrong with your zip file…

The problem was on my side. Do not know the reason : slow internet ? US/European restrictions (I am currently in France) ?

Anyway, I asked my son who lives in the US to download the zip file and forward it to me via our Dropbox. I am up and running….

Sorry for the trouble.



— comment by Pierre Bely on October 29th, 2020 at 3:18am JST (3 years, 9 months ago) comment permalink

Are you planning on updating the GPS LR pluggin for the new version of LR?

Hope so, I so count on it.


I updated all my plugins a few hours after Adobe announced Lr10. —Jeffrey

— comment by Patrick Lynch on October 29th, 2020 at 11:06pm JST (3 years, 9 months ago) comment permalink

Any suggestions on what the issue is when I try and install version 346?
I really want the geocode pluggin.


Pretty much every time I hear that someone can’t install the latest version, it turns out that they were really trying to install some older version lying around on their system somewhere. So I’d suggest to delete all copies of the plugin and plugin zip files that you can find anywhere on your system, then download the latest from my server, unzip it, move it to where you want it to live on your system (and if that’s in a different place than it was before, point the Plugin Manager at the new copy). —Jeffrey

— comment by Patrick Lynch on November 3rd, 2020 at 6:34am JST (3 years, 9 months ago) comment permalink

The issue seems to have been another plugin. Once it was handled I was able to install geocode

I’d be very curious to hear what the issue was; one plugin shouldn’t have the ability to cause install problems for another. —Jeffrey

— comment by Patrick Lynch on November 3rd, 2020 at 7:30pm JST (3 years, 9 months ago) comment permalink

Love the Peakfinder connection in the Plug-in. Only noticed this today – will save me a lot of time sorting out mountain shots. Thanks!

— comment by Fred on November 10th, 2020 at 6:33am JST (3 years, 8 months ago) comment permalink

After geocoding some files I used your Geocoding View to see the Bearing (and speed) and it works great. Awesome! Is there a way to also put the Bearing in the Direction field so when I upload my 360 street view images, they will be oriented “correctly”, Bearing doesn’t appear to be used by any of the software pgms I use to upload to Google Streetview, only Direction. (Yes I know that LR turns all numeric values of Direction to the 8 primary directional words, silly LR… I’m ok with that even though it’s not ideal)

When I view the image exif in an external tool like ExifTool, the Bearing doesn’t show up, but Direction does. Does that mean that Bearing only lives in the LR cat? I don’t use sidecar files for my 360’s. I also tried to export and then look, but it still wasn’t there.

If your Geoencoding Support” Plugin cannot also update the Direction, do you know another program that can copy the LR Bearing to Direction?

I’m not familiar with this “Direction” field, but could it be the GPSImgDirection field? That’s the direction that the camera is facing, while the plugin’s Bearing is the direction of travel at the time the image was taken. If you want to copy the latter to the former (because, for example, you had a camera mounted on a car facing forward), you might consider using my Run Any Command plugin to invoke ExifTool to copy over the data. —Jeffrey

— comment by Michael Bessler on December 5th, 2020 at 2:08am JST (3 years, 8 months ago) comment permalink

Hi Jeffrey,

I noticed that your website is only available via http, but not https. Most browsers (like chrome and firefox) block unsecure connections these days, so users cannot reach your site. You just get an error message saying the site is not available. Maybe sth to change on the server-end?

Kind regards,


I have had a secure server at this site for decades, but it is a different set of documents than the non-secure server. It is wrong to assume that they should be the same. —Jeffrey

— comment by Ben on April 19th, 2021 at 10:08pm JST (3 years, 3 months ago) comment permalink


Thank you very much for this plugin, its fantastic! however what can we do for video files? It seems its not possible to add GPS metadata to video files out of LR . I would like to save the GPS metadata to video files also….

This seems to be a bug in Lightroom. I’ve reported it to Adobe. Until fixed, you can use my Run-any-Command plugin to inject the coordinates, running:

exiftool -GPSLatitude="{Latitude}" -GPSLongitude="{Longitude}" "{FILE}"

for the per-image command. For this, you need to have ExifTool installed, and of course, update the “exiftool” in the command so that you have the full path to it (where it’s “exiftool.exe” on Windows). —Jeffrey

— comment by Gerardo on June 8th, 2021 at 1:33am JST (3 years, 2 months ago) comment permalink

Hi Jeffrey, I’ve been using your flickr and geo plug-ins ever since, so far never any problems, thanks!
with the latest LR upgrade and re-registration, the geo plugin won’t work, telling me that “current location has not been verified’. GPS coordinates exist, I have no clue what this could mean. any idea? Thanks!

I’ve got no clue either where that might be coming from, or what it means. Could you send a log, and perhaps a screenshot, the next time you encounter it? —Jeffrey

— comment by Jan on November 14th, 2021 at 10:45pm JST (2 years, 8 months ago) comment permalink


I’m using LRC 11.0.1 (german) the plugin version 20211018.350.

When I’m using OpenStreetMap to geoencode some pictures there some inaccurate results.

An example:

GPS: 53°48’26.7578″ N 8°54’14.7928″ E

City: „Samtgemeinde Land Hadeln“
But correct would be
City: „Otterndorf“

„Otterndorf“ is a part of „Samtgemeinde Land Hadeln“ as some other cities around.
„Samtgemeinde Land Hadeln“ is comparable with counties in the USA.

Is this a problem of OSM?

Hans-Peter Dorn

For that area, OSM returns “Samtgemeinde Land Hadeln” as a “municipality” and “Otterndorf” as a “town”, and my plugin gives priority to “municipality” over “town”. In this case, that doesn’t match what you want, but it might match what someone else wants, and it might match what you want in a different location. It’s hard to predict. It would be best if my plugin made this configurable somehow. I’ll have to give it some thought… —Jeffrey

— comment by Hans-Peter Dorn on November 21st, 2021 at 4:55am JST (2 years, 8 months ago) comment permalink

Hi Jeffrey,

I was using this plugins over years on my Windows-Machine. This year I switched to Mac.
For any reason it stopped working.

I am using a registered copy of “Geoencoding Support” Plugin Version 20220120.352 on Lightroom Classic-Version: 11.1 [ 202112022200-7fd1f998 ], Mac OS 12 – Version: 12.1.0 [21C52] – arm64.

Tried to geoencode 8 pics from a track log in gpa format (downloaded from a recorded walk on (worked perfect multiple times). Your plugin confirms “images processed successfully: 8” but I cannot find any GPS coordinates in meta data of any pic.

Any suggestion?

Thanks so much!!

How exactly are you checking for coordinates, and what is the indication that they’re not there? —Jeffrey

— comment by MichaPoe on January 31st, 2022 at 9:13pm JST (2 years, 6 months ago) comment permalink

Hi Jeffrey,
I am Using LrC 11.1 on macOS Monterey (M1) with licensed Geoencoding Plugin 20220120.352.
When I try to encode a few or single photo from a gpx file (exported from kommot) the plugin detects 718 datapoints. After processing it tells me that all pics were processed successfully. But I can’t see the GPS coordinates being stored to the photos.
On my Windows Machine all worked fine in the past.
What am I doing wrong?

How have you checked for coordinates being stored to the photos? Do they show up on the map in the Map Module? When you view individual photos in Library, does the metadata panel show an empty box where the coordinates should be? —Jeffrey

— comment by MichaPoe on February 6th, 2022 at 7:56pm JST (2 years, 6 months ago) comment permalink

Hi again,

just a quick note to let you know, still using geoencode as it works so well. And the $5 was just to renew my licence following a reistall of LR on a new laptop – couln’t leave $0.01 as it would seem just too insulting and hope this ‘refresh’ donation will at least get you a coffee 🙂


and thanks for such a great app


— comment by dave on February 6th, 2022 at 8:08pm JST (2 years, 6 months ago) comment permalink

Hey All, just wondering if there is a setting I can’t find in this plugin that will also write the location field into to the keywords while I am doing a reverse geocode? Right now my workflow takes me out of lightroom to just do that one task. Thank you.

My Metadata Wrangler plugin can inject data into keywords and some other fields, upon export. —Jeffrey

— comment by Daniel Osiedacz on April 4th, 2022 at 2:37am JST (2 years, 4 months ago) comment permalink

Hey Jeffrey,

Does your plug in write the location information directly to the photo file?

I am not a lightroom user but your plug-ins may be enough of a reason to switch. I did a test case and while the location data is visible in lightroom, I do not see it in Capture One, ACDsee, or the properties of the photos.

Frankly, your work is astounding.

Lightroom and the plugin update the database with location information, but it’s not normally written back out to the original master file. You can request that updated metadata is written out to the master file, but that works only for certain file types… non-DNG raw files, for example, have the updated metadata written to an XMP sidecar. If your only desire is to get location info into your files, Lightroom seems to be overkill. If you’re handy with the command line, consider ExifTool. There’s also something called “GeoTagr” or “Geo Tagger” or the like…. —Jeffrey

— comment by Kevin Scott on May 7th, 2022 at 7:08am JST (2 years, 3 months ago) comment permalink

Hi Jeffrey,

I am not sure if this is an issue with the plugin, but when I try to view photos with OpenStreetMap it fails to load, it appears the URI scheme is HTTP and not HTTPS. Only OpenStreetMap is affected

Plugin Verson: Version 20220606.354

Thanks for the heads up. I’ve pushed out a new version. —Jeffrey

— comment by Justin on June 12th, 2022 at 6:23am JST (2 years, 1 month ago) comment permalink

This method solves the persistent “There is something wrong in cryptunprotectdata” message:

Hope this saves others time for Googling a solution.


— comment by Aaron Leung on December 31st, 2022 at 4:05pm JST (1 year, 7 months 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.

IMPORTANT:I'm mostly retired, so I don't check comments often anymore, sorry.

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

Subscribe without commenting