Jeffrey’s “Geoencoding Support” Plugin for Lightroom

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

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

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

Table of Contents

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

Introduction

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 GeoHash.org;  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 MapFan.com (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.

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

The Static-Location Tab

The second tab of the Geoencoding Dialog is Static Location:

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

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

The Between-Points Tab

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

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

Reverse-Geoencoding Tab

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

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

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

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

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

The One-by-One Tab

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

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

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

The Etc. Tab

The Etc tab has a few odd and ends:

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

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

Extra Configuration and Keyboard Shortcuts

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

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

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

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

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

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

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

Inspecting Your Location Metadata

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

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

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

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

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

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.

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 GeoHash.org
  • 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 MapFan.com (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 MapFan.com, 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 MapFan.com, 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 MapFan.com 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 MapFan.com 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 MapFan.com 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 MapFan.com, 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 Lr4 to Lr5, 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 )

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.
20150607.258

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.
20150408.256

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.

20150205.255

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.

20150131.254

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
20141203.250

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.

20141129.249

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

20141127.248

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.
20140802.242

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
20140715.238

Fixed an issue with Creative-Cloud revalidation.

20140712.237

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

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

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
20140628.231

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.

20140619.230

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!).

20140613.229

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

20140605.228

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.
20140530.226

Added the ability to flush plugin data for selected photos.

Upgraded to the embedded copy of ExifTool to version 9.53.

20140509.225

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.
20140422.222

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

20140418.221

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".

20140417.220

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.

20140329.219

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.

20140324.218

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.
20140204.216

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.

20140204.215

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."

20140123.214

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.

20131203.213

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

20131202.212

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.

20131102.211

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.
20131022.209

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 Google.ru 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.
20130929.206

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
20130925.203

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.

20130920.202

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". :-)

20130829.201

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.
20130220.194

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
20130201.191

Upgraded to the embedded copy of ExifTool to version 9.15.

20130120.190

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.
20120923.188

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.

20120821.187

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 geoportail.gouv.fr
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.
20120608.179

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.

20120526.179

Update to handle the Mac App Store version of Lightroom.

20120512.178

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

Yikes, Lr2 registrations were broken again.

20120507.177

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.

20120430.176

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.

20120413.175

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
20120225.167

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

20120224.166

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.

20120123.165

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

--

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

20120114.164

More tweaks for Lr4b.

Updated Image::ExifTool to version 8.75.

20120112.163

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.
20111206.160

“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.

20111130.159

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.

20111018.158

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.
20110719.154

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.
20110520.147

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...
20110411.140

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 OpenCycleMap.org support.
20110215.138

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.
20100829.135

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.
20100814.132

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.

20100803.131

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.
20100620.128

(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.
20100609.125

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.

20100518.124

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.
20100420.121

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.

20100419.120

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.
20100317.115

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.
20100315.112

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.

20100306.111

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.
20100213.109

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.
20100123.107

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.

20100121.106

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 “@”.
20091018.92

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.
20090915.90

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.
20090717.86

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

20090707.85

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 ThePhotoGeek.com. 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.
20090701.83

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.
20090608.81

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

20090607.80

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.

20090601.79

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.
20090526.77

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.

20090525.76

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.
20090511.73

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.

20090511.72

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.

20090510.71

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.
20090427.64

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.

20090425.63

Added WikiMapia.org, 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 MultiMap.com url is created, using an incantation that ends up leaving a red circle to mark the photo location.
20090424.61

Added two more “View location at...” menu items: one for multimap.com 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.
20090417.59

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.
20090412.57

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 info.regex.lightroom.gps.map.

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.
20090402.54

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.
20090325.50

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.
20090215.44

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.
20090121.40

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.

20090121.39

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 MapFan.com 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.
20090115.36

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 MapFan.com” 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.
20081126.21

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

Jeffrey,
First thanks for a GREAT plugin ! I can’t imagine what I would do without it.

Next, an enhancement request.
I combine multiple exposures into a single negative (TIFF). The Tiff files have a timestamp of the first exposure of the set, but not any GPS info.
I would like to take a folder that has a mix of GPS tagged exposures, and non tagged, and have the “In between” function assign a GPS coordinates to non GPS tagged images proportional to the time difference of the untagged with the delta time: Example: Exposure A is at 12:34:54, Exposure C is at 12:35:06 and Exposure B (the tiff) has a time of 12:34:55. Exposure B has a 1 second /12 seconds (difference between A & C), so the GPS coordinates would be 1/12 of the distance from A to C, or nearly identical. And if the time stamp was the same, it would get the same coordinates.

Thanks,
:-)

That’s exactly what the “Between Points” tab does, especially with the [Import locations from the first/last images selected] button. —Jeffrey

— comment by Patrick Lynch on September 21st, 2014 at 10:54am JST (10 months, 13 days ago) comment permalink

I ran into an interesting problem today that I thought your plugin may be able to fix. I traveled to anothter time zone, took a bunch of photos on my Nikon and my iPhone. The iPhone had corrected its timezone when I arrived, but the D800 did not. I have my photos named chronologically.

I am looking for a way to automatically update the timezone stored in the date fields with the TZ of the lat/lon where the photo was taken. EG: if I took a photo in CO yesterday, set the time zone to -600, but if I took it in California set it to -700.

Do you think that’s a feature you could work in? I’d be happy to discuss the logic of it, feel free to e-mail me directly.

As unbelievable and inexcusable as it may seem, the Exif standard has no provisions AT ALL for timezones. Photo times are all wallclock times. It’s monumentally stupid, but that’s what a committee designed. So the best you can do is change the wallclock times in the photos to the correct data. Lightroom lets you do that easily… select all photos and click on the mark in the metadata display where the time would be, and a dialog pops up giving you various ways to update the time for all photos. —Jeffrey

— comment by Daniel on September 30th, 2014 at 2:20pm JST (10 months, 4 days ago) comment permalink

Hi Jeffrey,

Congratulations for this excellent work.

I am using GeoSetter for years and it has the possibility to copy location data as proper keywords (like city, country etc), that helps to search on web site that uses only keywords to index. I didn’t find the way to do so with your plugin and it is very important for me… Is it possible ? If not, is there a simple way to do that in LR?

Thanks for your feedback!

Many of my exporter plugins allow you to add keywords to the exported copy on the fly, including those derived from template tokens like “{City}“. It’s better to add them to the keywords on the fly like that than actually adding them as keywords in Lightroom, because in that case you have to worry about keeping the two sets of data in sync, which is a nightmare. Anyway, I’ve just now added the same ability to my metadata-wrangler plugin, so you can do this with any export. —Jeffry

— comment by David on October 3rd, 2014 at 7:02pm JST (10 months ago) comment permalink

Hi,

I’m trying to test this plugin to see how it compares to LR5’s builtin map module, but upon enabling it I get the “Your catalog must be updated to use this plugin” warning. Since I’m not sure I will want to use the plugin, just testing, I’m a bit wary of this. Could you please explain what is the impact of “updating the catalog”? And if I remove later the plugin, will the some plugin-related information remain forever in the catalog?

Thanks in advance!

That warning is really stupid, I think, and I’ve long complained to Adobe about it. It’ll add an inconsequential bit of data to the catalog (less than the develop-setting notes for one photo). This plugin isn’t used instead of the Map module, but along with it… it provides a lot of nice ways to investigate your geoencoded photos. The main overlap where it is better than the Map Module is in tracklog geoencoding, and in reverse geoencoding. But I still use the Map module to geoencode by hand all the time. —Jeffrey

— comment by Iustin Pop on October 6th, 2014 at 4:03am JST (9 months, 30 days ago) comment permalink

A friend sent me a .log file of our recent photography trip. I was able to view it using Google Earth. I can’t seem to upload this file into Lightroom. I think Lightroom wants a GPX file. Can this .log file be uploaded into Lightroom with your plug in? Thanks.

You can likely convert it to a GPX file with GPSBabel. If it’s something you’d need to do often you could configure the plugin to run gpsbabel automatically, but in this case you just need it the one time, so it’s probably easiest to just do yourself outside of the plugin. Perhaps try this web interface… —Jeffrey

— comment by Lance Levine on October 21st, 2014 at 10:03am JST (9 months, 14 days ago) comment permalink

Hi Jeffrey,

I have a problem with Neighborhoods in Spain: it seems that the plugin does not recognize them.

For example, for location 40°23’30” N 3°41’22” W Lightroom retrieve Legazpi (the neighborhood) while the plugin retrieve Calle del Plomo (The street name). Of course, I have set the field Neighborhood to a higher priority than Street Name, but all the fields are empty except Street Name and Street Address.

Do you know why I cannot retrieve the neighborhood with the plugin while I am able to do so with Lightroom ?

Thanks for your job !

The organization of the data that Google returns is an absolute mess that varies wildly at different places around the globe. The difference between what Lightroom does and what my plugin does is a reflection of different approaches to try to make sense out of that mess. It’s a fairly fragile process, and making a tweak that helps get better results in one area of the globe can often destroy the results in another. With that in mind, I’ve used your example to make some tweaks that I hope has a net-positive result. Upgrade the plugin to give it a try… —Jeffrey

— comment by Itomi on November 28th, 2014 at 4:28am JST (8 months, 7 days ago) comment permalink

I experienced problems similar to Itomi where the data returned was not consistent. After corresponding with Jeffrey, I discovered that the preferences set in the “reverse geoencoding” dialog was corrupted.
I did reset my preferences in the menu and now the data returned is reliable.
May be this can help others.
Thank you to Jeffrey who was very quick to answer and gave me the “hint” where the trouble might hide!
Check your preferences settings 😉

— comment by ishoot on December 10th, 2014 at 4:25pm JST (7 months, 25 days ago) comment permalink

Hi. I moved to Google Earth Pro a view days ago. Since then, I can’t retrieve a location from Google Earth. I can display the Crosshair, I can view a location on Google Earth from LR but when I try to retrieve a location from the Crosshair position through the direct access, I get a message “Can’t get location from Google Earth”. From the Geoencode windows, nothing happens. Any idea ? Thanks.

It works for me in both OSX (10.9) and Windows (7), but I’ve had one other report of it simply not working for another user. We couldn’t figure out why. He opted to move back to Google Earth from the Pro version. If you’re on Windows, you can visit the “Win” subfolder inside the plugin and try running “GetCurrentGEView.exe” in a command window. If you see a bunch of numbers (latitude/longitude/altitude), it’s working, but I suspect for whatever reason it’s returning an error of some kind… —Jeffrey

— comment by Greg on February 22nd, 2015 at 7:47pm JST (5 months, 10 days ago) comment permalink

I ran into this problem on Windows. What I had to do was uninstall both Google Earth and Pro, the reinstall Pro. The plugin then asked me for the location of Google Earth. I pointed it to the executable for Pro and all was well.

— comment by Paul on February 23rd, 2015 at 12:14am JST (5 months, 10 days ago) comment permalink

Thanks for the tip. Indeed it works after unstalling (reboot to be safe) and reinstalling. LR did not ask (it did the first time) to point the Exe but it works so that’s enough for me. Again, thanks.

— comment by Greg on February 23rd, 2015 at 5:43am JST (5 months, 10 days ago) comment permalink

Hi guys, for any conversion needed to get routes or waypoints, I suggest to consider this free tool which can easily make Google Earth kml format to gpx and vice versa, when in need. Check out here: http://kml2gpx.com/ Thanks!

— comment by Katrina on February 27th, 2015 at 6:04pm JST (5 months, 5 days ago) comment permalink

Hi,
Since the last update (not sure from which version I updated though), the plugin opens multiple instances of GE, whilst making it impossible to geotag photos from GE.

Hope you had a nice trip, thank you :)

Lightroom 64 and plugin updated to the last version as of today, GE 7.1.2.2041

It should open up only one instance of Google Earth, the specific one you’ve pointed to via the [Configure Google Earth Location] button in the plugin manager. If you’re not seeing that, please send a log. Thanks. —Jeffrey

— comment by Thomas on March 22nd, 2015 at 3:31pm JST (4 months, 13 days ago) comment permalink

Jeffrey

I have created the ‘place’ in Google Earth. This works well to update the sub location in LR6 R23 – have you made any progress on being able to edit other fields, such as city, street etc?

Make the description look like “country/state/city” (e.g. “USA/California/San Francisco”). —Jeffrey

— comment by Dave on March 27th, 2015 at 3:11am JST (4 months, 9 days ago) comment permalink

Hey, Jeffrey;

For the ‘Geocode from Tracklog’ tab, any thoughts on making the “Tracklog file(s)” point to a directory, instead of a specific tracklog? or maybe that plus a parameter that loads the last “n” files?

When I get back from a shoot, I dump my tracklog(s) into a directory, and periodically move them off to my server every few months. It would be nice to simply do a Library/Plugins/Geocode, select the tab, and then ‘Go’ instead of the extra step of browsing the directory to select the last few tracklogs.

Thank you!
–David

I, too, almost always geoencode with “the most recent few files”, but I just keep the list sorted by modification date and so it’s not too arduous to select the appropriate file(s) at the top of the list. Trying to configure some kind of automatic “use most recent…” seems fraught with “doesn’t work quite how I want” peril… —Jeffrey

— comment by David D on March 29th, 2015 at 6:18am JST (4 months, 7 days ago) comment permalink

Hi Jeffrey,
thank you for the plugin, it is very useful!
One question/suggestion – in the Reverse Geo mode it is possible to select either “Fill in only fields that are blank” or “Overwrite all fields with new lookup data”. Would it be possible to add a third option that fills the empty fields and autocommits information that is present in others?
Thank you!

No, sorry, because Lightroom doesn’t give plugins any access to data that has not been committed. —Jeffrey

— comment by Ilya on April 27th, 2015 at 12:30am JST (3 months, 8 days ago) comment permalink

Hello,
This is to answer the comment left by Thomas on March 22nd.
When, sometime in February, I updated to the latest release of the plug-in, I had the same kind of problem. It persisted in wanting to open several instances of Google Earth. I noticed that the parameters of this Google Earth were not the ones I had set in the preferences of the Google Earth I use.
After much head scratching, and Jeffrey on holiday at the time, I noticed that the plug-in had lost all the settings. After reconfiguration:
– pointing the Google Earth,
– resetting the location preferences,
it all worked again.
(if it is any use, I am on Mac)

— comment by ishoot on April 27th, 2015 at 4:33pm JST (3 months, 7 days ago) comment permalink

I’m using a Foolography Unleashed Dx000 and a Holux RCV-3000 to geotag my photo’s in my Nikon D610. Your plugin works wonderfully in Lightroom, except for the times that the GPS took awhile to acquire GPS lock, or temporarily lost it in the middle of a shoot. Could you extend the features of your plugin to use GPS data when available, but to use previously geotagged photos as a pseudo-tracklog for those that are missing GPS data?

For now, when I notice that I’m missing GPS data on a few shots, I’ll download the tracklog data from the device, load it into Lightroom, add that location data to the missing pictures, then reverse geocode with your plugin. It would certainly speed up the workflow if you could add this functionality.

Thanks in advance.

In this situation I just open up the Map Module with the filmstrip showing, and drag unlocated images to the map. I’m not quite sure how I’d automate it, nor how generally-useful it’d be if I did…. —Jeffrey

— comment by Robert on May 1st, 2015 at 1:38am JST (3 months, 4 days ago) comment permalink

Robert, in this case I use the “Between points” feature of the plugin which interpolates between previously geotagged photos.

— comment by Alain on May 2nd, 2015 at 2:22pm JST (3 months, 2 days ago) comment permalink

I’m one of those that can’t get coordinates from Google Earth. Clean install of Windows 8.1 a couple weeks ago. Lightroom 6. I uninstalled Google Earth Pro and installed regular Google Earth. I can see the cross hair, but it never gets coordinates. It remains a mystery to me, sorry, but I heard from one person with this problem that when they visited the plugin manager and re-told the plugin where Google Earth was installed, it started working for them. —Jeffrey

— comment by Aaron Priest on May 22nd, 2015 at 1:26pm JST (2 months, 13 days ago) comment permalink

Jeffrey,
I was probably the one affected by this issue.
Yes, going into the plug-in manager and resetting everything did the trick.

I have not uploaded the latest version of the plug-in; I am getting shy 😉

— comment by ishoot on May 22nd, 2015 at 5:30pm JST (2 months, 13 days ago) comment permalink

Yeah, I read that, it’s the first thing I did, and it asked me again where the .exe was. What’s odd is that the first time I used it, it worked, until I turned on the cross hair to be more accurate, and since then nothing has worked for me. Strange…

— comment by Aaron Priest on May 23rd, 2015 at 7:40am JST (2 months, 12 days ago) comment permalink

Hi, I am not in any way technical so please be kind!! I take many photographs either when out walking or cycling and would like to geotag them in LR6 (CC). My camera does not have the facility. I have used an app on my iPhone in the past however I am about to purchase a Garmin Edge 200 cycle computer which I understand can export a .FIT file. My question is can your plugin read this type of file and sync it with my photographs within the MAP sector of LR?

The plugin natively handles only .GPX files, so if you can get the Edge to export one of those, you’ll be fine. Otherwise, you can configure the plugin to convert the .FIT file to a .GPX file for your automatically, via the “config…” button under the trackfile “Browse” button. You’d install gpsbabel on your system and point the plugin at it, then set it up so that when a “fit” file extension is selected, “-i fit” is used. —Jeffrey

— comment by John on May 30th, 2015 at 8:56pm JST (2 months, 5 days ago) comment permalink

Thank you for that. I have now discovered that I can export a .GPX file through Garmin. For the record I live in Scotland.

— comment by John on June 1st, 2015 at 5:28pm JST (2 months, 3 days ago) comment permalink

I’ve just upgraded to Lightroom 6 and the latest version of the plugin, but for some reason the “Import location from Google Earth” option doesn’t seem to work anymore (it did a few days ago, when I was just running the plugin in LR6 as trial). I’ve explicitly re-set the path to Google Earth, closed/reopened both apps, but to no avail (on Win8.1, if that makes any difference). Any ideas?

Sorry, no ideas on this )-:. Google doesn’t officially support what the plugin is using to try to get the current view (they used to years ago, then dropped support), so it remains a mystery. I’ve spent many hours trying to figure out why it doesn’t work for some folks, and I’m stumped. Sorry. )-: —Jeffrey

— comment by Patrick H. Lauke on June 8th, 2015 at 7:35pm JST (1 month, 26 days ago) comment permalink

Hi Jeffrey,
The plugin Geoencode Selected photos does not work on my PC. It has always worked for me correctly, until today, I have registered.
I’m using the Google Earth Pro with Lightroom CC. Windows 7 Pro x64.
The error message is: Can’t get location from Google Earth
Best regards,
Pep Ferrer

Please see my response in the comment immediately previous to yours. —Jeffrey

— comment by Pep Ferrer Sanchis on June 9th, 2015 at 3:46am JST (1 month, 26 days ago) comment permalink

I’ve just upgraded to LR6, while at the same time migrating to a new computer… and I seem to have lost all of my static location presets within the geoencoding plugin. I’ve grepped around a bit in the Application Support/Adobe/Lightroom folders on the old and new machines, and I can’t seem to find them… is there an easy way to bring them over to the new machine/LR install?

The plugin stores them in your Lr preferences file. If you can invoke Lightroom still on the old system (or on the new one with your old preferences), you can export them via the plugin to an external text file that you can then import into the new system. —Jeffrey

— comment by Zane Selvans on June 18th, 2015 at 12:38pm JST (1 month, 16 days ago) comment permalink

I use the Qstarz BT-Q1000 XT which seems to log fine but I notice in the GPX, there are points with names such as:
Stop for 1hr10mins

As a result, the lat/long is not being repeated every 5 seconds (the default logging interval)

So now when I try to match the photos to GPX, there isn’t (always) a matching timestamp since it might have been 10+ mins earlier with a pause.

At least, this is what I THINK is happening… Any way to handle this situation?

It’s not ideal, but you can set the “fuzziness” in the tracklog dialog to something large. —Jeffrey

— comment by Kaitlyn on July 1st, 2015 at 8:25am JST (1 month, 3 days ago) comment permalink

I traveled to a different timezone but left my camera as-is. Upon loading into lightroom i selected all and edited the capture time – everything worked fine. When I view the default view, I see the updated “Capture Time”. When I go to the “Geocoding” view, the “Date Time” field still has the old value – shouldn’t this also reflect the date?

When I do the geocoding, how do I now know which timezone to pick since I am seeing two dates?

Many thanks!

Ah, good catch. Photos times are a complete rat’s nest in Lightroom, and the way they’re exposed to plugins is often simply wrong. But I figured out how to get the proper date in most situations (videos are still a separate issue) and just pushed a new version of the plugin that has the better date in the metadata view. Hopefully you’ll see only the one (fixed) date from now on…. —Jeffrey

— comment by Kaitlyn on July 1st, 2015 at 11:25am JST (1 month, 3 days ago) comment permalink

Using v 20150703.259 on LRCC. I tried to use the “Import Location from Google Earth” (GE 7.1.5.1557) option which I’ve used many times before. I lined the crosshairs up just where I wanted them. On the plugin dialog it says Valid location not yet specified. The plugin dialog blinks “fetching”, but no coordinates appear. What’s going on here?

Sadly, this feature is not supported by Google and for mysterious reasons has stopped working for many folks at various upgrades. It sounds as if perhaps you didn’t upgrade and that there’s no obvious trigger here, but then we’re back to the “mysterious” aspect of it. The plugin uses a feature that Google added long ago, but then abandoned, so I never know whether it will actually work. It seems to work for me, but many hours debugging (with other users for which it no longer works) has not been fruitful. In other words, I’m at a loss. )-: —Jeffrey

— comment by Terry Straehley on July 28th, 2015 at 12:41pm JST (1 week ago) comment permalink

Hi Jeff, thanks so much for your very useful plugins! I have used GeoSetter in the past to geotag my photos. I use a GPS tracklog that generates GPX or KML files. Usually, I take a picture of my GPS device while hitting the waypoint button so that I have a picture at the exact time of the waypoint. GeoSetter then allows you to set a specific picture to the time of the waypoint, adjust all the other pictures with the same offset, and then automatically assigns the GPS coordinates of the tracklog to the photos. I was trying to incorporate as many steps of that process into LR6 as possible. Does your geotag plugin allow assigning a waypoint to a photo to fix the time, then assign the coordinates based on that offset? I see that your plugin does allow for the offset, but was wondering if there was a way to incorporate the waypoint aspect (helps me not have to worry too much about getting my camera time exactly aligned with the GPS unit!). Thanks! I’m in Dallas.

I didn’t quite follow the whole waypoint thing, but what I suggest here is to just take a photo of the GPS unit’s clock some time during the day, then after loading all the photos in Lightroom, select all photos and most-select the clock-display photo. Then in the Metadata Panel click on the list icon next to where the time would be shown if only one photo was selected, and that’ll allow you to update the times for all photos by entering the correct time for the clock-display photo. Now all your photos have an accurate time, and you can delete the clock-display photo and geoencode the rest via the tracklog (using the Map module or my plugin). —Jeffrey

— comment by Aashoo Tandon on July 30th, 2015 at 1:58am JST (5 days, 17 hours ago) comment permalink
Leave a comment...


All comments are invisible to others until Jeffrey approves them.

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


You can use the following tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting