.
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 5 (and older versions as far back as Lightroom 2, 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 )

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

Comments so far....

One word: awesome. I wonder if you’d be able to access Google Earth’s api via LR and use that for geotagging – it’s pretty awesome, fast and from what I can tell pretty simple to fetch gps coords/info from it. Not sure how this would work with the LR plugin structure but this would be super awesome :)

Thanks for all your hard work.

I’ve looked around and haven’t seen any way to tie them together, but apparently, with a simple Google Earth plugin like this you can enable a “copy location to clipboard” functionality, which you should –in theory– be able to paste into my plugin. —Jeffrey

— comment by M on October 30th, 2008 at 1:01am JST (6 years ago) comment permalink

Another great plugin Jeffrey! I agree with the other commenter, being able to connect to Google Earth would rock. But I do understand that you have a life. :-)

Have you seen my blog? If so, where do you think I have time for an actual life? :-) —Jeffrey

— comment by Beau Harbin on October 30th, 2008 at 1:13am JST (6 years ago) comment permalink

I have little problem with that (awesome) plugin. A have a gpx file that covers date 2008-08-15 from around 10:00 to 19:00. I have pictures (Nikon NEF) that were taken on that day. In lightroom metadata viewer (metadata set: All) i have three dates that describe my example picture:
Date Time Original: 2008-08-15 14:14:42
Date Time Digitized: 2008-08-15 14:14:42
Date Time: 2008-08-16 00:55:03

When i switch to Default metadata set i can see capture time:
Capture Time: 14:14:42
15 August 2008

The problem is when i try to geoencode that picture with my gpx file. At the top of the geoencode form there is a text: “Selected: one image dated aug 16, 2008 12:55%p” and at the bottom: “Tracklog does not cover any of the selected images”. Obviusly the plugin does not use the correct capture time (Date Time Original). It uses the time that describes the moment when i copied the files from my camera to computer (Date Time).

I use Lightroom 2.1 on Windows Vista

I think this is fixed in version .8 —Jeffrey

— comment by maciek on November 2nd, 2008 at 7:24am JST (6 years ago) comment permalink

Hi Jeffrey,

I was wondering if it would be possible to update your metadata-viewer preset builder (try saying that fast eh… ;) ) to include the shadow GPS fields.

It would be very nice to be able to check the fields from one preset without having to constantly toggle back and forth…

Yeah, it’s definitely on my todo list. Until I get around to it, you can manually update the preset file with tokens that look like info.regex.lightroom.gps.Location or (replacing the last word…) Altitude, Speed, Bearing, or Geoencoded. —Jeffrey

— comment by Balaji Dutt on November 2nd, 2008 at 6:09pm JST (6 years ago) comment permalink

Hi Jeffrey,

I did try to edit the LRTEMPLATE file but it looks like I’m missing something. Here’s what I did:

“com.adobe.country”,
“com.adobe.isoCountryCode”,
“com.adobe.separator”,
“info.regex.lightroom.gps.Location”,

— comment by Balaji Dutt on November 3rd, 2008 at 11:04pm JST (6 years ago) comment permalink

Bugger it – I forgot to use HTML entities and half my comment got swallowed :(.. Trying again.

I opened up the LRTEMPLATE file and put in the following:

“com.adobe.country”,
“com.adobe.isoCountryCode”,
“com.adobe.separator”,
“info.regex.lightroom.gps.Location”, *added*
“info.regex.lightroom.gps.Geoencoded”, *added*
“com.adobe.separator”, *added*

When I launch LR, I can see an additional separator line after the Country Code but no shadow GPS fields. Any advice?

— comment by Balaji Dutt on November 3rd, 2008 at 11:06pm JST (6 years ago) comment permalink

Hi Jeffrey,

It looks like you might not be reading the best parameter for Google Maps URLs. If the URL has a ‘latlng’, then you can use the first two parts of the comma separated value list (with appropriate decimal places), rather than the value it looks like you’re using (sll?).

This gives you the lat/long of the business listing (ie, copy the URL for the ‘more info’ link, or a link generated by clicking the “Link” link on the top right of the page). Otherwise you end up setting the lat/long to the centre of the viewport, not the business listing’s URL.

I’m pretty sure that I want the center of the currently-displayed map in all situations, but am open to discussion about it. I’d think it’d be more confusing than not for it to be anything else. I’ll see whether I can document it more clearly… —Jeffrey

— comment by Andy on November 6th, 2008 at 5:38pm JST (6 years ago) comment permalink

Anybody else having problems reading GPX tracklogs with v10?

No matter which log I try, I get, “No datapoints found in that tracklog“.
I have GPX files from various sources, including two Garmin handhelds and GPSBabel.

I downgraded to v9 and it works! (As long as I don’t give it an empty one, heh)

Doh, stupid error I stupidly introduced in the previous (stupid) version. Sorry, and thanks for the report. Should be fixed in .11 —Jeffrey

— comment by Peter Davis on November 7th, 2008 at 1:30am JST (5 years, 11 months ago) comment permalink

Looks like the “line 12415″ error happens on photos when I was standing still for a long time. My GPS (Garmin Colorado) only saves trackpoints while moving.

Jeffrey, would it be possible to implement a “120 seconds” OR “50 meters” setting?

Workaround: increase the “fuzziness” parameter, if you’re sure you were recording tracks when the photo was taken. I had to increase up to 1000(s) for some photos, but it avoids the “line 12415″ error.

Your suggestion is not a workaround… it’s exactly what “fuzziness” is for (so it’s a good suggestion :-)). If you get the error again with .11 or later, could you please let me know (citing, please, the full error message and the exact version you see it in)? Thanks. —Jeffrey

— comment by Peter Davis on November 7th, 2008 at 2:19am JST (5 years, 11 months ago) comment permalink

Hi,
After downloading the new version of plug-in, I still have the same problem with the error message:

+287.0: At line 12567: ?:12654: attempt to index a nil value

Please help me out. Thanks.

Version .12 should fix this. I hope. —Jeffrey

— comment by Lucas Liu on November 9th, 2008 at 5:57am JST (5 years, 11 months ago) comment permalink

Hi Jeffrey,
I’m still struggling to make this work in my environment.

A couple of problems:-

1) When I select a track log (Magellan) that has 2000 points; the Plugin indicates it can find only 29 points in the file.
I’ve successfully loaded the track into Google Earth so it looks like it’s 1/2 way reasonable.

2) When trying to encode my pics for that file I still get error messages along the line of

+61.2: At line 12567: 12692; attempt to index a nil value.
The process seems to hang on picture 225 of 251.

I’ happy to send the tracklog if that will halp.

Oh, and I’m on version…11

Regaards
Leonard.

Thanks to the tracklog you sent, I was able to fix these (version .12 has the fixes). Thanks. —Jeffrey

— comment by Leonard Abbey on November 9th, 2008 at 4:32pm JST (5 years, 11 months ago) comment permalink

I am just reading the update dialog for version 12. I did have a write-back error in Version 11, but I am not certain whether it was user induced or a problem in the applet.

I tried writing back several sample photos singly and in small batches and all went well. Then, to finish the job of writing back to real GPS all of the remaining photos that had shadow GPS, I highlighted all the photos that still had shadow gps data, performed a saved metadata to file operation and then performed the write-back function. It took a long time for this operation to complete, as there were 157 photos in this batch. I did not watch this operation closely, and came back after this was finished. I then did a read metafile operation and none of the photos were retagged but the shadow gps data had been purged.

This was yesterday, and I decided to wait before doing anything else. I do have a Time Machine Backup of the files before they were altered and can go back– a bit laborious, as I did other things in Lightroom and Photoshop to some of the photos, which are more important for me to retain than the GPS data.

I have not yet updated to version 12, and am leaving 11 on in case there is something further to test.

— comment by Ina on November 11th, 2008 at 1:29am JST (5 years, 11 months ago) comment permalink

Something really weird just happened.

I had closed Lightroom up after I sent you the last message. I had a file open in Photoshop that I saved and then closed Photoshop. I reopened Lightroom to ensure that my photo was back in Lightroom and performed a Read Metafile from File operation. It took a long time processing and was going back reading several photos. When this was finished it ALL the photos I had tried to write back yesterday were tagged.

Yesterday, I had tried the read metafile several times before I was (prematurely) sure that the GPS data was “lost.”

I have just performed a Lightroom Catalog Relaunch and Optimize operation and the Geotags are still there.

Ina

— comment by Ina on November 11th, 2008 at 2:04am JST (5 years, 11 months ago) comment permalink

Hi,

Thanks for keeping on updating the new version. After updating to Ver. 12, the original message was gone but came with another error message.

At line 13192: ?:13280: attempt to index a nil value

I know it’s annoying but I appreciate your effort on this. Thanks.

Lucas

— comment by Lucas Liu on November 11th, 2008 at 12:16pm JST (5 years, 11 months ago) comment permalink

Hi Jeffrey,
any plans to expand beyond gpx files? I use an amod agl3080 for tracking my routes and it produces a .log file in nmea0183 format. I know this can be converted to gpx but would great if your plugin supported it directly.

thanks, appreciate the great work you do.

Ben

Yes, of course, I’ll probably embed GPSBabel into the plugin eventually. Have been ultra crazy busy lately, as my blog and the plugin update history perhaps hints at ;-) —Jeffrey

— comment by Ben on November 11th, 2008 at 1:35pm JST (5 years, 11 months ago) comment permalink

I note that you have a link to Geohash for manual geotagging.

As my two bluetooth geotaggers’ interfaces have not worked smoothly since I changed to a MacBook Pro from a PC, I have been doing a lot of manual geotagging.

I find that GetLatLon.com does a better and easier job of manual tagging than GeoHash.

It has 3 advantages over GeoHash:

1. You can search by place name as well as address: eg., Museum of Natural History, NY, NY or w 77 street and central park west, ny, ny.
2. You can interactively click on a nearby point and read the new lat/long data. This is especially helpful if the automated tagging isn’t exactly where you want it.
3. A comma is automatically inserted between the latitude and longitude.

Ina

Geohash is an idea… a way to encode a latitude/longitude pair as a single entity that affords some important features for geospacial-related programming. I added support for them because it was easy and it could be useful to someone, but I certainly don’t mean to suggest that their web site is a convenient way to find points and geoencode here. On the other hand, it sounds as if GetLatLon.com is perfect for doing that, so thanks for the reference! —Jeffrey

— comment by Ina on November 11th, 2008 at 10:06pm JST (5 years, 11 months ago) comment permalink

Thanks for this great plugin!
I tested Lightroom one year ago and I found it very useful for the whole task of photo management. But I dont understand why such a professional (and expensive) tool cannot handle geotagging, for me this is essential. So I decided to go one with a set of free apps: RawShooter Essentials, GeoSetter, Picasa, Adobe DNG Converter, …
But with your plugin the situation has changed.
Thx again from Italy.

— comment by Georg on November 11th, 2008 at 11:55pm JST (5 years, 11 months ago) comment permalink

Hi Jeff

I just tried to use the geoencode for the first time. I’m using a Sony GPS-CS1 which simply writes a log file to embedded memory which I downloaded to my Mac. When I invoke the plugin, I’m told there are no data points in the files.

The data does appear to be in the files, though I’m not sure if it is in a compatible format.

Any help would be appreciated.

Cheers

Convert to the GPX format that the plugin wants with GPSBabel. —Jeffrey

— comment by Graham on November 18th, 2008 at 12:39pm JST (5 years, 11 months ago) comment permalink

Hi Jeffrey:

I have been using your GeoSetter extensively now for the last few weeks. I have only used the Static geotagging. I have not encountered any further errors, so far. However, I do have a couple of enhancement suggestions that would save time and hassle:

1. Allow the input box to remain open until the user says “done.” In other words, allow both geocoding and writing back shadow data wihout the pluglet automatically closing between steps. I always geoencode and then immediately write shadow data back.

It’s on the to-do list to include a “write back shadow data to file” checkbox to the geoencoding tabs.

2. Have an option to write the reverse location, city, state, country and country data back to the metadata. Perhaps a checkbox to select which of the metadata one would want to write back.

That’s also on the to-do list, once I can find a good source of data. I currently put reverse geocode data from Google as information in some places, but it’s much to spotty to rely on. —Jeffrey

Thanks so much for a great applet and great support.

Ina

— comment by Ina on November 23rd, 2008 at 10:56pm JST (5 years, 11 months ago) comment permalink

Jeffrey:
The write-back option on the Geocoding page works very well.

It took me a couple of minutes to figure out that, in order to use this option, I had to go to the Wirte-back page to enable the function on the Geocoding page. Perhaps a small note on the geocoding page will prevent any frustration.

Again, thanks.
Ina

Is the “(to enable this option, see the “Write data back” tab and its associated warnings and instructions)” note somehow insufficient? —Jeffrey

— comment by Ina on November 28th, 2008 at 1:18am JST (5 years, 11 months ago) comment permalink

Jeffrey:

Re: “Is the “(to enable this option, see the “Write data back” tab and its associated warnings and instructions)” note somehow insufficient?”

If you first look at the Geocoding page , there is the box asking you if want to wirte back data. By default, it is greyed out and there is no instruction on that page telling the user how to activate the box.

Ina

— comment by Ina on November 28th, 2008 at 1:34pm JST (5 years, 11 months ago) comment permalink

This seemes like a great plugin! Right now I can only think of one improvement: Give a better oportunity to manually geocode one/many pictures with a userfriendly interface. I have no idea how hard it is to implement, but maybe the maperture plugin (for aparture) could be some inspiration? videodemo here.
Anyway, thanks for your efforts!

That is indeed a wonderful interface. It’s not easily possible now in Lightroom, unfortunately. —Jeffrey

— comment by evero on November 29th, 2008 at 9:24am JST (5 years, 11 months ago) comment permalink

Jeffry, I have been trying to find a way to manually geotag my photos in Light Room and ran across your plugin. It is a great idea but when I manually put in the coordinates like this +28° 25′ 13.71″, -81° 35′ 5.11″ and press the button to geotag the photo I get this error message ?:1280:bad argument #1 to ‘?’ (number excpected, got nil). I am using LR 2.0 Am I doing something wrong? Can you help? Thanks.

That should work, and does for me. Are you using the latest version of the plugin? (You’re not using the latest version of Lightroom…. why?)
By the way, it’s “Lightroom” and not “Light Room”. —Jeffrey

— comment by Jim on November 30th, 2008 at 5:48am JST (5 years, 11 months ago) comment permalink

Jeffrey, Thank you for responding. I am actually using Lightroom 2.1, sorry I missed informed you. I went to the plugin manager, clicked on “check for new version now” and it says that I have the latest version. The version is 20081126.21.

— comment by Jim on November 30th, 2008 at 11:04am JST (5 years, 11 months ago) comment permalink

Hi Jeffrey, I’ve just updated to the last version (20081204.23) and when I try to “View location at Google earth” get the following error:

‘Attempt to access property “url” that’s not declared in Info.lua’

César.

Oops, sorry about that. I just pushed .24 that fixes it. Thanks for the report! —Jeffrey

— comment by César on December 5th, 2008 at 7:44pm JST (5 years, 11 months ago) comment permalink

I noticed that it sort of looks like you can make a Preset to set shadow GPS metadata, but it doesn’t actually work (similarly to how Sync Metadata looks like it works, but doesn’t actually). Is there any way to do something like a preset? I’d like to make it easier to tag frequent locations like my house… right now I just have a text file with common GPS coordinates but that’s a little awkward.

— comment by dave glasser on December 9th, 2008 at 4:57pm JST (5 years, 10 months ago) comment permalink

First, your plugins are great. I wouldn’t be using LR if it weren’t for them.

I found an issue with this one however, (.26) it seems the popup window is too large for my screen. I’m using a 12″ 1024 x 768 screen (its on my PowerBook G4), and I can’t cancel the plugin window. I’m assuming that there is a cancel button below the geocode images button. If there is, it is too far down for be to access.

— comment by Warren on December 12th, 2008 at 6:23pm JST (5 years, 10 months ago) comment permalink

Hi, this plugin is ideal and unlike the others I’ve tried it does a good job with timestamp fuzziness. But I’m having trouble writing the metadata. I’ve tried the houdahgeo trial (but it’s way way too expensive to buy) and when I’ve re-read the metadata afterwards an extra GPS field has appeared at the bottom of the default metadata view without the need for a plugin. But with your plugin, after doing “write data back” and reading the metadata from the files the GPS field isn’t appearing. I’m using Lightroom 2.1 for Mac OS X 10.5.5

Any ideas?

— comment by MRKisThatKid on December 15th, 2008 at 5:20am JST (5 years, 10 months ago) comment permalink

Been playing around a lot with the plug-in and seemed to have found an issue. When I try to sync the GPS Support data between two images, the GPS data does not seem to move to the new image. I have selected the images correctly and the one with the data is highlighted as primary. I right click and go into the Metadata>Sync Metadata interface. I select the GPS Support and have the fields checked. Hit Synchronize and nothing happens. Well just thought I would let you know. Thanks much.

Lightroom doesn’t allow you to sync GPS data that way. If you want to sync the shadow data that my plugin deals with, you can do so in its Geoencode dialog, selecting “Geoencode Static Location” and then use the [import location from active image] to plugin in the data that will be applied to all the other images. —Jeffrey

— comment by Beau Harbin on December 15th, 2008 at 12:16pm JST (5 years, 10 months ago) comment permalink

Hi Jeffrey,

I seem to have broken your excellent GPS plug-in.

Below is error message.

Any help would be appreciated.

Buzz

Execution/debug log for Jeffrey’s gps plugin for Lightroom, version 20081223.29
Log started December 24, 2008 04:00PM local
December 25, 2008 08:00AM JST
Plugin folder: /Applications/gps-jfriedl.lrplugin
Lightroom version 2.1.0 build 512205 for Macintosh (Locale: en).
———————————————————————————————-

?:15018: attempt to index a nil value

— comment by Buzz on December 25th, 2008 at 8:03am JST (5 years, 10 months ago) comment permalink

Hi Jeffery,

I’m having a problem geoencoding images on my EeePC, I dont seem to have the “Begin” button under the tracklog tab. Would it be something to do with my screen only supporrting 1024×600(724)?

Mark

— comment by Mark Duncombe on December 25th, 2008 at 9:13pm JST (5 years, 10 months ago) comment permalink

Stumbled on a bug when I was trying to encode about 1300 images with one location. Long story short I should have had a look in the log file instead of trying several hours of configurations! The Write-Back function appears to cough on files located in folders containing an apostrophe. (I’ve saved the log if needed). I realize that’s partially my fault for using non-standard characters in a file system (honestly, I should have learned my lesson when it’s given me problems in other programs) though Windows allowed me to so I didn’t think about it ;)

The bug is that while it won’t write to those photo’s XMP files, it won’t write to ANY of the other selected files that are part of the same batch. The processing dialogs all appear to show things going along as normal and it comes up with the “Success” dialog saying “XMP files actually written: ” when none have. Don’t know if there’s a fix possible or if I should just rename my folders without special characters like they should be.

One non-bug but typo, when the Flush shadow data is selected, the “go” button on the first tab of the Geoencode dialog says “Shadown” :)

Thanks, both are now fixed in .32. —Jeffrey

— comment by JasonP on December 28th, 2008 at 11:25pm JST (5 years, 10 months ago) comment permalink

Just installed your GPS and Flickr plugins a couple of days ago. Went to use them today and say the “New Version Available” text, so I went in to plugin manager, and tried to install the new versions by clicking on “Upgrade Now”. The debugging immediately ungrayed, and when I looked at the log file, here’s the gist of the errors I’m getting:

Execution/debug log for Jeffrey’s gps plugin for Lightroom, version 20081227.31
Log started December 28, 2008 05:47PM local
December 29, 2008 09:47AM JST
Plugin folder: C:\Program Files\Adobe\Adobe Photoshop Lightroom 2\Plugins\gps-jfriedl.lrplugin
Lightroom version 2.2.0 build 523352 for Windows (Locale: en).
———————————————————————————————-

At line 1884: before trap
+0.0: At line 13081: in ShowUpgradeDialog
+0.0: At line 12844: in unzip_cmd()
+87.1: At line 1884: before trap
+87.1: At line 13081: in ShowUpgradeDialog
+87.1: At line 12844: in unzip_cmd()
+89.5: At line 1884: before trap
+89.5: At line 13081: in ShowUpgradeDialog
+89.5: At line 12844: in unzip_cmd()

And for Flickr Uploader:

Execution/debug log for Jeffrey’s flickr plugin for Lightroom, version 20081224.62
Log started December 28, 2008 05:53PM local
December 29, 2008 09:53AM JST
Plugin folder: C:\Program Files\Adobe\Adobe Photoshop Lightroom 2\Plugins\flickr-jfriedl.lrplugin
Lightroom version 2.2.0 build 523352 for Windows (Locale: en).
———————————————————————————————-

+768.8: At line 1889: before trap
+0.0: At line 22569: in ShowUpgradeDialog
+0.0: At line 22332: in unzip_cmd()

BTW: these both seem to be dieing around a ‘zip’ command. I do not have WinZip. I have WinRAR, which handles all of my zipping and unzipping needs. Could this be part of the problem?

Thanks for cool tools!

PS: I’m looking forward to the feature that will upgrade Headlines, Captions, Keywords, and other Metadata on Flickr without having to re-upload the files!

— comment by BrookB on December 29th, 2008 at 9:56am JST (5 years, 10 months ago) comment permalink

Hi Jeffrey,

I was wondering if you want to support an import of Geodata from Picasa. Personally, I like the tagging features of Picasa, not only regarding geo data but also person tagging.

Cheers,
Alex

— comment by Alex on January 5th, 2009 at 1:50am JST (5 years, 10 months ago) comment permalink

Hi Jeffrey,

thanks for your great pluggin, i really love it!!!

i just noticed on pictures geoencoded by other means (geosetter) and imported to lightroom, the geodata shows up in the exif, and there’s a neat link right there to open google maps at location.
would this be hard to have this with your plugin ? could be a nice addition.

anyways thanks a lot for your pluggins !

Alex

Only “real” GPS data gets the direct link (to Google Maps if you click, or to Yahoo! Maps if you ALT-click). This is a basic (and unfortunate) limitation of the plugin architecture. If you convert the shadow data to real data (via writing back, then reading metadata), you’ll get the clickable coordinates. BTW, the various “view location in…” menu items I added work with both real and shadow location data, so they’ll always work. —Jeffrey

— comment by Alexis on January 11th, 2009 at 10:20am JST (5 years, 9 months ago) comment permalink

How does one search for/filter in photos that have GPS info?

The same way you do other filtering, via the Library Filter. In Grid mode, hit the “/” key to bring up the filter controls. —Jeffrey

— comment by Rubin110 on January 25th, 2009 at 10:23pm JST (5 years, 9 months ago) comment permalink

writing back worked perfectly, thank you Jeffrey!

— comment by Alexis on January 26th, 2009 at 6:03am JST (5 years, 9 months ago) comment permalink

This is exactly what I looking for…

I like automatic write back option. Thank you very much.

— comment by secrice on January 28th, 2009 at 11:10pm JST (5 years, 9 months ago) comment permalink

Thank you for this great tool. I have a question about the expiry. I will probably be using GPS-Support offline for up to three months this summer doing remote field work in the arctics. Will I run into problems with the plug-in expiring?
Best,

Sorry for the delay in responding, Lars…. when your question came in I knew I was planning on removing the expiration. Modern versions no longer expire, so upgrade and you’ll be fine. —Jeffrey

— comment by Lars on January 30th, 2009 at 4:16am JST (5 years, 9 months ago) comment permalink

Hi Jeffrey. Fantastic tool. I noticed a problem when geocoding some JPEGSs recently – writing back the shadow data doesn’t result in it appearing in the EXIF field on Lightroom whereas the DNGs I geocoded did. Is there a difference ib how your plugin or lightroom handles JPEGs?

— comment by Warren on January 31st, 2009 at 12:20pm JST (5 years, 9 months ago) comment permalink

Hi Jeffrey. Found the problem – exiftool was throwing a minor error about the maker notes offset. Extract from log below.

C:\Users\Warren\Documents\Lightroom Plugins\gps-jfriedl.lrplugin\inject-gps: [minor] MakerNotes offsets may be incorrect (fix or ignore?) (Duplicate Orientation tag in IFD0)

The solution I’ve used is to add the following line in the inject-gps perl script after you create the image object (line 64):

$exifTool->Options(IgnoreMinorErrors => ’1′);

It might be a good for you to include in the user interface a tick box that turns on or off the minor error checking.

Thanks again for the tool. It’s fantastic.

Warren

— comment by Warren on February 6th, 2009 at 11:40am JST (5 years, 9 months ago) comment permalink

Hi Jeffrey,

in my case the write back does not work. Any Ideas?

Frank

— comment by Frank on February 10th, 2009 at 2:54am JST (5 years, 8 months ago) comment permalink

Now again with subcribtion.

The Problem is that the geoencoding itself works fine. I can see the shadow gps data. But after write back the data I cannot see it in LR or elsewhere. Also after rereading metadata from file no effect.

Frank

— comment by Frank on February 10th, 2009 at 3:09am JST (5 years, 8 months ago) comment permalink

Hi again,

I’ve found the problem. The write back tool does not find “ä” in filename and so the write back tool does not find the filename.

Frank

Thanks for debugging this, Frank. I think that somewhere along the line the character encoding of the filename is being changed (e.g. from Latin1 to UTF-8) and that causes a name mismatch later on. I don’t know enough about the details to know what to blame or how to fix…. yet. I’ll dig around. —Jeffrey

UPDATE: this should be fixed as of verision .44. Yikes, it was tough! I hope the fix works. —Jeffrey

— comment by Frank on February 10th, 2009 at 3:24am JST (5 years, 8 months ago) comment permalink

Hi again Jeffrey,

I have an another request about this plugin : Would it be possible to add a combobox list in the tab Geoencode Static Location, in order to record GPS coordinates of a list of places that are used frequently (eg home, work …). In this case I don’t always use my GPS unit and I need to search a photo previously geoencode.

I think it’s an interesting feature to simplify the workflow

Thank you for the answer even if it is negative

Absolutely. I’ll be adding that soon. —Jeffrey

— comment by Florent Bouckenooghe on February 10th, 2009 at 7:40am JST (5 years, 8 months ago) comment permalink

I am getting the followig error when trying the .46 download and upgrade:

“Access to undefined global: ReloadPluginFile”

I would like to second the above suggestion for a combobox that would enable a selection of frequently used places.

That bug is fixed in .46, so, unfortunately, you may have to do a manual install from the version you have to get there. Sorry for the hassles. None of this automatic-upgrade stuff is built into Lightroom…. I hacked it all together myself, and it’s still got some rough edges. Sorry. —Jeffrey

— comment by Ina on February 22nd, 2009 at 8:40pm JST (5 years, 8 months ago) comment permalink

GPS and “ÖÄÜ” is fixed! THANX!

— comment by Frank on February 23rd, 2009 at 1:16am JST (5 years, 8 months ago) comment permalink

Hi Jeffrey,
Thanks so much for your plugins, its been a real hassle for me to keep my flickr account in decent sync with my lightroom photos, and you’ve done some great work. I’ll be sure to donate/register as some point before april.
I wonder if you could think of a way to import the GPS data from Flickr and match it up to Lightroom photos in the same way the Export Plugin does it (by time taken). That would be the ideal solution, since almost all of my Flickr photos are geotagged, and none of my lightroom originals are.
Thanks Jeffrey, keep up the good hobby… I mean work.

–Evan

These kind of things are definitely on the to-do list. —Jeffrey

— comment by Evan Payne on February 23rd, 2009 at 7:38am JST (5 years, 8 months ago) comment permalink

Jeffrey,
Thanks for your incredibly useful plugins. I’ve started using the Geoencoding plugin and am wondering if it is possible to run other command line arguments in the GPSbabel configuration box? For example, can I run a discard command to cleanup up a GPS track from an NMEA logfile?

-x discard,hdop=10,vdop=10,hdopandvdop,sat=4

I tried adding it to the argument -i “nmea” but had no luck. Do I need to change the syntax or is the plugin simply not configured to accept additional functions?

Best,
Steve

You should be able to use whatever arguments you like… the plugin doesn’t care, except that it ensures you don’t set input/output filenames (it adds them) nor the ouput format (it sets it). You do have to be very careful about how you quote the arguments, and that’s dependent on the OS. Check out the plugin log (referenced in the upper-right corner of the Plugin Manager) for hints to the problem; feel free to send it to me (there’s a button in the Plugin Manager for that) if you need a hand. —Jeffrey

— comment by Steve Johnson on February 24th, 2009 at 4:50am JST (5 years, 8 months ago) comment permalink

I just updated LR to 2.3, and my Mac OS to 10.5.6. I used the LR Plugin Manager to download and install the latest GPS-Support. But…when I hit the Reload Plug-In button I received: “An error occurred while reading the schema for the plug-in “GPS Support”. The plug-in will be disabled.”.

As per the release notes, you have to restart Lightroom when upgrading this time. Give it a try, and if that doesn’t fix it, send me an email with details…. —Jeffrey

— comment by Denis on March 4th, 2009 at 8:46am JST (5 years, 8 months ago) comment permalink

I’m just trying out your plugin. Great work!

One comment, when using the Write Shadow Data to Files feature, the window with the progress bar that popup does not change (i.e the progress bar does not indicate how many files are done).

Am I doing something wrong? This is on LR 2.3 and your latest version of GPS-Support plugin.

Ahmad

You’re not doing anything wrong. The actual writing back is done by an outside process, all in one batch, so the plugin doesn’t know anything about the progress until it’s all done. There’s an alternative that allows the progress bar to be updated properly, but it’s significantly slower, so I opted for speed rather than reporting. —Jeffrey

— comment by Ahmad on March 12th, 2009 at 4:02pm JST (5 years, 7 months ago) comment permalink

Hi Jeffrey,

Just updated and registered some of your plugins. I have been geocoding most of my photos for the past two years and displaying them on a map on my website. I will give your plugin a try, might make encoding easier.

I also loaded the plugin on my netbook for use in the field, however the registration and the geocoding screens are too large for its 1024×600 screen – would be nice if you could make them slightly smaller – it saves having to plug in an external monitor to make a quick look (its a bit small to use for serious work – but is usable with Lightroom).

Mike
Delft, The Netherlands.

I’ve spent considerable time trying to get the dialog smaller, but there’s just so much packed in there, I’m not sure what to do. You can run Lightroom on a 1024×600 screen? Wow! —Jeffrey

— comment by Mike on March 13th, 2009 at 5:14am JST (5 years, 7 months ago) comment permalink

Mike,Jeffery

I run LR on my EeePC 901 which has a button that lets change from its default 1024×600 into 1024×768 with either the screen scrolling or the screen compressed. I find that if I use this mode before running LR then Jefferys GPS plugin works just great. I then switch back to native resolution when finished with the plugin.

And yes LR does work fairly well on the little EeePC, good enough for reviewing,tagging and writing comments, with some basic corrections. Just the job when travelling.

Mark

— comment by Mark Duncombe on March 13th, 2009 at 7:49pm JST (5 years, 7 months ago) comment permalink

I run the MSI Wind with OSX and don’t have the option of 1024×768, only 1024×600 so the only option is to plug in an external monitor, unless Jeffery can shrink the box just a little.

Mike

I think I’ll have to add a small-monitor mode, or something, getting rid of a bunch of prose, the ugly icon at top, etc. Give me a few days to see what I can come up with… —Jeffrey
Okay, I just pushed .49, which adds a small-dialog mode that’s usable down to 800×600. There’s a checkbox in the Plugin Manager to enable it. —Jeffrey

— comment by Mike on March 13th, 2009 at 10:17pm JST (5 years, 7 months ago) comment permalink

Mike

Lightrooms minum requirements does state 1,024×768 display so its possible we might come across other problems at 1024×600 but so far I have not found any, just the one using Jefferys GPS plugin so far.

I wonder if there any windows utilities out there that will allow a virtual 1024×768 on your MSI? Not great for editing images but might help you use Jefferys plugin.

— comment by Mark Duncombe on March 13th, 2009 at 11:48pm JST (5 years, 7 months ago) comment permalink

Hi Jeffrey,

Thanks for the small dialog box – thats really great – works well on the MSI Wind.

— comment by Mike on March 14th, 2009 at 10:13pm JST (5 years, 7 months ago) comment permalink

Hi Jeffrey

Looks good on the Asus EeePc901 as well

Thanks

— comment by Mark on March 15th, 2009 at 3:59am JST (5 years, 7 months ago) comment permalink

Hi Jeffrey,
Thanks for this great plug-in…
I would like to make a small suggestion: could it be possible to split the written shadow process in blocks, 10% sounds nice enough, as to give some feedback on progress withou penalizing much the speed?
I’m facing some problems when trying to process large number of images as you really don’t know if it is working or just hang-up.
Also, sometimes it fails to write an image and the entire process is stoped, no feedback on written images is provided… with the 10% blocks it should be easier to delimitate what are all the written images without digging in a large log file.
Thanks

I’ll take a look into splitting it up, but in the mean time, if you run into the situation where it fails and doesn’t tell you where/why, please send me the log for that run (via the send-to-Jeffrey button in the upper-right section of the plugin manager). —Jeffrey

— comment by Rafa on March 16th, 2009 at 6:39am JST (5 years, 7 months ago) comment permalink

… maybe it’s me or Flickr, Jeffrey, but… seems there’s something wrong with GPS Date (and Time).

Yesterday I manually Geoencoded some files prior to uploading them on Flickr. Here are the resulting Dates/Times:

Date and Time (Original): 2009:01:31 18:32:22

Date and Time (Modified): 2009:03:22 04:09:25

GPSDate Time: 2009:03:03 17:32:22

So… I argue:

1) “Modified Date/Time” are those the picture has been uploaded to Flickr
2) “GPS Time” is *original’s* Greenwich Time (I’m in +1 Timezone)

but… where does that “GPS Date” come from? (the picture was manually Geoencoded on 20 or 21 March 2009)

Any help, please?

Wow, that’s really odd. Can you send (via email) info about the file at Flickr, and if the original is not available there, a copy of the original? —Jeffrey

— comment by paolo savonuzzi on March 22nd, 2009 at 7:35pm JST (5 years, 7 months ago) comment permalink

… sorry, I forgot to specify:

those are Date/Times as reported on Flickr’s “More Properties” page (btw: how can I see GPS Date/Time in Lightroom? Both “All Plugin Medatada” and “Geoencoding…” presets *do not* show either)

pictures where manually geoncoded using GoogleEarth

thanks!

— comment by paolo savonuzzi on March 22nd, 2009 at 7:43pm JST (5 years, 7 months ago) comment permalink

Hi Jeffrey! I’m writing from California to say thanks for the plugins and also to report a bug. If the gpx file is in a directory with commas in the name, the plugin can’t find the gpx file. e.g. “/pictures/biking with Scott, Anne, and Bob/track.gpx”. The plugin gives an error saying, “Tracklog error: “/pictures/biking with Scott” does not exist. I haven’t tried other punctuation such as “&” and “:”, which are valid in Mac OS X directory names.

Fixed in .54. —Jeffrey

— comment by Vincent Mo on March 23rd, 2009 at 11:15am JST (5 years, 7 months ago) comment permalink

Great plugin. Thank you. One question–I wanted to add GPS data to photos I geoencoded in Picasaweb some time ago. The Picasa photos were altered, so I couldn’t just import them & be done with it. I figured I had to encode them one at a time, and so I used presets in your plugin so I wouldn’t have to go back and forth between 2 versions of each photo copying GPS data. I never finished this, and now I have hundreds of presets, with all new presets being inserted at the bottom of a huge list. Is there any way to remove all of them other than one by one?

Thanks so much.

I just pushed a new version that adds a backdoor for you to clear out the list. See the release notes for details. —Jeffrey

— comment by Rob on March 27th, 2009 at 3:40pm JST (5 years, 7 months ago) comment permalink

Jeffrey,

Thank you so much for the additional feature. It works perfectly.

— comment by Rob on March 29th, 2009 at 5:32am JST (5 years, 7 months ago) comment permalink

Hi Jeffrey,

yesterday I tried your PlugIn and its great. Maybe you know the software GeoSetter. It’s a german program which I want to use at first for geotagging (know I use your plugin). This Tool has a view nice functions and maybe you can find somethink usefull.

As example there is an option to load metadata like “location”, “region”, “high” etc from the internet and fill this data to the picture. You can find it, if you doppelklick an image.

The show map is also usefull to find locations etc. It will be usefull to search directly with your PlugIn like in GeoSetter. Also if someone will load a Tracklog, the route will be displayed in the map. I will helps to verifying the route.

My current workflow is:
- I start the plugin
- Select the geodata (static, gfx)
- Write shadow data
- Start the plugin again
- Write data back to file
- Read metadata form file

Maybe it is possible to make a makro. It is a little bit ineffective to start the plugin two times. I know it is not important, but you say, that if someone have some ideas to improve the plugin… ;)

Optimized workflow:
- Start plugin
- Select geodata
- Select the option to write the data directly to the file and load it

This are my first improvement suggestions. But remember that this plugin is know also great!! Thanks a lot!!

greets,
neon

— comment by neon on March 29th, 2009 at 10:05pm JST (5 years, 7 months ago) comment permalink

Jeffrey: a very small glitch with “psd” files: “View locations in Google Earth” issues a “The selected photo is not geoncoded” alert (but it is) whilst it works just fine with both Google Maps and Yahoo! Maps

The Google Earth one actually considers all selected photos, not just the “most selected” one like the other options, so it seems that not all the selected photos are geoencoded. I should tidy that message up a bit, thanks. —Jeffrey

— comment by paolo savonuzzi on March 30th, 2009 at 5:10am JST (5 years, 7 months ago) comment permalink

… Jeffrey… I actually tried with just *one* picture selected! ;-/

— comment by paolo savonuzzi on March 30th, 2009 at 8:32am JST (5 years, 7 months ago) comment permalink

Hi

thanks for your great plugin, i use it alot. But recently i tried to write the gps data back to the files and most of the time it didn’t work.

There occured an error “?:3605: bad argument #2 to ‘?’ (value expected)”

See screenshort here Screenshot

What can I do to resolve this problem?

Thanks
Stefan

Try with the latest version, and if you get it again, send mail with the text of the error and the full version number of the plugin. —Jeffrey

— comment by Stefan Jäger on March 31st, 2009 at 9:19pm JST (5 years, 7 months ago) comment permalink

Hi,

enjoying your various projects, big fan of the flickr export.

Still testing the geoencoding thing and having trouble.

I use a Nokia E71 (program: sportstracker) to make tracklogs.
But I have to do a manual translation with gpsbabel, ’cause even with the settings correct, the program can’t find any datapoints in the original file. Bummer.

The arguments in gpsbabel that work with the manual translation are -p “” -t -i gpx -f and -o gpx -F.
I tried it with -i “gpx” and all combinations of -p “” -t -i gpx. I didn’t use -o or -f.

Please help, because for the moment it’s still easier to just place the pictures manually on the flickrmap!

Could you send me a small trackfile via email? It’s probably just using some version of the GPX format that I haven’t yet allowed for. —Jeffrey

— comment by bart on April 4th, 2009 at 4:03am JST (5 years, 7 months ago) comment permalink

Oh, and another thing.
I found the timezone setting confusing.
Both the gps and my camera are set to the same time and that means I have to set the timezone to Greenwich… which is odd, since I live in timezone UTC+1.

GPS satellites all work in UTC, so as far as I know, GPS receivers should be reporting tracklog times in UTC, or in something that can be converted to UTC. Maybe your tracklog is different… I’ll see when you send me one… —Jeffrey

— comment by bart on April 4th, 2009 at 4:09am JST (5 years, 7 months ago) comment permalink

Hello,
Thank you for your plugins. I use to geotag my pictures from Google Earth with AppleScript (which calls exiftools) in iView. As I now move to Lightroom I would like to do the same but unfortunately your plugin doesn’t interface wih Google Earth. You suggestion on first comment is windows-only, hence useless. May be you should ask some help from Google developers to implement this enhancement.
A second concern is valid for all your plugin : it seems you embed the exiftools instead of using the library installed.

The lightroom plugin infrastructure does not lend itself to working with Google Earth in this way. I’m not going to say “impossible”, but until I get an epiphany on how to do it, I remain open to suggestions. As for your second comment about exiftool, I don’t understand your concern. What is “library installed”? I embed the exiftool library because it’s not a standard part of the operating system. —Jeffrey

— comment by Alain on April 4th, 2009 at 11:55pm JST (5 years, 7 months ago) comment permalink

Of course I know that exiftools is not a standard part of OS but when it is installed you should use it, avoiding discrepancies and benefitting of last updates.

It’s enough trouble getting the plugin to work on every different system out there…. it’s more work than I care to take on to try to figure out whether someone has an install of exiftool elsewhere on their system, where it is, whether it’s complete and compatible with the plugin’s needs.

About Google Earth I don’t understand how you can SEND location to it and not RETRIEVE location, is Google Earth API lacking functionality ?

No, but Lightroom’s is. Lightroom has an API call to launch a program (e.g. Google Earth). It has no way to connect to a program and exchange back-and-forth communications. As I said, it might be possible to work something out, somehow, (say, using files to communicate), but it would be difficult at best and I have plenty of low-hanging fruit to address first. This month is very busy for me with family things, but I hope to get more solid development time starting in May. —Jeffrey

— comment by Alain on April 5th, 2009 at 12:22am JST (5 years, 7 months ago) comment permalink

… I don’t really understand what Alain meant…

Jeffrey’s Geotagging plugin does not *directly* interface with Google Earth but… it’s extremely easy to drop a placeholder in GE and copy/paste those data to Jeffrey’s plugin! (that’s what I have come to, but… I’m open to even easyer suggestions ;-) )

I tried HoudaGeo which directly interfaces with GoogleEarth but… it does not interface with LightRoom! =:-/
If you geotag you pictures before importing them in LightRoom… just go with that one! Otherwise… ;-)

btw… Jeffrey: do you remember my previous inquiry on GPS timestamp? well… HoudaGeo has a drop-down menu meant to select the timezone where the pictures are taken. I suppose that’s a way to solve UTC fixed timezone written by your plugin and, as you said, GPS units ;-)

— comment by paolo savonuzzi on April 5th, 2009 at 12:25am JST (5 years, 7 months ago) comment permalink

As a former software developer I disagree with you, it makes no sense to embed software available in a library and checking of availability is easy to perform at installation. But I understand you develop during your spare time, so don’t worry.

As a former software developer, you should understand when you don’t understand the environment. —Jeffrey

Paolo, could you explain in detail what you suggest, I don’t really understand what you meant…

— comment by Alain on April 5th, 2009 at 1:19am JST (5 years, 7 months ago) comment permalink

Jeffrey… If you have a Mac handy, take a look at how HoudaGeo works: first step is selecting, from a drop-down menu, a timezone that matches camera’s clock setting (and, I suppose, GPS unit). Then you geoncode your pictures.

This way GPS timestamp matches exactly Capture Time (original) embedded data ;-)

The GPS Timestamp is explicitly defined to be UTC, so it’ll match the photo dateTimeOriginal only for those in the GMT timezone. Times in tracklogs are also supposed to be in UTC, or at least have an explicit timezone, so there shouldn’t be any need to specify a timezone for the tracklog. —Jeffrey

— comment by paolo savonuzzi on April 5th, 2009 at 3:11am JST (5 years, 7 months ago) comment permalink

… so… why, in pictures geoencoded by HoudahGeo, GPS DateTime matches DateTime Capture Original whilst in those geoencoded using your great plugin is 2hours off (italy, here)?

is this a bug, or a misinterpratation, in HoudahGeo?

The Exif standard explicitly defines the GPS timestamp to be in UTC (see page 65 of the standard), so if HoudaGeo is putting something else there, it is in error. —Jeffrey

— comment by paolo savonuzzi on April 6th, 2009 at 12:17am JST (5 years, 7 months ago) comment permalink

Good stuff Jeffrey. My donation is on it’s way… one thing:
It would be nice to have a right arrow in the geoencoding metadatabox in Lightroom’s library panel like the website or copyright info. One should be able to choose the favorite mapping service in the plugin’s setting page. The arrow should then take you directly to this service and show the photo’s location. It’s quite annoying to surf through the file menue every time you want to see a location on google maps.

Keep up the good work.
Cheers
rdp

I absolutely agree on all counts, but sadly, the LR plugin infrastructure does not make that option available to plugins )-: —Jeffrey

— comment by rdp on April 8th, 2009 at 3:49pm JST (5 years, 6 months ago) comment permalink

I noticed that you had to make a hack for the WGS84->”tokyo datum” geodetic transform. A quick look shows that if you search for the term “geodetic transform library” there are a handful of results that should make the process much much easier if needed in the future. On another note, the reverse geocoding is nice, any chance to see it implemented into a writeback so that it shows in the lightroom metadata?

There’s a library put out by some Japanese government agency, but it’s Windows only, and can’t be accessed from within Lightroom even on Windows, so it wasn’t much help for me. I precalculated a bunch of differentials ahead of time, and apply the one closest to the point in question, so I’m confident that the results from the method I came up with is pretty darn accurate. I’ve considered a reverse geoencoding plugin, but have yet to find a good source of data. Every place I’ve tried has had horrible results for Japan, and spotty results for whereever else I’ve checked. —Jeffrey

— comment by Robert S. on April 9th, 2009 at 2:19pm JST (5 years, 6 months ago) comment permalink

Well I thought you already had some reverse geocoding using the google api built in. It showed up in the window when I checked out a file that I had already added gps data to. (reverse geocoding is coord to address, vs regular geocoding which is address to coord) As for datum transforms, I havent had to deal with programming them directly, but to the bset of my knowledge http://earth-info.nga.mil/GandG/geotrans/ is the reference for doing transforms.

— comment by Robert S. on April 9th, 2009 at 3:33pm JST (5 years, 6 months ago) comment permalink

Hi,
great Plug-in. Another great Option for me, would be if it would be possible to pass the location names from the Plug-in Dialog directly to the Location description in Lightroom.

Thanks Mathes

That’s definitely on the short list. I’ll not have a lot of development time in April, but I hope to have a lot in May and June…. —Jeffrey

— comment by Mathes.s on April 12th, 2009 at 12:47am JST (5 years, 6 months ago) comment permalink

… HAPPY BIRTHDAY, JEFFREY!!! :-) :-) :-)

— comment by paolo savonuzzi on April 13th, 2009 at 7:48am JST (5 years, 6 months ago) comment permalink

The plugin seems to be having issues with write-back on large TIF files — it choked on TIF files over 130MB. I get an error like this:

> Out of memory during “large” request for 134221824 bytes, total sbrk() is 275279872 bytes at C:\Program Files\Adobe\Adobe Photoshop Lightroom 2\lightroom_plugins\gps-jfriedl.lrplugin\lib/File/RandomAccess.pm line 201.

The worst part is it corrupts the file so when opening it in Photoshop I get “The document may be damanged (the file may be truncated or incomplete). Continue?”

After continuing, I find that the TIF file has indeed been corrupted — all the layers are lost as if the image is flattened (better than losing the layers altogether since these were finished images, but still sad to have lost them). Note: the corrupted file’s size is still the same, so the layer info is probably in there, but corrupt in some way such that photoshop sees it as a single layer.

FYI, this is on a vista box and is reproducible (I created a 200MB TIF file with 3 layers then tried to geoencode it with a static location using LR2.3).

Yikes, sorry about that(!) The plugin uses the exiftool library to do the writeback. Not sure what I can do here, but I’ll ask the exiftool author whether there’s a safer road I can take. —Jeffrey

I’m still not sure of the exact mechanics of how files are getting corrupted, but a quick and smart fix will be for me to have the plugin write each file to a temporary file, then rename over the original only if the first write succeeded. Besides being safer, I believe that it doesn’t try to build the whole thing in memory, so won’t fail on huge images. I’ll try to get this done tomorrow. —Jeffrey

Okay, just pushed version .58 that addresses this. It now never writes to an original file, but rather writes to a temporary file and then renames it over the original only if the temporary file could be written successfully in the first place. It also no longer tries to hold the entire image in memory at once, so it shouldn’t run out of memory anymore. I feel bad for your TIF that lost its layers, so just in case please backup images and test once before using in production. —Jeffrey

— comment by David Underhill on April 13th, 2009 at 1:27pm JST (5 years, 6 months ago) comment permalink

Hi Jeffrey

a small but nice improvement would be to add a 2nd button in the window that appears after geoencoding (Success : Images selected: x, Images processed successfully: y) to show only photos that could not be geoencoded

Yes, that’s a natural item to have, but the Lightroom plugin infrastructure offers no way for a plugin to control the selection directly. If you set the Library Filter to “GPS Shadow: No” ahead of time, though, it will automatically update as the plugin works. —Jeffrey

— comment by Florent Bouckenooghe on April 17th, 2009 at 11:51pm JST (5 years, 6 months ago) comment permalink

After updating to Version .59 I got the error “attempt to yield across metamethod/C-call boundary”. Using Lightroom 2.3 on Mac OS X. Can’t process any images :-( Where can I download old versions?

Just pushed .60 that should fix that, thanks for the report. —Jeffrey

— comment by Patrick on April 18th, 2009 at 4:17am JST (5 years, 6 months ago) comment permalink

Hi Jeffrey,

after using you Picasa Plugin extensively, I’m testing your GPS Plugin (April 25ths release).
Unfortunately I always get the message, that no datapoints were found in the tracklog.
This is independent of the file Format (i.e. using gpx, kml (–> configured as -i “ktf2″)).
Here I’ve uploaded an example tracklog:
https://www.yousendit.com/download/dVlxT216TStrWTlMWEE9PQ
I’ve also checked other tracklogs, but I can’t get it to work :-(

Do you have any hints?

Greetings, and thanks a lot!
Hendrik

The problem in the sample you provided (thanks) is that the trackpoints do not contain a date/time for the point, so there’s no way that the plugin (or anything else) can correlate the location to a photo. Garmin units strip the date/time info when you save a tracklog internally (e.g. when you apply a name to a tracklog to save it from being deleted or overwritten), so perhaps you’re running into that. The sample also had a bunch of waypoints, and those included a human-readable date in the comment field, but the waypoints do not include the requisite computer-readable <time> field, so again, there’s no way to associate a location with a photo. Check how you’re generating the tracklogs and be sure to include the date/time information, and it should work. —Jeffrey

— comment by Hendrik on May 1st, 2009 at 2:59am JST (5 years, 6 months ago) comment permalink

Great work! Looks very nice and it is pretty simple to use! I really appreciate your effort developing this great tool.

I’m running into a problem though, that is: “Write Data Back” does not actually write the existing metadata (in LR) back to files. It only saves the GPS shadow data into files. The proces starts and no error occurs. However the metadata is not written back to files, only the GPS shaddow data is written back. I can verify this by other tools (like properties windows of the picture to check the metadata and GeoSetter to verify the GPS data).

If I use internal command of LR to save metadata to the file, the meta data does get written well.

If I may assist with additional info, please let me know.

Yes, that’s how it works… the plugin write-back operation writes only the GPS info. If you’ve already “save metadata to file” (which in the case of non-DNG raw files creates an xmp file), the GPS data is added. Otherwise, the plugin itself creates an xmp file. If you don’t do the “save metadata to file” step first, then you can lose data when you “read metadata from file” after you write back the info. That’s why the plugin explicitly recommends doing the save first, as Step 1 of a four-step sequence. —Jeffrey

— comment by Kevin on May 1st, 2009 at 4:37am JST (5 years, 6 months ago) comment permalink

Hi Jeffrey, In version .49 you made the dialog box smaller so it would fit on my net books 1024×600 screen. Somewhere between then and the current version .60 The box seems to have got slightly bigger and no longer fits on the screen :(

The dialog had gotten hacked up a bit lately, as I added new functionality. Gave the layout some TLC and just pushed .67, and it again fits into 800×600. —Jeffrey

— comment by Mike on May 2nd, 2009 at 12:28am JST (5 years, 6 months ago) comment permalink

Hi Jeffrey,

thanks for your reply on my comment on May 1st.
I understand the problem. The data comes from a GPS-Logger, and I saved the data with its software to nma, csv and kml (these are the formats that are supported).
In the csv file, I found the date/time data and succeeded to convert it to gpx via gpsbabel (manually).
For some reason the plugin only succeeds to link 160 of 700 files, but I will try with geosetter whether it manages to link more.

In order to ‘debug’ this, a dialog with the Times of the Files (all) and the GPS Data that was found, like geosetter does would be very helpful. (let me know if you don’t know what I mean and I’ll provide a screenshot).

Thanks for your help!

Regards,
Hendrik

You may wish to increase the “Fuzziness” factor, to allow for photos taken between tracklog datapoints. I don’t quite understand the “Times of the Files” thing, so please do send a screenshot (via email). —Jeffrey

— comment by Hendrik on May 4th, 2009 at 4:06pm JST (5 years, 6 months ago) comment permalink

Great plug-in. I was using a combination of other programs to do what this does in one easy step.

Have you given any thought to having the program add a samm icon to the library thumbnail, such as what you get for keyword tags and develope adjusatments.

I’ve got a large libray of old pictures that I have scanned in and am adding geodata as I can determine a location for the pciture. This would make it much easire to track files that you have added geotags to.

Bob

I’m not sure what a “samm icon” is, but LR’s plugin architecture doesn’t allow much. The best I could come up with for making it easy to track what has and hasn’t been geoencoded is the “GPS Shadow” item in the Library Filter (with which you can also make a Smart Collection)… —Jeffrey

— comment by Bob on May 7th, 2009 at 7:54am JST (5 years, 5 months ago) comment permalink

Jeffrey… seems that import location from Google Earth does not work anymore with GE’s Mac version released yesterday (5.0.11733.9347) :-(

It seems to work for me, so perhaps you can send me an email with more details about what “does not work” means in this case. Thanks. —Jeffrey

— comment by paolo savonuzzi on May 9th, 2009 at 10:54pm JST (5 years, 5 months ago) comment permalink

I use this Tool with all my Photos and it works wonderful.
Is it possible to add or edit URLs like this:

http://www.openstreetmap.org/?mlat=52.51858&mlon=13.37603&zoom=15

I don’t like google.maps.

Thx
Stefan

Just pushed version .69 with it. Thanks for the suggestion. —Jeffrey

— comment by Stefan Diestelhorst on May 10th, 2009 at 1:38am JST (5 years, 5 months ago) comment permalink

Hello Jeffrey,

I’m using plugin version 20090510.69, and get the “no datapoints in the tracklog”; the tracklog in question is in GPX format, and has the time entries as far as I can see. You can check the tracklog in question at [...]

The times in that tracklog have no timezone, so the plugin didn’t know what to do with them. (GPX files are supposed to have times given in, and marked as, UTC; if not, it’s not a GPX file). However, I’ve run into enough devices that produce broken GPX files to go ahead and push a new version, .71, which assumes the photo timezone for datapoint times that have no timezones. —Jeffrey

— comment by Michael Bravo on May 10th, 2009 at 8:25am JST (5 years, 5 months ago) comment permalink

Hi Jeffery, thanks for the excellent work as always.

I notice that in the Geocode static location dialog that you reverse geocode the coordinates and display something like “1.9 km from Pompano Beach, FL” as a text description of the location.

Whats the source for the reverse geocode?
Can you enable an option to write that data into the Location field?

I’d like a way to auto populate a City, State, Zip field in the database using “real” exif data.

I’ll cheerfully make another donation :-)

Ross

The source is Google, and it’s on my list to try to do more with it. The problem is that it’s very spotty so you can’t at all rely on it without a final inspection. It’s on the to-do list. —Jeffrey

— comment by Ross Cobb on May 11th, 2009 at 8:24am JST (5 years, 5 months ago) comment permalink

I have a small problem when I use Geoencoding from Google Earth.
I have a Dutch version of Google Maps and also a Dutch version of Lightroom 2.3.
My OS is Vista Home Premium.

The problem occurs when I try to Import Location from Google Earth. After pressing the button a window with the message ?:8876 attempt to compare number with nil appears and there is not a valid location.

I found that the problem is the decimal point in English, in our language we are using a comma for the decimals and when I change the comma in a dot then there is a valid location and can I store the position.

I hope you can do something about this problem.

Thx
René

After you get the failure next time, please send a plugin log (via the “send to Jeffrey” button in the upper-right of the plugin manager) and I’ll take a look. Be sure you’re using the latest version of the plugin before you test it, though, because I thought I fixed that bug already. Thanks. —Jeffrey

— comment by René van der Krogt on May 15th, 2009 at 8:29pm JST (5 years, 5 months ago) comment permalink

Hi Jeffrey. Thanks for the ability to import locations live from Google Earth. I just noticed that you’ve listed off a known issue with Google Earth 5 not support applescripts, and more or less destroying that functionality.

I’m running Google Earth 5.0.11337.1968 (beta), build date of Jan 28, 2009 for OSX and have no issues. I’m fairly sure this isn’t the most current version (I disabled auto updates for the application a little while ago). Figured I’d make a post here saying it’s not dead for all versions of Google Earth.

That’s good to know… I guess you’re lucky to have the old one. I’ll check in the future every so often… maybe they’ll put support back. —Jeffrey

— comment by Rubin Starset on May 25th, 2009 at 2:35pm JST (5 years, 5 months ago) comment permalink

Hi Jeffrey,

I really love the reverse geo-encoding feature and think it’s a great addition to the plugin.

Yesterday I selected over 200 photos with GPS coords. After fetching the city, country from the gps for the first photo and using the “tag photos in 1km radius” feature, many of the 200 photos were tagged but I had to scroll the whole list to find the ones that weren’t tagged and work them.

It would be nice to have a button that would remove the photos that were reverse geo-encoded while leaving the rest in the queue.

Thanks for the great work!
Ahmad

That’s a good idea… I’ll add a filter or something. Nice to hear some feedback…. I thought it would be a popular addition to the plugin, but yours is the first reaction of any kind I’ve received. Sort of depressing, actually, to spend that much time on something and then get the exact same reaction as if I hadn’t done it at all. So thanks for not only giving some indication that someone, somewhere has actually seen it, but a great feature idea, too. —Jeffrey

— comment by Ahmad on May 31st, 2009 at 2:26pm JST (5 years, 5 months ago) comment permalink

Hi Jeffrey,

I just updated the plugin and noticed that you had added reverse geocoding – It was the only feature missing from the plugin, that I was using with the previous method I used to tag my pictures ( a perl script, but it was slow and did not integrate with Lightroom). Great work.

— comment by Mike on June 1st, 2009 at 12:39am JST (5 years, 5 months ago) comment permalink

Yep, this is an excellent addition to the plugin! One minor quibble with the interface though, the distance data between rows in the white font is nearly invisible on my calibrated screen. I only really noticed it when the tool-tip popped up. Neat little feature though.

— comment by JasonP on June 4th, 2009 at 7:03am JST (5 years, 5 months ago) comment permalink

Reverse geocode is perhaps the most useful plugin feature I’ve come across – thanks for this!

— comment by John on June 5th, 2009 at 5:55pm JST (5 years, 5 months ago) comment permalink

Hi Jeffrey
I love the plugins, and was really looking forward to the reverse geoencode from Google Earth. However, when trying this GetCurrentGEView.exe returns an error saying “Windows Scripting has not been initialized! Exiting application.” Is this something that needs to be initialized in Google Earth or Windows, and how? I’m running XP with all updates etc up to date.

Also the reverse geoencoding dialog has a button for bulk geoencoding but this is greyed out and there doesn’t seem to be a way to select multiple images – how does this work? As an addition to this, a select all button would be useful.

Thanks for all your hard work on this

I don’t know much about Windows stuff, so am not sure what to make of the “Windows Scripting has not been initialized” error. I’ll search around. The reverse geocodeing “bulk” button works with all the geoencoded images in the dialog (that is, it works to derive city/state/country for all images that have latitude/longitude), but it’s grayed out until at least one image in the dialog has latitude/longitude. The plugin works with the images that are selected when you invoke it. —Jeffrey

— comment by Brian on June 7th, 2009 at 2:52am JST (5 years, 4 months ago) comment permalink

The plugin works well for astrophotography! If you use Google Earth’s Explore Sky feature you can generate coords to store with a photo, and vice-versa you can use the coords in the photo to view the location in Google Earth. Neat!

Now if the plugin only had a way to convert latitude and longitude to Right Ascension and Declination…. :-)

— comment by hm on June 7th, 2009 at 4:30am JST (5 years, 4 months ago) comment permalink

Hi Jeffrey,
What metadata identifiers should I be looking at if I want to include support for your GPS latitude and longitude in a plugin?

I have a routine that once loaded, allows you to transparently get the shadow data if it’s there, and the “real” GPS data otherwise. It’s on my Lua Code page. —Jeffrey

— comment by Sean McCormack on June 7th, 2009 at 1:21pm JST (5 years, 4 months ago) comment permalink

Awesome update (.80) – I love the country code addition.
Would it be possible to allow the location field to be populated automatically with the reversed data (I understand not everyone tags to this accuracy but I suspect a number do without realising, like this:

Tagging in Picasa or now – via your awesome plugin – Lightroom by Google Earth I search for Louve, or Tate Modern rather than Paris or South Bank, London – thus the geolocal data should be spot on.

This would remove yet another layer of laborious metadata entry for me (if available from Google) – even if I could manually click ‘fill location’ or something like that. I see Throughfare data is available – is this what pulls location info? – I’m not sure it’s that accurate worldover but US/UK seems pretty spot on for me. Even selectable / draggable location data would be great- saves typing it in anyway!

I’ll see about adding something here, but I don’t hold much hope that the find-grained location data is really that good, label wise. I’ve yet to see an example where it is.

Another thought- collapsible raw reverse-google-geocode data at the bottom of the Interactive/Reversecode tab/pane – just for appearances sake :)

Finally, I don’t see any altitude info in the raw Google data (testing using a place in Hong Kong Island) so I guess this can’t be pulled, too?

In the reverse-geocode stuff? You mean you want it to use the altitude data to tell you what floor of a highrise you’re on? The regular geoencoding stuff (“import location from Google Earth”) should indeed bring the altitude over.

Maybe this is a bit too much info for some so could be in an expandable additional/geek area?

To be honest Lightroom should have this all builtin – populate localation metadata from gps – but your plugin is simply awesome for this.

I, too, think it should be built in, but it’s apparently just not on the non-geek radar, so therefore not on Adobe’s radar, I think. —Jeffrey

“It would be nice to have a button that would remove the photos that were reverse geo-encoded while leaving the rest in the queue.” I second this, too.

I absolutely adore this plugin- worth the price of Lightroom itself! I’m only an end user on Windows (Leicester, UK , where it’s currently raining again) but find all this geeky metadata stuff fascinating!

Great work, thanks for the phenomenal work.

— comment by J on June 7th, 2009 at 11:41pm JST (5 years, 4 months ago) comment permalink

Additionally, further use of PostalCodeNumber would be really useful for me in the UK although I don’t see where this would fit in LR’s location metadata schema.
I see Google Maps API’s accuracy of 9 Premise (building name, property name, shopping center, etc.) level accuracy is available for some places – perhaps (linking to my above comment re location field (Louve, Tate Modern) this could be optionally displayed depending upon users preference for detail of metadata entered. Clearly this wouldn’t work with a 1km distance for similar files (in fact 1m would be needed and perhaps too many requests) but would be useful if offered.

Thanks again!

The problem with the postal code stuff is that at least for the countries I’ve tested, it’s very vague, as if they have a point and radius and that’s it. Doing a search in Japan will likely come back with 5 to 10 postal-code records (“Accuracy=5″) with different postal codes, at most one of which can be correct. It’s still just not ready for prime time. —Jeffrey

— comment by J on June 7th, 2009 at 11:47pm JST (5 years, 4 months ago) comment permalink

Me again :)
Final comment, I promise!
Using .80 on Windows 7 RC 7100 LR 2.3 Reverse encoding I can see the Country Code data pulled from Google and populate the Country Code box (GB, HK etc) but applying it doesn’t update the image’s country code- it still appears blank in both LR and the plugin.

If I select just the country + code to be updated (and have already filled in the Country name correctly- leaving only the Code to be pulled and attached) and click encode it say’s there’s nothing to be done.

I think that sometimes LR is a bit slow to reflect the changes…. after exiting the Geoencoding dialog, just change the selection in some way, and LR should update the metadata display. Seems like a bug in LR, but easy enough to get around. —Jeffrey

— comment by J on June 7th, 2009 at 11:55pm JST (5 years, 4 months ago) comment permalink

Hi Jeffrey,
Thanks for the handy plug-in. However, I’m still struggling with with getting the camera time, Garmin time, and plug-in time working together. Part of the problem might be that there’s not yet an entry for Newfoundland (where I am for the summer) Daylight Savings Time on the UTC Offset dropdown menu. Would you be able to add one in your next update? Alternatively, is there I way I can do so in the current version? Thanks, and thanks again for the valuable plug-in.
Scott

Wow, sorry, I thought I had them all covered. What’s your offset from UTC??? —Jeffrey

— comment by Scott on June 8th, 2009 at 10:00pm JST (5 years, 4 months ago) comment permalink

Hi Jeffrey,
Thanks for the swift reply. NST and NDT follow in lockstep with EST and EDT, but 1.5 hours ahead. Since the shift from EST to EDT is from 5 to 4, the shift from NST to NDT should be 3.5 to 2.5. You’ve already got NST listed, so please just add NDT at 2.5. Thanks again.
Best,
Scott

Okay, just pushed it. —Jeffrey

— comment by Scott on June 8th, 2009 at 10:15pm JST (5 years, 4 months ago) comment permalink

Thanks Jeffrey–worked a charm.

— comment by Scott on June 8th, 2009 at 10:55pm JST (5 years, 4 months ago) comment permalink

Congratulations on the great write-up on Geoencoding in the June issue of NAPP’s “Photoshop User.” (See pages 84-86.) Be prepared for an onslaught of new users !!! :-)

Also, thanks for the enhancements in v. 80.

Ina

— comment by Ina on June 8th, 2009 at 11:16pm JST (5 years, 4 months ago) comment permalink

Re Altitude- I wasn’t looking for floor info, just being completest with data like ground altitude (Mt Fuji etc) so I can be a geek :)

I’m not sure theres a way using the LR Metadata editor plugin – might not be possible in LR – but after some fields one can click a side arrow and find all photos with the same metadata (cropped dimension I think does this) – is it possible to to this with other data like location?

— comment by J on June 10th, 2009 at 4:31am JST (5 years, 4 months ago) comment permalink

I thought LR wasjust being slow, too, but as I say ‘If I select just the country + code to be updated (and have already filled in the Country name correctly- leaving only the Code to be pulled and attached) and click encode it say’s there’s nothing to be done.’

Changing selection, saving/reading metadata etc doesn’t work for me even after removing + reinstalling the plugin. If I set the country code to a wrong one (ie AT) then try to reverse geoencode for Hong Kong (HK) the code field is populated w/ the correct HK code but still says ‘in the end there was nothing to do’ as though it’s not being told to write the code data saving the data.

— comment by J on June 11th, 2009 at 2:25am JST (5 years, 4 months ago) comment permalink

Works fine on my Mac with Google Earth 5.0.11733.9347
A typing error : “When Goole Earth is running”
Is there a way to disable logging ? Each time I use Lightroom I have various items in my trash.
Thanks for last enhancements.

Thanks for the typo report… it’ll be fixed in the next release. Odd that it works for you… or that it doesn’t work for me and some others. Dunno why. Maybe I’ll change the prose to “may not work”. I’d like to understand why, though. The plugin doesn’t add anything to your trash. What do you see in there that you think is from the plugin? —Jeffrey

— comment by Alain on June 12th, 2009 at 12:16am JST (5 years, 4 months ago) comment permalink

The log file named “gps-log.txt” appears in Trash/Recovered files after I restart my computer the day after I used Lightroom. It Contains :
Execution/debug log for Jeffrey’s gps plugin for Lightroom, version 20090608.81
Plugin is unrestricted, and is registered to Alain …
Registered since 2009-04-04T14:12:07 (20090402.55) via .
Log started juin 11, 2009 05:04PM local
juin 12, 2009 12:04AM JST
Plugin folder: /Users/alaincollet/Library/Application Support/Adobe/Lightroom/Modules/gps-jfriedl.lrplugin
Lightroom version 2.3.0 build 539407 for Macintosh (Locale: fr).
———————————————————————————————-
And many other lines

Your computer must be clearing temporary files to the trash when it boots. The plugin creates that file in the system temporary directory, where it normally sits out of the way unless needed. I would think that the trash even further out of the way, but if it’s bothersome, have your system leave it in the temporary directory. —Jeffrey

— comment by Alain on June 12th, 2009 at 3:38pm JST (5 years, 4 months ago) comment permalink

Usually the logs are in /Library/Logs or ~/Library/Logs and don’t bother.
I’ts not very important but every morning I have to check trash before emptying it.
I don’t understand what you mean by “have your system leave it in the temporary directory”, I don’t have any control on what system does.

I don’t know your system (my Mac doesn’t do what you’ve described), but I wouldn’t be surprised if there were an option in /etc/rc to control this. —Jeffrey

— comment by Alain on June 12th, 2009 at 6:59pm JST (5 years, 4 months ago) comment permalink

Hi. Installed this on Win7 and LR 2.4 x64 and I might have found something you should trap for:

I originally got error reading “An error occurred while reading the schema for the plug-in “Geocoding Support”. The plug-in will be disabled.” I had stored the plug-in file in the Program Files directory under c:\program files\adobe\adobe photoshop lightroom 2.4\plugins. Once I moved the plugin to a directory where I did not need Administrator privileges to write, I had no problems loading. You might want to trap for that and tell the user (or alternatively, not write to the directory :-).

Yeah, my bad, sorry. I just pushed a version that checks the writability of where it’s installed, and disabled menu configuration as needed. —Jeffrey

— comment by James Beldock on June 29th, 2009 at 4:32pm JST (5 years, 4 months ago) comment permalink

Thanks for .84/Country code fix, appreciate the work you put in to this.

— comment by J on July 3rd, 2009 at 7:00pm JST (5 years, 4 months ago) comment permalink

I’ve got 2 feature requests if possible, i really would like to email some people a mini-vacation demo in google earth. So i would like to know what you think and if its possible to;

1) Include a tracklog into the metadata, this should permit the photo to carry not only the gps location but the whole tracklog of the outing.

2) whether its possible to output certain photo(s) to a kmz file that could hold the tracklog as the path, Comments, and certain adjustable quality photos with customizable metadata?

I think houdageo does something like this but i love doing everything in lightroom and your plugin has made it so much easier!

Thanks

— comment by Bryan on July 8th, 2009 at 11:27pm JST (5 years, 3 months ago) comment permalink

Hi Jeffrey,

i’m back from a trip to Zanzibar. Now i have the following problem: we had two cameras. One of them had an GPS attached for geotagging (which worked most of the time). But the photos from the second camera are not geotagged. My idea would be a feature like tagging from a tracklog but from photos in a specific time range… Would that be possible?

You might try using something to make a KML file representing all the geoencoded photos (the “View in Google Earth” feature of my plugin will do this), then see whether you can convert that to a GPX file somehow (say, with GPS Babel), then use that to geoencode the remaining photos…. —Jeffrey

— comment by Matthias Zirngibl on July 9th, 2009 at 1:01am JST (5 years, 3 months ago) comment permalink

The GPS-plugin is a great product. After the last update it works almost seamlessly. However I’ve some questions/suggestions. My standard workflow is geoencoding – interactive reverse geoencoding – write back to XMP. 1) reverse geoencoding provides city, state, etc. but not “location” (mostly street address). However the location is indicated in a green string above the location field. Why not put it in the location field. If there are some (technical) reasons not to do that, I should be able to copy manually the adress. But even that is not possible, the “green” string is not selectable. By the way, the green location string shows up in the geoencoding dialog too. Can’t you make these strings selectable with the mouse? 2) There are too many dialogs of kind “OK, I did this or that”. They all must be clicked away. A better way would be a status bar for these messages. 3) A batch option to implement a personal workflow would be nice.
Thank you for your work.

Michael, Switzerland

— comment by Michael on July 12th, 2009 at 8:49pm JST (5 years, 3 months ago) comment permalink

Hi, just downloaded your GeoEncoder, just wondering what I did wrong, I used all the default settings when doing the shadow data, however most of my images did not gets a gps location. I am just wondering before I saw your plugin I was using another geotagging program called RoboGeo and it assigned a gps location on all my pics. Maybe I did something wrong can you help?

Did you check the fuzziness factor? Depending on how you made the tracklog, it might not have datapoints very often in time. Send details by email if need be… —Jeffrey

— comment by Noel on July 14th, 2009 at 12:56pm JST (5 years, 3 months ago) comment permalink

Enhancement Request:

I now have about 30 Geocoding presets stored in your excellent plugin. I’d like to sort them by name. I thought I may be able to do this by exporting them to a text file, sorting them (using Notepad++) and then importing.

But no, it looks like you do a merge so the order of the presets was unchanged.

Could you possibly show my presets in alphabetic order in the list? Or allow the user to sort them by some other means?

I do not see a way of deleting presets I no longer use or are an error. Maybe I missed that.

Thanks a lot!

Ian

— comment by Ian Fuller on July 18th, 2009 at 12:13am JST (5 years, 3 months ago) comment permalink

Hi, I am still doing test on your wonderful program, this is the first time that I will export to flickr and I encountered the following error. When I looked at log file here is a small cut of the log file. I checked the directoy and I did not find the perl.exe program. Can you help?

Error writing metadata to see the log file

RUNNING: “”C:\Users\hongning\Documents\LightRoom Plugin\gps-20090707.85\gps-jfriedl.lrplugin\Win\perl.exe” -CioIO -I “C:\Users\hongning\Documents\LightRoom Plugin\gps-20090707.85\gps-jfriedl.lrplugin\Win” -I “C:\Users\hongning\Documents\LightRoom Plugin\gps-20090707.85\gps-jfriedl.lrplugin\lib” “C:\Users\hongning\Documents\LightRoom Plugin\gps-20090707.85\gps-jfriedl.lrplugin\inject-gps” “C:\Users\hongning\AppData\Local\Temp\LR-52″ 1> “C:\Users\hongning\AppData\Local\Temp\LR-53″ 2>&1″
Status: 1
Execute log:
————————————————–
> ‘”C:\Users\hongning\Documents\LightRoom Plugin\gps-20090707.85\gps-jfriedl.lrplugin\Win\perl.exe”‘ is not recognized as an internal or external command,
> operable program or batch file.
————————————————–

Perhaps your version got corrupted… perl.exe should be in the Win subfolder. You should upgrade to the latest version before reporting bugs anyway :-), so maybe give the latest a try. It’s possible that the upgrade process didn’t work properly, and silently failed, and if so (if you don’t see perl.exe in the Win subfolder), please do a manual install. I should have the upgrade process do a checksum of the files to make sure they got installed properly…. I’ll think about that. —Jeffrey

— comment by Noel on July 22nd, 2009 at 10:17pm JST (5 years, 3 months ago) comment permalink

Thanks for all the help, the upgrade worked. Program works great. Sure makes geoencoding a lot more convenient Thanks.

— comment by Noel on July 25th, 2009 at 10:44pm JST (5 years, 3 months ago) comment permalink

Hi Jeffrey

Can you add support for IGN map ? This is the french service mapping (Institut Géographique National) and the maps are excellent on french territories (often better than Google map). Try here http://www.geoportail.fr/changeLangue.do?lang=en&cty=UK

All documentation on the API Geoportail is available in English
https://api.ign.fr/geoportail/api/doc/index.html

Happy holidays,
Florent

PS : thanks again for all your work on your plugins

I’ll add it to the todo list…. —Jeffrey

— comment by Florent Bouckenooghe on July 31st, 2009 at 5:13pm JST (5 years, 3 months ago) comment permalink

Regarding my previous post here (31 July), I decided to play with Friedemann Schmidt’s “Geosetter”. Unfortunately it works independent of Lr, but it does work better. IE, I can set the GPS data in a raw ORF and export it within Lr and all GPS info is also exported (as seen with Geosetter). Unfortunately, your Geoencoder Lr plugin cannot see the GPS data as enbedded with Geosetter.

I’m still in a quandry with respect to both softwares … are they actually writing different GPS data, or am I misunderstanding something. Naturally, I’d prefer a plugin that Geo-tags as well catalogs and exports all my images. Is there any other info or files I can provide that will be of some help?

I’m surprised to hear that the plugin doesn’t recognize data encoded with other geoencoding software, since the plugin recognizes any geo-data that Lightroom recognizes. Due to limitations in Lightroom (silly limitations, I feel), my plugin can’t set the geo-data to the LR catalog directly, so it maintains a “shadow” set of data in an area of the catalog that LR does allow the plugin to write to. Upon export from Lightroom, my plugin can, if you enable it, inject the shadow data into the exported copies, so that the final image is properly geoencoded. For most workflows, this is perfectly fine and thus the whole “shadow” bit is reduced to the status of “behind the scenes detail”. —Jeffrey

— comment by michael shaffer on August 1st, 2009 at 9:51pm JST (5 years, 3 months ago) comment permalink

I’ve just discovered that JPGs that are a result of Lr export after geotagged with your plugin, do show GPS data as viewed with Geosetter (GS), but will not show GPS data with Lr (see previous posts). However, a similar JPG, previously not geotagged, but then geotagged after Lr export with Geoencoder (GE), will not show GPS data with GS, but will show GPS data with Lr. The problem seems to be with Lr’s Geocoding support metadata presentation after export. The other problem seems to be a difference in the way GE embeds initially, and it being imcompatible with GS (I can provide example JPG example of the latter problem).

This is all explained on the pages that describe the plugin… see viewing geodata. —Jeffrey

— comment by michael shaffer on August 1st, 2009 at 10:44pm JST (5 years, 3 months ago) comment permalink

Hi Jeffrey,

I’m having an issue with the reverse geocoding (which I didn’t even notice until I ran across it on this thread — it should definitely have it’s own tab/pane!) in which the locations being returned are so vague as to be inaccurate. Lat/Lon coordinates in Pasadena (where I am) get returned as Los Angeles. Hesperia, CA comes back as San Bernadino. I suspect this is something to do with the Google API and not you, but when I click on the Google Maps URL generated by the coordinates, it comes up with the right place names, so clearly Google knows what the right data is. Seems odd.

Your plugins are an incredible asset to Lightroom. In fact, they’re largely why I’ve decided to buy Lightroom. Without them it just wouldn’t serve my purpose of organizing the metadata on a decade’s worth of accumulated personal photos (I let @LR_Tom know), and I’ll certainly be donating more than a penny once my Lr license comes through (waiting on educational discount). I hope the donationware model works out for you!

I’ve found the Google data to be quite spotty (but infinitely better than nothing, so I appreciate it), but it’s possible it’s my fault. Send via email, if you’d be so kind, an example latitude/longitude and the values you’d expect for city/state/country. As for reverse-geoencoding having its own pane, I agree that it should be promoted more, but the UI is fairly inflexible and already there’s 10 pounds of information in a 9-pound page, so I squeeze stuff in there where I think it’ll do the least harm to the UI. It’s certainly not how UI design should progress, but one works with what they have. —Jeffrey

— comment by Zane Selvans on August 2nd, 2009 at 6:21pm JST (5 years, 3 months ago) comment permalink

Hi,
there Thanks again for your great Plugin, and also for the picasa one. but I ran into a Problem today. It seems that there is a Problem with reverse-geoencoding. I get this Error:

+2934.9: [457F7F8] line 12070: [string "return {..."]:11: ‘}’ expected (to close ‘{‘ at line 10) near ‘:’

Everything works fine, but the reverse-geoencoding. Same in the interactive encoding tab.

Thanks Mathes

Just pushed a fix, v88. Sorry for the hassles. —Jeffrey

— comment by Mathes on August 7th, 2009 at 12:29am JST (5 years, 2 months ago) comment permalink

Hi,

I have been using your plugin for a while and I just realised that metadatas are not embed in the file. I ran the “Write Back” process and all went fine for jpegs, but my RAW files weren’t updated.

Do you have any idea why it doesn’t work ?

And are you thinking of making an iPhoto like interface for geotagging ? It would be so much more convinient to have a map, advanced preset features…

Thank you for your great job

Non-DNG raw files are never written by my plugin (or Lightroom in general, except in the special case when you update the “Date Time Original” and have enabled the “update raw files” global option). The Write-Back operation for non-DNG raw files creates XMP files, as described in the dialog. About the interface, it would indeed be much better to have an embedded map, but I haven’t figured out a way to get in done in the face of the severe UI limitations of LR’s plugin infrastructure. —Jeffrey

— comment by Arkante on August 7th, 2009 at 7:27am JST (5 years, 2 months ago) comment permalink

THANK YOU for fixing the problem with reverse geocoding so quickly.

I had a backlog of pictures I wanted to reverse geocode. I selected them in Lightroom and passed them to you. I used the “Bulk Reverse Geocode” feature for 581 pictures.

At picture #215 the plugin presented a dialog box that said:

Confirm
Fetching reverse geocoding data for image #215 of 581
and two buttons “abort” and “continue”.

I replied “continue” and it finished the batch without further alerts.

My guess is that there was a glitch in the communications with Google Earth (the plugin must be throwing many requests at it) but the dialog didn’t say that.

Thought you’d like to know. It’s certainly not an urgent issue. Enjoy your vacation.

Thanks again, Ian

If you get it again, please send a plugin log (with the “Send to Jeffrey” button in the upper-right of the Plugin Manager)…. that’ll have the full response from Google, which hopefully I can code to look out for in the future… —Jeffrey

— comment by Ian Fuller on August 8th, 2009 at 11:56am JST (5 years, 2 months ago) comment permalink

Comment to 20090808.89: why don’t you provide a means to let the user pick up the information provided from Google by copy and paste? It’s true, reverse encoding d0esn’t always exact results. But in the region where I live the “location” entry is almost always correct. It’s indicated in green above the entry fields but it’s not selectable. I can also find useful information in the black box below but it’s not accessible either. Isn’t it possible to get these fields selectable and provide copy and paste? Thanks for the otherwise great plug in.
Michael

That’s a good idea… I’ll add it to the todo list, for after my current travels… —Jeffrey

— comment by Michael on August 9th, 2009 at 7:29pm JST (5 years, 2 months ago) comment permalink

For the last few version updates I’ve been unable to manage the update through the Plug-in Manager. The dialog box that says, “Downloading new plugin from Jeffrey’s server…” comes up, but nothing seems to happen (I’ve waited for more than a minute); even the cancel button doesn’t work. I’ve only been able to recover by doing a forced quit for Lightroom.

I’ve been downloading the .sit file and manually moving the file, but something’s changed for me as the manager connection used to work. Any thoughts about how to move beyond this?

I did change a while ago how the new version is downloaded, but if the cancel button doesn’t work, I’m guessing that the network request is getting stuck at the OS level. The network requests I use for the download are different from anything else the plugin does, and so maybe you’re getting bit by something with your ISP or firewall. I’ve not heard of any other problems, so can’t really speculate. Next time you get stuck, take a look at the plugin log file (referenced in the upper-right of the Plugin Manager)…. if LR is stuck, you’ll have to look manually at the file, but perhaps there will be some clues…. —Jeffrey

— comment by James Moehrke on August 10th, 2009 at 8:41am JST (5 years, 2 months ago) comment permalink

Hi,

I had the wrong time offset for my camera clock the first pass. Now it seems I can not overwrite the location attributes. It there away of overwritting the location attributes?

thanks for your great work.

You’ll have to be more specific about “location” and “overwrite” (where, with what?) but if you’re referring to the shadow gps coordinates maintained by my plugin, see the bottom-left corner of the geoencoding dialog, for the radio buttons that allows you to specify which kinds of images to apply geoencoding to. —Jeffrey

— comment by Scott on August 20th, 2009 at 9:08pm JST (5 years, 2 months ago) comment permalink

Hi Jeffrey,
Playing around with your plugins. Currently geoencoding by hand upwards of 10000 pictures…i have to buy a GPS …

I’ve run into what may be a bug …
When reverse geoencoding pictures from Bahrain, Google returns raw data that seems accurate, which includes a “locality name” that is “Manāma”, notice the unicode ā character.
The plugin unfortunately doesn’t populate the “city” field (although the “apply” button is checked). The GPS location is

When i do the same for pictures in Paris, the city field is populated…

It would seem to be an issue with non standard characters …
On a side note, in windows, i can’t copy the green data field that is parsed from the google data, so i actually have to use the “character table ” to manually input the ā character …

Thanks for your help

The data returned by Google is a big hairy mess. If you send me a plugin log (via the “Send to Jeffrey” button in the upper-right of the plugin manager) after trying to reverse-geoencode the Bahrain location, I’ll see what I can figure out. It’s on the todo list for me to expose all the various names as selectable text, so you can cut-n-paste more easily. —Jeffrey

— comment by Paul on August 21st, 2009 at 12:31am JST (5 years, 2 months ago) comment permalink

Hi,

A fantastic plugin and has helped to get me really interested in geotagging. I like being able to work within Lightroom also. I currently use an Iphone and export GPX which works great except battery life is poor. Maybe Ill purchase a dedicated logger?

Anyhow I have been able to import and update my photos successfuuly and save back to the metadata. I was wondering if it was possible to update the location info with what is picked up from Google Maps? When I put the coordinate in the ‘Geoencode from static location’ the correct location shows and I want this added to the metatdata. I hate filling in the location info!

Also what is the best way of getting coordinates from Google Maps? I am thinking about going thru many of my photos and geotagging them manually. Just want the quickest way of extracting the coordinates.

Thanks

Chris

About “location”, see the “Interactive” tab. As for Google Maps, try Google Earth instead, at least for areas with good satellite coverage. Enable the crosshair from the plugin, navigate to a location, then import the location to the plugin. This can be done from the static tab, and from the interactive tab. —Jeffrey

— comment by Chris Putnam on August 24th, 2009 at 9:41pm JST (5 years, 2 months ago) comment permalink

I’m trying this plugin and it works very nice. For me it would be useful the possibility to add an altitude offset when geotagging from a gpx tracklog. Are you planning to implement it?

Thanks and regards,

Pietro

It does use the altitude, if the gpx file has it. Not all do. —Jeffrey

— comment by Pietro on August 27th, 2009 at 5:13pm JST (5 years, 2 months ago) comment permalink

HI,

Thanks for your response. I have now worked it out and am hooked. I probably will go thru my existing catalog adding coords to the metadata. One last question is whether its possible to show multiple photo locations on Google Maps/Earth? Sometimes nice to compare instead of having to open a seperate window for each pic.

I ended up buying a GPS logger which is great:) Getting 100% success rate geotagging photos!

Chris

If you select multiple images before invoking “Show in Google Earth”, they’ll all be shown. (There’s ample room for improvement, though, since it doesn’t even show thumbnails yet.) —Jeffrey

— comment by Chris Putnam on August 29th, 2009 at 9:54pm JST (5 years, 2 months ago) comment permalink

Just a note: Google Earth 5 is working fine with GPS-Support plugin on Mac OS X 10.6 “Snow Leopard”. It wasn’t, for someone (including me) on 10.5.x “Leopard”

Oh, great to hear! I just got Snow Leopard, too…. I’ll give GE5 a try! —Jeffrey

— comment by paolo savonuzzi on August 31st, 2009 at 9:35pm JST (5 years, 2 months ago) comment permalink

When bulk reverse geotag photos in interactive mode, the button to save the modifications to the images is disabled. Why?

Thnaks for the amazing plugin!

In the interactive mode, changes take place immediately, and remain unless you revert them before leaving the dialog. —Jeffrey

— comment by LUCA on September 2nd, 2009 at 4:45am JST (5 years, 2 months ago) comment permalink

Hi,
I’m trying your plugin from yesterday and it works a charm!
Just a (hopefully simple) addition would be very helpful:
I’ve just returned from a trip in Scotland and I had the GPS (a Gisteq PhotoTracker) on all the time. It automatically stopped recording when speed was less than a certain amount and whenever I stopped for more than 5 minutes.
This way, I have lots of images taken without a corresponding GPS position (unless I put a fuzziness of 3000+ seconds) but the two nearest recorded points are just 5 meters apart!!!!
It would be nice to geotag these as well, given a distance threshold, so that if a photo has no GPS position within the fuzziness and the closest points (by time) are closer than the threshold, the position is kind of between them.
Could it be done?
Ciao,
Giulio from Italy

The situation you describe also applies to when you (for example) walk down into a subway and take a trip somewhere, take some photos, then return, getting a signal again as you emerge from the same subway station. The locations on either end of the hours-long dead spot are identical, but photos were taken kilometers away. So, it’s not something the plugin should do automatically. If you know that’s not the case, then do just set the fuzziness to 3000 seconds, at least temporarily. —Jeffrey

— comment by Giulio on September 11th, 2009 at 10:51pm JST (5 years, 1 month ago) comment permalink

Thanks for the answer, clear and to the point!
Given your example, I agree with you.
Giulio from Italy

— comment by Giulio on September 12th, 2009 at 4:54pm JST (5 years, 1 month ago) comment permalink

Hi Jeffrey,

I use your geoencoding plugin for lightroom for a while now and really love it.
I noticed something (a bug maybe) that when I get the data from google earth and it has a negative altitude (I’m from Holland we are below sea level) that after writing it back to the file and reading the metadata into lightroom, the negative sign has disappeared.
(for instance location 52.242575, 4.8168617 near my home has -2.8m altitude but after coding it into the file it shows as 2.8m in lightroom.)

Maybe something to look after.

Best regards,
Michel.

If my house was at a -2.8m elevation, I would have bigger worries than geoencoding my photos! :D

I tried it and got -3m, so it’s working for me. Make sure you’re using the latest version of the plugin, then try importing the data from Google Earth (no need to actually apply it to any images), then visit the plugin manager and send me the log, using the “Send to Jeffrey” button…. —Jeffrey

— comment by Michel de Nooij on September 21st, 2009 at 4:11am JST (5 years, 1 month ago) comment permalink

I’d be lost without this plugin so it seems unfair to bug-report such a trivial matter as this, but I guess it counts as helping so:

When using the “Geoencode from Tracklog” tab it’s tricky to type in the address of a known file due to focus being lost immediately after every keypress (while the plugin checks for the file’s existence).

Using the browse dialog works fine but as my (& I suspect other’s) tracklogs are numbered sequentially by date it’s easy (should be easy…!) to just retype the last couple of digits for the next day’s tracklog. At present this can be a bit of a chore, typing one digit and reselecting the input area before the next keystroke!

Maybe adding a short pause to ensure typing is finished is a nice & simple option?
Leaving focus at the typing sursor would be better though :)

oh, and this is Lightroom running on Windows XP btw – just realised that may throw a spaner in the works as far as testing a fix is concerned :S

Sorry for the long delay in getting to this. I’ve just pushed v103, in which this issue should be much better. —Jeffrey

— comment by Ryan Woolies on October 20th, 2009 at 4:08am JST (5 years ago) comment permalink

Hi,

I’m using your Geoencoding plugin for a few days now, and after a bit of learning to understand all the GUI, I finally find the best way to put it in my workflow, and I really love it.
But recently, adobe labs pushed LR3b out. Wanting to give it a try, I downloaded it and started playing with it. I’m especially interested in their new Import/Export modules, and how their Flickr module compete with yours ;-).
As I wanted to keep geotagging my pictures, I added Geoencoding (updated) to LR3b.
Here are a little bugs I’ve noticed.
First when it doesn’t manage to convert GPS info to IPTC metadata.
The GPS coordinates to adress still works great, but it is not parsed anymore to fill the following fields: Location, City, State, Country, ISO Code.
Second issue I’ve came across, is in Interactive mode. Previews are not displayed, even if I run a Render Standard Preview on the whole library.
Finally, more like a feature request, even if I’m not sure the Lightroom SDK allows it. A keyboard shorcut would be awesome to quickly get the Geoencode form.

Regards,
Thibaud from France

Most of what you mention has been covered, though perhaps only in English. Lightroom does not let plugins set gps data, so the best I could do is come up with the “Shadow GPS data”, which is the same information but in private plugin metadata. Look for more on the announcement page. The preview stuff doesn’t work in LR3b at all…. it’s only lucky that I could get it in LR2, but I’ll try more in LR3 and perhaps get lucky again. With some work you can set up a keyboard shortcut. —Jeffrey

— comment by Thibaud on October 27th, 2009 at 8:19pm JST (5 years ago) comment permalink

Thanks for your quick reply.
I knew about GPS Shadow data, and this not what I’m talking about.
In LR2, when using your plugin, coordinates were translated (through Google ?) to an adress, and those infos were parsed to fill IPTC fields. That worked well with nothing to do (except clicking on the ‘city,etc, from GPS’ button) But in LR3, the adress is retrieven (no change) but not parsed or actually IPTC fields are not set. There is the issue.

Oh, sorry, I see. I just pushed a fix. Thanks for the heads up. —Jeffrey

— comment by Thibaud on October 27th, 2009 at 8:57pm JST (5 years ago) comment permalink

Thank you very much.
One more bug or request as I don’t remember how it was working in LR2.

In the Geoencode static Location Pane, I can quickly set coordinates for multiple files, and the location adress is retrieven automaticly, but IPTC fields are not set. I must then go to the Interactive Pane, and press the bulk reverse button. Is it possible to have the IPTC fields set as soon as the location adress is reversed from the coordinates I type? That would be awesome and really time savy.

Regards,

— comment by Thibaud on October 28th, 2009 at 1:26am JST (5 years ago) comment permalink

Hi. Jeffrey:
I just downloaded version .97. I get a error upon opening the applet:

“An undefined error has occurred. Access to undefined global: a”

3 of the same error messages occurr upon opening applet. I was able to static geocode but the errors reappeared when I went to the Interactive Tab and no reverve geocoding of city, state etc was done.

I was unable to access the log to send it to you.

Ina

Sorry about that… it’s fixed in .98, which I just pushed —Jeffrey

— comment by ina on November 2nd, 2009 at 8:54pm JST (5 years ago) comment permalink

I have started to see a consistent set of errors in version 20091102.97 of your most excellent plug-in.

When I start it up to geocode some pictures I get a dialog box that says: “An internal error has occurred: access to undefined global: a”. If I click OK the plugin proceeds and I can geocode pictures in Interactive mode.

However, related errors pop up for every picture when I try to reverse geocode. They relate to this undefined global “a” and reverse geocoding no longer works.

I can send you screen shots or logs if you need more information.

Thank you very much for all your efforts on this and all your other Plugins. They are actually the main reason I use Lightroom in preference to other workflow tools.

Sorry about that… just pushed .98 which fixes it. I can’t figure out how that one got past me. —Jeffrey

— comment by BKKPhotographer on November 3rd, 2009 at 4:59pm JST (5 years ago) comment permalink

I just downloaded .98.

Now I get an error dialog box: “?:12446: attempt to index a nil value” whenever I do any reverse geocoding in the ‘Interactive’ dialog box. This happens if I press the ‘city etc from GPS’ button or try to reverse geocode a batch of pictures together.

This is with LR 2.4 on Windows XP and it is for locations in Bangkok if that helps.

I hope it isn’t a difficult fix. I can provide screen shots and / or a log if needed.

Hmmm. Yes, please send a log… that’ll help. Thanks. —Jeffrey

— comment by BKKPhotographer on November 4th, 2009 at 11:44am JST (5 years ago) comment permalink

Version 99 fixed the problem. That’s great – thank you.

I looked at your log file and am amazed that for the test photo I used Google gives 8 choices for the location given a lat/long pair. Some are in Thai and English, others are all English. This is possibly a complex case because I was near a major intersection.

I wonder why the plugin chooses p5 for the location?

I have the plugin go through a bunch of heuristics about which to choose – it’s fairly complex due to the mixed-up nature of the data and the stuff the data describes (various cultural and political human conventions on location description) – but in many cases what it amounts to is taking the first one whose “accuracy” element is 4 or lower. In spot testing all over the world, I’ve often found this to give the best for the concept of “city” and above. —Jeffrey

I discuss the difficulties of reverse geocoding Bangkok addresses a bit at http://bkkphotographer.wordpress.com/2009/11/06/reverse-geoencoding/.

I think a general solution exists that will make everyone happy because the data you are working with isn’t consistent. I’m happy if I get a consistent result over time. That means I can search Lightroom for, say, photos taken in kawaeng “Khlong Tan Nuea” and know I have them all.

Thanks again, Ian

— comment by BKKPhotographer on November 6th, 2009 at 7:47pm JST (5 years ago) comment permalink

Wow! 100 updates. Thanks so much Jeffrey, for your talent and perseverance in making this the best geocoding app ever!!

— comment by ina on November 9th, 2009 at 2:46am JST (4 years, 11 months ago) comment permalink

Hello, Sweden calling ;).
I was plying around with your plugin in LR 3, ok i know it’s a beta but when i try to import the location from Google earth with the geo plugin, and when i checked if it worked, it has missplaced the spot.
works in LR 2.4.
//Stefan

— comment by Stefan Zander on November 10th, 2009 at 5:18am JST (4 years, 11 months ago) comment permalink

Hi and congrats on the plugin. I was wondering if your plugin works on Mac OS X?

Thanks,
Juan Dent

Yes. —Jeffrey

— comment by Juan Dent on December 2nd, 2009 at 3:59am JST (4 years, 11 months ago) comment permalink

Hello Jeffrey,

New registered user from Western Iowa here and I very much like how this plug-in works. :) Mostly I’ll be using static locations and I have quite a few of them entered so far. Is there a way I can back those static coordinates up so when I get a new computer next year I can transfer them over to it? Thanks for a great plug-in!

John

You can save and restore via the save/load buttons in the middle-right of the “Static” pane. —Jeffrey

— comment by John on December 5th, 2009 at 1:48am JST (4 years, 11 months ago) comment permalink

Duh, they were right there in front of me!

Thanks Jeffrey!

— comment by John on December 6th, 2009 at 3:12am JST (4 years, 11 months ago) comment permalink

I have a Columbus V-900 and am trying to use your plugin with gpsbabel but there doesn’t seem to be a set format for the files that the V-900 creates. I can create a custom .style file for gpsbabel but how do I reference the location of the file in the plugin? Something along the lines of csv -i “location of v900.style”.

I don’t have any experience with these style things, but from a glance at the GPSBabel manual it looks as if you need -i style=v900.style. —Jeffrey

— comment by Vic on December 12th, 2009 at 5:18am JST (4 years, 10 months ago) comment permalink

Your geoencoding program has been great to use, and I haven’t had any problems with it. I just have problems with me, like putting my handheld GPS on top of the car while I set up my tripod, then quickly forgetting it was there. About 40 minutes later, after taking pictures of what I think was a juvenile bald eagle, and lots of landscapes, I realized the GPS wasn’t with me. Thankfully, after backtracking several miles and searching everywhere along the road, I found the unit intact but scratched a little, and, most amazingly, still operational. So, anyways, I have a lot of pics from a recent shoot that are off several miles. I took some extra shots on the way out of the different locations I’d already shot, but that was just so that I would have accurate GPS coordinates I could put in after geoencoding.

So, my question for you is, is there a way I can edit the lat/long info that was already assigned to the pictures through your program, and replace it by hand with accurate data?

Mark

Sure, just be sure that the selection in the lower left of the geoencoding dialog is “all”. The “Interactive” tab, with Google Earth running alongside, is useful for hand encoding like this. —Jeffrey

— comment by Mark on December 14th, 2009 at 3:03am JST (4 years, 10 months ago) comment permalink

Jeffrey, I geoencoded a photo from a “static position”. When I try to write data back according to recommended sequence, “Save” and “Read” options in LR2 are greyed. Why is that?.
I don´t see real gps data in exif info on the right pane. I usually do. What I’m missing or doing wrong now?

I hate to bring up the obvious, but are you sure that you actually have images selected? —Jeffrey

— comment by Marcelo on December 23rd, 2009 at 10:20am JST (4 years, 10 months ago) comment permalink

Jeffrey, I think I found it. I´m selecting a virtual copy. It works on the “original” one. So, I would have to copy the gps metadata to the virtual copies, is that correct?

Hmmmm… I’m not actually sure what happens with metadata and virtual copies. I’ll take a look… —Jeffrey

— comment by Marcelo on December 23rd, 2009 at 1:03pm JST (4 years, 10 months ago) comment permalink

Thanks Jeffrey.
I “workaround” geoencoding the orginal file, making new virtual copies from the geoencoded picture, and syncing settings from the “old” virtual copies to the new ones. Finally, deleted the old virtual copies.
Is there a different way to do it?

I don’t know… I haven’t had a chance to look at it yet, sorry. —Jeffrey

— comment by Marcelo on December 23rd, 2009 at 11:15pm JST (4 years, 10 months ago) comment permalink

Oh, no it´s okay. I hope you understood me. I wasn´t trying to get an answer back ASAP. I was trying to check if there was in LR2 and/or in your GPS plugin a shortcut to the sequence I mentioned above. Just that. Thanks again.

— comment by Marcelo on December 24th, 2009 at 6:58am JST (4 years, 10 months ago) comment permalink

Hello Jeffry,

I do a lot of aerial photography. I normally use a GPS device that writes to the NIKON NEF file. Sometimes however the GPS does not come live fast enough and I do not have GPS info written to the RAW file. I now want to make it “Real” GPS info. I have downloaded the plugin and am trying to export with SHADOW GPS info injected. I never find the GPS info in the files (Photoshop > File info), nor when I reimport the RAW image. Are there instructions somewhere to do this?

Thanks a bunch!

Florian from Germany

“Inject” is what happens during export, but if you want the data to become “real” GPS inside Lightroom, you’ll need to “Write Back”. There’s a write-back tab in the geoencoding dialog with more information. —Jeffrey

— comment by Florian Schulz on December 30th, 2009 at 7:58pm JST (4 years, 10 months ago) comment permalink

Just noticed your new “configure map URLs” feature. Cool! In a future release could you please add support for Bing maps as the destination? maps.bing.com is my preferred way to view locations, particularly now that they have their new beta out.

Thanks!

Neil

Added in v104. —Jeffrey

— comment by Neil on January 1st, 2010 at 12:52pm JST (4 years, 10 months ago) comment permalink

Thanks for adding support for Bing Maps. However, I see that you can view Location as the Bing map but configure map only shows various Google or Yahoo maps. Can this dialog be extended to also include Bing maps as an option?

Ina

Sorry, forgot about that. Added in v105. —Jeffrey

— comment by ina on January 1st, 2010 at 11:35pm JST (4 years, 10 months ago) comment permalink

Just gave the new Bing Maps URL a try, works nicely. Down the road it would be cool if there were a way to specify my own URL with the lat and long inserted as placeholders. For example, I’d prefer the Bing URL to point to the current beta version of the site rather than the production version. Might save you the trouble down the road of having to support each variation of every map site out there.

Thanks again!

— comment by Neil on January 3rd, 2010 at 1:19pm JST (4 years, 10 months ago) comment permalink

Just one little thing: the dates of the xmp sidecar files don’t change when updated with the gps data, so my backup software skips then completely. Is there a way of forcing the date to be updated?

I could update the plugin to update the dates, but you would be better served to get better backup software(!) —Jeffrey

— comment by Sergio on January 3rd, 2010 at 11:38pm JST (4 years, 10 months ago) comment permalink

It would be great if the plugin updated the xmp file dates (I quite like my backup software!).
In fact the gps plugin updates the file’s creation date instead of the modification date.
Many thanks for such a useful plugin.

Just pushed version v107 that now supports the ability to have the file modification date updated with each change. —Jeffrey

— comment by Sergio on January 5th, 2010 at 2:29am JST (4 years, 10 months ago) comment permalink

Hi Jeffrey,
I like your plugin and it works great with my raws.
But when I export them into jpegs I cannot longer see the GPS shadow in lightroom.
The gps-log is – as I understad it – o.k. and I can see the GPD data in bridge but not in lightroom, what can I do?

Thanks for help from germany
Beate

Make sure to add (and enable) the “GPS Shadow Injector” in the Export Dialog… it’s exactly what you’re missing. —Jeffrey

— comment by Beate on January 8th, 2010 at 8:37pm JST (4 years, 9 months ago) comment permalink

Hi,
One question: can the EXIF of a photo be altered via Lightroom or otherwise?

Thanks,
Juan

Generally, Lightroom does not update the Exif set of metadata (one exception is the DateTimeOriginal field). However, my plugin does update the Exif fields by calling out to exiftool, which the plugin includes. —Jeffrey

— comment by Juan Dent on January 10th, 2010 at 2:22am JST (4 years, 9 months ago) comment permalink

Great plugin!
Would it be possible to let the user edit (in a config file?) what version of Google Maps and Earth he is using? In the current version I miss e.g. the swedish versions.
Thank you
Bertil

You can already configure Google Maps via the “configure map url” link in the Geoencoding dialog, though there was apparently no Swedish version of G! Maps when I did that. I’ll look into adding it. As for Google Earth, just pushed a new version that allows you to configure that in the plugin manager. —Jeffrey

— comment by Bertil on January 21st, 2010 at 2:17am JST (4 years, 9 months ago) comment permalink

I just tried to update the plugin and after the update finished the plugin is disabled and the following errors were created. Any idea of how to correct this issue? Version is 20100123.107, Lightroom 2.5

Plug-in error log for plug-in at: Y:\DATA_MY DOCUMENTS\JIM\LightroomPlugins\gps-jfriedl.lrplugin

**** Error 1

An error occurred while attempting to run one of the plug-in’s scripts.
?:5115: attempt to index upvalue ‘?’ (a boolean value)

I’m hard pressed to understand how this error is happening, but it’s related to some debugging code I put in the other day, so I’ve reverted it. —Jeffrey

— comment by Jim on January 24th, 2010 at 7:20am JST (4 years, 9 months ago) comment permalink

Hi Jeff,
Thanks for this awesome plug-in. I was wondering if you were planning to add support for loading multiple gpx tracklogs into future versions. I think this would streamline the process. Instead of having to repeat the geocoding process for every day’s shoot, a person could simply select all their photos from multiple days, load all their tracklogs into the plug-in simultaneously, and process them in one step.

Brad

The tracklog-input box can accept multiple files, and you can select multiple files in the browse dialog. That’s why the label is “tracklog(s);-) —Jeffrey

— comment by Brad S. on January 26th, 2010 at 7:48pm JST (4 years, 9 months ago) comment permalink

Hi Jeff,
A friend just showed me you Geo app. I love it. I just installed it on my Windows 7 machine and tried to run it but got the following error:

GetCurrentGEView.exe
“Windows Scripting has not been initialized”

I see someone comment on the same issue on June 7th, 2009. have you found a resolution to this issue?

I tried it on a clean-install Windows7 box, and it worked fine. Perhaps you disabled something? You’ll have to dig around, sorry. —Jeffrey

— comment by Rubs on February 2nd, 2010 at 6:04pm JST (4 years, 9 months ago) comment permalink

I’m down here in Australia. I ‘ve been using you excellent plugin for some time to geocode from Google Earth to LR. I thought I’d streamline my workflow by getting geo data logger. I got a GiSTEQ PhotoTrackr CD110BT. Unfortunately its logfiles are in .GPS format. GPSBable doesn’t appear to support this either. I’m hoping you might consider providing for this in a future upgrade. Luckily PhotoTrackr allows exporting in .GPX but that is an extra step I’d rather not have to take every time.

— comment by Bob on February 5th, 2010 at 2:08pm JST (4 years, 9 months ago) comment permalink

Further to my comments above regarding the GiSTEQ PhotoTrackr .GPS format, it seems that GPSBable does indeed support it but indirectly. One selects NMEA and then ticks the GiSTEQ option. Now what I need to know to what do I change the GPSBable argument -i”gpx” in you plugin to reflect this?

I’d think that -i "nmea,gisteq" would do it. If it doesn’t, please email a test tracklog. —Jeffrey

— comment by Bob on February 5th, 2010 at 8:26pm JST (4 years, 9 months ago) comment permalink

Good God! I didn’t give that any chance of working but it worked perfectly. You’re a bloody genius! I had an issue with the date and daylight saving adjustment but fixed it.

— comment by Bob on February 6th, 2010 at 6:17pm JST (4 years, 9 months ago) comment permalink

Great Plugin! Works perfectly together with my amod 3080. Great way to geotag raws (DNG’s in my case)

Tested it for a while a decided to donate…. just a normal amount and not the 0,01 eurocent.
Like everyone just compesate this guys’ work!! Great stuff… keep supporting it! THANKS!

— comment by Marco on February 6th, 2010 at 6:24pm JST (4 years, 9 months ago) comment permalink

Hi I recently downloaded the GPS plug-in, however, my McAfee is telling me that one of the .exe (getcurrentgeview.exe) is infected with the Artemis trojan. Does anyone else have the same problem? Obviously this is for Lightroom 2.5 on a PC.

It’s a mistake on their part… there are no viruses in my stuff. Send it to them and ask them to clarify. —Jeffrey

— comment by John on February 6th, 2010 at 6:31pm JST (4 years, 9 months ago) comment permalink

Hi Jeff,

Would it be possible to include a toggle with which we may tell the plugin to use the street address (as reverse-coded from Google) for the “Location” field?

I’m not sure that’s the intended info for that field, but it may be useful when shooting in the city.

The street address is often wildly incorrect, so I didn’t want to put it in there automatically, but I display what they return in such a way that you can select and copy the part that makes sense, and I provide the empty box to paste it in. I think it’ll be more useful than to shove it in there and then leave it for you to try to edit where you might not even be able to see it all without scrolling…. —Jeffrey

— comment by Marco on February 11th, 2010 at 9:16am JST (4 years, 8 months ago) comment permalink

I beg to differ: in my experience, block numbers may be very wrong, and are never precise (it’s always a range); street names are often correct, and I don’t even live in the US (where databases are most certainly the freshest.)

IMHO, most of the times one’s interested in finding “photos of 5th Avenue in New York City,” rather than a precise block number. In those instances, having the street name in the Location field may help a lot. Granted, one could use your (fantastic) Proximity Search, but it’s faster to just type a street name. As for copy-pasting the data into the field—it’s pretty easy but a little tedious when you’re fixing 200–300 photos at a time, as I often am!

Anyway, you’re the boss, man! Thanks for your great software.

— comment by Marco on February 11th, 2010 at 7:18pm JST (4 years, 8 months ago) comment permalink

Thanks for the amazing plugin! I have a problem though: I want the gps data to be included in my NEF files so i try to Write Back and to save metadata into files but if i import the photos is aperture no gps data is found.
I can find gps data only if I export my images as jpg, dng or whatever format. What do I have to do? Thanks!

It’s pretty much taboo to modify a non-DNG raw file in place, so I have the plugin write to a sidecar file. It’s a standard, so I’d think Aperture would be able to handle it. But anyway, now that Aperture 3 has come out, with it’s supposed-to-be-super-great built-in-geoencoding support, your problem is likely moot. —Jeffrey

— comment by luca on February 12th, 2010 at 10:28pm JST (4 years, 8 months ago) comment permalink

Played with this for the first time today, and so far I love it. Can I just pick one little nit, though? There’s a typo in the plugin text next to “View location as OSGB36″ – you have “Great Brittan” rather than “Great Britain”. Minor thing, but being a pedantic Brit, I thought I should mention it.

It’s an empire that used to rule the world… least I can do is get the spelling right. Just pushed a fix. Thanks. —Jeffrey

— comment by Les on February 13th, 2010 at 4:05am JST (4 years, 8 months ago) comment permalink

Any chance of this plugin working with GPS applications that don’t constantly record a point? I use Trails on the iPhone as my recorder, and in order to avoid memory issues on long recordings, it allows you to “filter” the waypoints so that instead of recording a point blindly every second, it will only record a new point if your location changes by a filter setting. I generally keep it set to a 50yard filter.

The problem is that the resulting GPX file won’t work properly with this plugin, so i’m forced to use an external program (GeoSetter) that encode my files.

The plugin should work just fine in these cases… just make sure the “Fuzziness” (one of the options in the tracklog tab) is set large enough. The plugin will interpolate between points. —Jeffrey

— comment by John Vanderbeck on February 25th, 2010 at 7:46am JST (4 years, 8 months ago) comment permalink

Hi Jeffrey thanks for a great plugin. I used it a while back and just registered it today. I’m running the latest plugin with Mac OS X 10.6.2 and Lightroom 2.6. I do most of my tagging using the static location window and the Import from Google Earth is one of the most important functions for me. It doesn’t work for me though with Google Earth version 5.1.3533.1731 which I think is the latest. I’m getting mixed messages on this board as to whether it works or not. Please let me know if it’s not and I’ll wait hoping that Google and Apple can play together nicely in the future. Thanks.

I have the same OS and GE version, and it’s working for me. Is your GE install named normally (“Google Earth.app”)? —Jeffrey

— comment by March on March 2nd, 2010 at 1:43am JST (4 years, 8 months ago) comment permalink

Yes my GE is installed normally and is called Google Earth.app. I’ve used the feature many times before but not in a few months after upgrading GE. I work in the IT field so I’m not clueless. I’ll try to uninstall/reinstall completely and a few other things tomorrow. So the no Applescript support in the new GE should have no bearing on the issue? Thanks.

I just thought of something that might be related… I have GE4 on my system, as well as GE5. Maybe the applescript support is part of GE4? Could you try installing GE4 as well (I call it “Google Earth-4.3.app”) and then reinstall GE5, and see whether that takes care of it? It’s a long shot, but worth a try. —Jeffrey

— comment by March on March 2nd, 2010 at 12:13pm JST (4 years, 8 months ago) comment permalink

Hi Jeffrey

Writing fom Edinburgh Scotland!

Just discovered your geo-encoding prog for LR 2. It looks great.

However the first image I tried to encode gives me an error. (not sure if its a System error or a “Jeffrey” error, but …

an internal error has occurred: ?12944: invalid order function for sorting

I can’t do much with the error message without knowing exactly which version of the plugin generated it (the number in the message is important, and is version specific), but I think I remember seeing an error like this, and I think it’s fixed in the latest version (if not, it’s fixed in the version I’m working on now, which is in sort of a hacked up state at the moment, so I can’t push it out to test, so please let me know.) —Jeffrey

— comment by Colin on March 8th, 2010 at 3:21am JST (4 years, 7 months ago) comment permalink

Hi Jeffrey,

Just added the plugin (20100306.110) to Lightroom 2.5. When using Google Earth 5 it fails to pick up the co-ords at all. Any ideas why this is happening?

It just doesn’t seem to work for some people, and I’ve never figured out why. One idea I’ve not yet confirmed or refuted is that there’s something in Google Earth 4 that is missing in GE5… if you try installing GE4 and then reinstalling GE5, does it work? I’d like to hear… —Jeffrey

— comment by Mark on March 8th, 2010 at 6:45pm JST (4 years, 7 months ago) comment permalink

Hi I recently downloaded the GPS plug-in, however, my McAfee is telling me that one of the .exe (getcurrentgeview.exe) is infected with the Artemis trojan. Does anyone else have the same problem? Obviously this is for Lightroom 2.5 on a PC.

There are no viruses, etc., in the plugin…. please ask McAfee to check it out and they’ll fix their stuff. —Jeffrey

— comment by travesti on March 9th, 2010 at 8:55pm JST (4 years, 7 months ago) comment permalink

fantastic plugin! Now that my photos are geocoded, how can I tell other people to view them on maps? Is there some software they need to get? Thanks!

There are many ways to inspect the location…. Picasa on your computer, upload to Flickr (but first set the account preferences to allow Flicrk to use the location… it’s off by default), or any of a bazillion other ways… just look around where you normally view your photos and you’ll likely find something. —Jeffrey

— comment by Dale on March 17th, 2010 at 4:54pm JST (4 years, 7 months ago) comment permalink

Hi,

I’m a happy user from the Netherlands already using your plugin for some months. One of the features that I like and used in the past -not that often I have to admit- is the “Between Endpoints” section. After a few months without using it and with the plugin version .115 installed I tried to applied the locations using this feature but it’s not giving a correct result. I have 21 images the first one and the last one with GPS Location. Importing from the first & Last Image or Importing from Google Earth the Start and the End, shows me the correct locations. The issue is that after pressing “Geoencode Images” all the locations from the images “in between” move near 550 meters southeast.
What I’m forgetting to do? I know that in the past I didn’t had this problem.

That sounds pretty odd… could you email me a screenshot of the entire Geoencoding dialog just before you press the “Geoencode between endpoints” button? —Jeffrey

— comment by Mario on March 18th, 2010 at 12:51am JST (4 years, 7 months ago) comment permalink

Just got a chance to try out .kmz’s with photos included on v.117. Works great now on Vista 64. Thanks for the update!

— comment by JasonP on April 3rd, 2010 at 11:40am JST (4 years, 7 months ago) comment permalink

I just used this plugin in LR3 b2 for the first time. I selected all the files in a folder and tried to apply GPS data from a tracklog, and write that data back to the original files. The write back repeatedly failed.

It wasn’t until I realized that there were video files -included in my selection, and that the plugin was crashing when it tried to write to those files. The error message wasn’t at all intuitive, and the error log wasn’t really either.

I would like to suggest that if GPS data is not going to be compatible with video files then the plugin should either skip them automatically or perhaps give a more detailed error message.

Thanks for your continued great work on LR plugins!

Oops, good point. Just pushed a new version (v121) that skips video files when writing things. You can still have them encoded within Lightroom. —Jeffrey

— comment by Sean Phillips on April 5th, 2010 at 1:34pm JST (4 years, 7 months ago) comment permalink

Hello Jeffrey,

thanks for the excellent work.

In a future release could add support for following url? (korean map)

http://local.daum.net/map/index.jsp?urlX=513278&urlY=1139109&urlLevel=3&map_type=TYPE_SKYVIEW&map_hybrid=true&SHOWMARK=true

thanks!

Just added the ability to view locations at Daum (in v118 of the plugin), but in order to support the ability to cut-n-paste via a Daum URL, I’ll need details on how to convert from the X/Y coordinates in their link urls to latitude and longitude…. if someone knows it, please send the calculations. —Jeffrey

— comment by Mincheol on April 11th, 2010 at 2:37pm JST (4 years, 6 months ago) comment permalink

Yes,
i need only ability to view location at Daum .

i really thanks your reply.

(Daum have reference doc at http://dna.daum.net/apis/maps/reference
and convert cordiante api at http://dna.daum.net/apis/maps/reference#toc-trans
but korean language. )

To allow conversion the other way, I need a way to convert from the urlX and urlY coordinates seen in their URLs, to latitude/longitude. If someone knows the calculations, please let me know (in English or Japanese, please…. sorry, don’t read Korean). —Jeffrey

— comment by Mincheol on April 12th, 2010 at 5:05am JST (4 years, 6 months ago) comment permalink

Hi Jeffrey,

I have a feature request too if you don’t mind. Currently we can delete any one preset, I would find it very useful if we had a button that let would us delete all presets (with a confirmation of course). If that’s not feasible, then could the presets be sorted automatically? I like to keep my presets in alphabetical order and right now the only way I can do that is to save the presets to file, then one at a time delete my current presets, then I’ll process the saved file to sort the presets, and finally I’ll load them again.

Thanks for a great plug-in!

I just added a feature to the latest version (v120) that allows you to clear out the current presets when loading new presets. (It’s in the load-presets find-file dialog). It’s not an ideal solution, but should allow you to get it done. —Jeffrey

— comment by John on April 12th, 2010 at 9:38am JST (4 years, 6 months ago) comment permalink

Hello,

When I try to view locations in google earth, all I see is red crosses in the places of photos. They seem to be correctlly geotagged but I can’t see them.

Thanks

PB

You didn’t give much info (“red crosses”?) and no email, so the best I can suggest is to send a note (via email) with more details, such as the version of the plugin you’re using (should be the most recent), and the KMZ file in question. —Jeffrey

— comment by Paulo Baptista on April 13th, 2010 at 3:13am JST (4 years, 6 months ago) comment permalink

Hi,

I just wanted to know if lightroom 3 improves the plugins structure so you can add new features as a visual map. If not, have you tried to contact adobe to propose this improvements ?

Thanks :)

Map won’t happen for Lr3, unfortunately. Yes, I’ve talked to them about it, but they see geoencoding as a fringe thing, so it’s not high on their priority list. )-: —Jeffrey

— comment by arkante on April 21st, 2010 at 8:51pm JST (4 years, 6 months ago) comment permalink

Hi Jeffrey,

I’m not sure if I’m the only one who’s encountered this recent error, but in the past couple days, when I try to geoencode my photos, I get an error message: “An internal error has occured: ?:12144: attempt to compare number with nil”.

I’m using Windows Vista Home, Lightroom 2.7, the latest geoencoding plugin (v 20100420.121).

I hadn’t had any problems geoencoding in the past up until a few days ago. The new things that have changed for me are (1) upgrade from Lightroom 2.6 to 2.7, and (2) upgrading your geoencoding plug-in. Lightroom 2.6 is still on my computer, so I tried geoencoding with v2.6, but I still get the same error message.

I can import location from Google Earth without problems. But when I press the “Geoencode Image” button, that’s when I get the error.

Just wondering if I’m the only one encountering this problem. Thanks again for all your hard work, Jeffrey.

Sorry about that… just pushed a fix (I hope). —Jeffrey

— comment by charlie on April 23rd, 2010 at 5:27am JST (4 years, 6 months ago) comment permalink

Jeff,

Writing from Norcross, GA, right outside Atlanta.

I just upgraded to LR 2.7 and am trying to reinstall the latest version of the geocode plug-in on Win7. I dropped the gps-jfriedl.lrplugin directory in the zip file into the Adobe Photoshop Lightroom 2.7 directory and installed the plugin using the plugin manager in LR. When I try to tag the images using a track log I get the error message “An internal error has occurred: ?:12144: attempt to compare number with nil”.

Part of the problem is that I might not have the plugin installed in the right place for Win7. The directions for Vista and XP don’t seem quite right for Win7. While this worked with LR 2.5, I was never comfortable that I had it installed correctly.

Thanks for the help.

Bob

Just pushed a fix for the error. As for where to install the plugins, pretty much any place you like, so long as Lr has permission write to the files in that location. Personally, I keep a folder “plugins” in my home folder, but you can put them wherever you like. —Jeffrey

— comment by Bob Chadwick on April 23rd, 2010 at 10:26am JST (4 years, 6 months ago) comment permalink

… as usual: individual mileages may vary, but today’s release of GoogleEarth Mac (Intel) v. 5.1.3534.411 broke “Import from Google Earth” function :-/

Back to GE v. 5.1.3533.1731 and all is fine :-)

— comment by paolo savonuzzi on April 24th, 2010 at 2:16pm JST (4 years, 6 months ago) comment permalink

Just trying your excellent plugin with LR3 beta 2 and have a small problem when viewing in Google Earth. If I select one image from the current library view, all images are shown in Google Earth. If I select two or more images, only the selected images are shown in GE.

That’s actually a feature, but one that makes sense only if you don’t think about it. (Really.) That’s how many Lr operations work… if you have just one image selected, it’s often because it’s just what happens to be there, so people were confused that their operation (e.g. export) didn’t work with all the images. If you’ve specifically selected just one image, well, then that’s what you want, but Lr doesn’t know your intentions, so it has to pick something that seems to work most often. —Jeffrey

— comment by Mike Carter on April 26th, 2010 at 7:13pm JST (4 years, 6 months ago) comment permalink

Thanks for the quick reply. This is obviously a good plce to learn about Lightroom :-)

— comment by Mike Carter on April 26th, 2010 at 8:03pm JST (4 years, 6 months ago) comment permalink

Fantastic work Jeffrey. I was wondering if there might possibly be any plans in the future to read directly from garmin handheld GPS units, without going through a 2nd program.

Thanks a ton!

Well, if you have a unit with a memory card, you can mount it on your system, and the plugin should be able to access the GPX file directly. But otherwise, no, talking directly to a GPS unit is way beyond the can of worms this plugin wants to open. —Jeffrey

— comment by Mike Thompson on April 26th, 2010 at 9:51pm JST (4 years, 6 months ago) comment permalink

I tried this rather good plugin but hit a problem. My setup is a little ususual: LR runs in Windows XP on a VM (Virtualbox) hosted on a Linux machine; all images are stored on a native ext3 disk accessible to LR as a network drive. So good so far, no issues whatsoever until I tried your plugin.

I geotagged a batch of raw files and used the option to write back the shadow GPS data to the (xmp) files. The plugin believed this was done, LR didn’t see the change. On investigation the problem became obvious: LR writes “xxx.xmp” files, your plugin used “xxx.XMP” and although this matters not to Windows itself it certainly does to the underlying native filesystem, resulting in two variants of each xmp with differing contents one of which was read by LR and the other by the plugin.

I’ve temporarily “fixed” the problem by moving the image files to a case-insensitive FAT32 filesystem while I continue testing but I’d rather not leave it that way for all sorts of reasons…

The plugins looks for a pre-existing file with “XMP” and “xmp” extensions and uses it if found. I’m wondering whether Windows is getting confused by the case sensitivity of the file system in some cases. —Jeffrey

— comment by John Bean on April 29th, 2010 at 5:52pm JST (4 years, 6 months ago) comment permalink

hi Jeffrey,
I have just a question, understanding that probably is an issue with some modification of Google Maps or Google Earth… Sice some time ago when locating the address (either to show up in the geoencode page or in the interactive page) instead of the name and number of the street where you are located appears the name and address of some relevant spot in the surroundings (i.e. a name of an hotel that it is two streets apart).
Is this something related to the configuration or the tols or just what is returning now google when questioning for the spot.
The problem is that whereas some time ago I was able to do about 100% of the inverse IPCT, including the street and number, now I cannot do more than 5% as always there is some relevant spot that shows-up.
Regards,

It wouldn’t surprise me if this is something that Google changed that I didn’t notice. Send an example lat/lon pair (via email) along with what data you expect, and what data you’re actually seeing. —Jeffrey

— comment by Rafa on May 1st, 2010 at 3:48pm JST (4 years, 6 months ago) comment permalink

Silly me… I updated Google Earth on my Mac to the latest release and now the Import Location function no longer works. I’ve tried stepping back to version 5.1.3533.1731 with no success.

I get these messages: “Location currently indicated: nothing:” and in the lower left corner, “Valid location not yet specified”

I am unsure how to rectify this. Do you have a solution?

I don’t, sorry. I’m using that exact version on my Mac and have no troubles. If you can find GE4 and install it, then re-install GE5, it might work, but I’m not sure. —Jeffrey

— comment by James Moehrke on May 6th, 2010 at 4:35am JST (4 years, 6 months ago) comment permalink

Hi, Jeffrey!

The feature request: copy GPS data from one picture and paste to others.

Description: often (after pano stitching) I got images with almost all exif data vanished, including capture date-time, not mention GPS data. Now to geotagging those images, I do four steps: open them together in your Geoencoding with one picture from pano source, open «Interactive» and one-by-one copy gps data from valid image to empties, then write data back and then re-read metadata for changed images. A bit of boring, if you have a lots of panos.

And I dreaming about some kind of GPS-sync (together with date-time sync) — get GPS data from the first valid image and explode it to others empties, with no questions.

Is it possible?

Sure, you can do it now. Select all the images you want to sync to, and also make the image you want to sync from the “most selected”, then invoke the Geoencoding Dialog. In the Static tab, click on “import from selected photo” then invoke the geoencode and it’ll be applied to the others (or the other “empties”, depending on what you’ve selected to the left of the launch button). —Jeffrey

— comment by aKry on May 7th, 2010 at 6:21pm JST (4 years, 5 months ago) comment permalink

> Select all the images you want to sync to, and also make the image you want to sync from the “most selected”

Thanks a lot! My life time is saved by you once again :)
++ Perhaps you can add «copy exif date-time» checkbox to this dialog in future versions? :)

— comment by aKry on May 7th, 2010 at 6:59pm JST (4 years, 5 months ago) comment permalink

Quote: I don’t, sorry. I’m using that exact version on my Mac and have no troubles. If you can find GE4 and install it, then re-install GE5, it might work, but I’m not sure. —Jeffrey

I tried installing the old versions, etc. but it never worked for me. I read here that it works for others.
M

— comment by March on May 9th, 2010 at 11:30am JST (4 years, 5 months ago) comment permalink

Another feature request: Thanks to my EyeFi card, when I shoot raw+jpg, my jpgs are auto-geocoded, but *not* the raw files. Is there any way to extract geo data from .jpg sidecar files and apply it to the main image?

The JPGs have a sidecar? Never heard of that, but anyway, you can probably copy GPS stuff over with a script that invokes ExifTool. —Jeffrey

— comment by Scott Laird on May 20th, 2010 at 12:39pm JST (4 years, 5 months ago) comment permalink

Question – ‘web-gallery export’ is one of the conditions listed for shadow data being ignored. I shoot raw .NEF. Is there any reasonable work-around that you know for this, short of writing to XMP and then re-importing? I’m using The Turning Gate Highslide, which I absolutely love and was all excited to start geotagging and have my galleries tagged.

I don’t think it’s possible, sorry. I don’t know much about web-gallery stuff, but I don’t think Lr offers web galleries access to the general Lr plugin-infrastructure hooks. If it did then it’d be easy enough (assuming the web-gallery author wanted to do it), but I don’t think it does. —Jeffrey

— comment by Chris on May 21st, 2010 at 5:17am JST (4 years, 5 months ago) comment permalink

Using LR2.5 installed geo plugin. Hope this isn’t stupid question, but I think I figured it out and got it to update from google maps url, but it doesn’t insert location name in the metadata. Do I have to do that for each pic individually. Was hoping in addition to inserting gps coordinates that a location name could be updated as well, both for single and groups of selected photos. Tks for any feedback and hope this isn’t already answered in comment. I tried to go over them and didn’t see anything. Perhaps I am confused about the scope of geotagging for updating metadata. Tks again.

It’s pretty kludgy at the moment… after all photos get latitude and longitude, then visit the Interactive tab, then “Bulk Reverse Geoencode”. I really need to make a better UI, if I could only find the time. —Jeffrey

— comment by Todd on May 31st, 2010 at 3:37am JST (4 years, 5 months ago) comment permalink

Hello Jeffrey

Thank you for your excellent plug-ins. A quick question about “GPS-Support” Geoencoding Plugin for Lightroom :
I’m developing a small software using the API Geoportail (France) to the geo-location.

After obtaining coordinates (longitude and latitude) with this soft, I would like this soft to start Google Earth directly on these coordinates, so it is possible to use your plugin for Lightroom then.
Could you tell me if it is possible to run GE on precise coordinates in the command line?

Thank you.

The approach I take is to create a small, simple KLM file with one Placemark, then open that file in the Google Earth app. —Jeffrey

— comment by Yves on June 1st, 2010 at 5:56pm JST (4 years, 5 months ago) comment permalink

Hi. I’ve been a registered user of the LR geoencoding plugin for a long time and have no problems at all until today! I’ve just got back from a trip to Switzerland and have a lot of images to geoencode. My normal workflow is to geoencode from a .gpx tracklog (from a Garmin 60CSx) and then write the data to an .xmp side car and re-read the metadata into Lightroom.
Typically this is quite a quick process – and I can almost do it in my sleep I’ve been doing it for that long!
However, today the writing the shadow data seems to take an absolute age. Is there a bug in the latest version of the plugin?

I’m using 20100518.124 with LR2.7 on a Macbook Pro OS 10.6.3. Image files are a combination of Canon EOS5D mkii RAW and Panasonic Lumix LX3 RAW

Thanks,
Richard

I’ve gotten some reports about issues with the shadow writing, but have been too busy with Lr3 preparations to address them yet. Best to hold off on writing back for a while… shouldn’t be all that long now, one would think. —Jeffrey

— comment by Richard Linney on June 6th, 2010 at 8:43pm JST (4 years, 5 months ago) comment permalink

I’ve upgraded to my lightroom catalog to LR3 and installed the latest version of this plug-in. I mainly use the plug-in in “interactive mode” to geotag my images – but the thumbnails aren’t currently showing. During the beta phase there was a message in the thumbnails saying this would be resolved when LR3 was released. I’ve got a backlog of several thousand images waiting to be geotagged – can you give some indication as to how long before this will be available?

Sadly, they won’t be coming back. (In the beta, I said “not available yet” leaving the hope they’d come back, but that hope has now passed). Lightroom provides no way for a plugin to get a copy of the image to display like this, so in Lr2 I went through all kinds of hoops to figure out where Lightroom was storing its thumbnail/image cache, extract some image, and show it. I couldn’t figure out how to extract orientation information, so it was often upside down or sideways, but at least it was something. Anyway, as part of their under-the-hood speedups for Lr3, they changed how they store the previews I was appropriating, and I have not figured out how to get at them again. For the same reason, my preview-cache-extractor plugin doesn’t work in Lr3. I requested support on this, along with a bazillion other random things, and it’s one that didn’t make the cut. I have reiterated it for some later version of Lr… let’s keep our fingers crossed. —Jeffrey

— comment by Ian M Butterfield on June 10th, 2010 at 7:47pm JST (4 years, 4 months ago) comment permalink

Hi Jeffrey,
So I installed this plugin recently but I have found that when I open the window to add geolocation to pictures, the window is too big for my laptop screen and can’t be resized. Is there a way to resize the windows so I can view all the information maybe with a scrollbar on the side? Right now I can’t click on the bottom two buttons even if I move my Windows 7 toolbar.

Thanks

Robert

Yes, there’s an option for small screens in the Plugin Manager. —Jeffrey

— comment by Robert Clarke on June 13th, 2010 at 4:33pm JST (4 years, 4 months ago) comment permalink

Jeffery

Thank your for continuing with Geoencode. I have just donated for the LR3.

question

I am running on a laptop and the geoencode page on LR3 falls underneath the menu bar.
I thought this was the extra text before registering, so that was taken care of today….however issue did not go away.

Is there any chance you can make the screen adapt to the size of the computer screen or make it resizable.

For info my screen is set to 1366 x 768 (its the depth that is the problem)

Many many thanks in advance

Simon

There’s a “small dialogs for small screens” option in the plugin manager that you can turn on. Automatic resize is now possible in Lr3 (I put in a request for the ability for plugins to get info about screens specifically because this dialog was often getting unwieldy, and Adobe implemented it), but I’ve not yet had a chance to make use of it, so for now the manual option is your best bet. —Jeffrey

— comment by Simon Leppard on June 14th, 2010 at 1:47am JST (4 years, 4 months ago) comment permalink

Jeffery,

Thanks for the great plugin. I have version 20100612.127 installed in Lightroom 2.7 WIN and still have problems with reverse geoencoding. a) I get a dialog box that seems to expect text input after either bulk or individual lookups. I press enter without writing anything in the textbox and the location info is entered properly. Basically just an annoyance b) Somewhere between upgrading versions of your plugin and upgrading from lightroom 2.6 to 2.7 I lost all reverese geoencoded info except State/Province and ISO country code. I just did a fresh bulk lookup again to get that info back.

Also very sad to read your reply above re thumbnail images in interactive mod for LR3. That’s pretty much a knockout for me. With streetview and 3D view in Google Earth I have geotagged vast amounts of old photos. A very simple procedure. That’s the majority of geotagging I do. Not sure what to do after the upgrade to LR 3 in a couple of weeks. I’m not aware of any alternatives that allow interactive use of Google Earth. So, sadly I will have to geotag my remaining photos before upgrading to LR3.

The loss of the thumbnails is indeed painful, but so is the thought of doing a lot of manual geoencoding with my plugin. It’s possible, but the UI is horribly kludgy, and any number of third-party apps present a much better interface. I use the plugin with tracklogs, but added all the other stuff just to give people who were hard up for any kind of solution something that might work. I expect Picasa has an excellent interface with Google Earth… I wonder whether I could import data from that….? —Jeffrey

— comment by Steff on June 18th, 2010 at 6:53pm JST (4 years, 4 months ago) comment permalink

I too was sad to hear thumbnails wouldn’t be coming in the full LR3. I switched away from LR2 once the LR3b2 was released and got used to the shortcut keys to invoke the Geoencoding plugin. It didn’t take too long to get used to pressing Alt+F+S+G and Alt+Tab to switch between LR and GE with the left hand and keeping the mouse under the right hand. In some cases its faster in that you can select a range of photos and tag them whereas the Interactive dialog only allowed one-at-a-time clicking on the “from above or below” buttons (unless I missed that one…)

So I do miss it, but I’m coping!

— comment by JasonP on June 19th, 2010 at 4:49am JST (4 years, 4 months ago) comment permalink

Is there a keyboard shortcut to invoke Geocoding with LR3/Windows 7? (E brings up the loupe view)

ALT-F S G —Jeffrey

— comment by Peter on June 24th, 2010 at 11:08am JST (4 years, 4 months ago) comment permalink

More a LR question, than a plugin question, but here goes: Is there a way to set a filter to see images without geoencoding data?

It took me a moment to parse the semantics… at first I read it as “see images without seeing their geoencoding data”, but it makes a lot more sense as “see images that have no geoencoding data” :-) In the Metadata view of the Library Filter, you can look for “gps” to find images that do/don’t have “real” data, and “GPS Shadow” to find images that do/don’t have shadow data. You can make a smart collection that combines the two in any combination you want. —Jeffrey

— comment by Dale on June 26th, 2010 at 6:32am JST (4 years, 4 months ago) comment permalink

:) Thanks for decoding my question!

— comment by Dale on June 27th, 2010 at 2:09am JST (4 years, 4 months ago) comment permalink

Jeffrey,

I traced the problem I described above re the missing location data to a faulty meta data preset which got applied under certain circumstances. Had nothing to do with your plugin. Feel free to delete my comments above so people don’t get confused.

Thanks again for a great plugin.

— comment by Steff on July 3rd, 2010 at 1:47pm JST (4 years, 4 months ago) comment permalink

Jeffrey–
Some how in the last week Lightroom 2.7 forgot where the plugins were stored. I used the Plugin Manager to point to Documents and Settings/ … Adobe/Lightroom/Plugins and re-added them. All are now functional, but the registrations are still lost. Any pointers as to how to retrieve the registrations?

If they cannot be retrieved, I am intending to go to Lightroom 3 soon, so I will have to re-register them anyway. My main concern is what I might have done to cause the problem.

(California)

The only reason I know for the plugin manager to spontaneously forget about plugins is for the Lr preferences file to have gone at least partially corrupt. —Jeffrey

— comment by Jack Lindley on July 8th, 2010 at 3:49am JST (4 years, 3 months ago) comment permalink

Jeffrey-
Replaced the LR preferences file with a backup copy. All seems normal now. Many thanks for the help!

— comment by Jack Lindley on July 10th, 2010 at 12:36am JST (4 years, 3 months ago) comment permalink

Flickr doesn’t recognize the geoencoding when publishing with the built-in plugin. Any hope if/when this will be fixed?

It’s working for me… are you sure the plugin is geoencoded, and that your Flickr settings are set to allow geoencoded photos? They don’t by default. —Jeffrey

— comment by Harri on July 12th, 2010 at 12:23am JST (4 years, 3 months ago) comment permalink

The issue seemed to be that I didn’t write the data back to images – assumed it would be automatic by default. Now it works, and I just registered :) Thank you for the great plugin, starting to geoencode my photos!

Some ideas for LR3:
- non-verbose mode, with popups only when something went wrong with processing
- A button to invoke the plugin so I don’t have to go through menus, or context-sensitive right-click menu item
- Alternatively a way to change which photos I have selected while the plugin is on top
- Ability to add keyword(s) from the plugin to processed images (e.g. “geotagged”) to aid filtering processed images
- Hope you can get the thumbs to work in LR3 – no biggie for my workflow

You don’t need to do the writeback for exporting… for that you’d want to use the shadow injector as part of your publish/export pipe. That’ll be all that most people need… personally, I never do the writeback. All of this writeback/shadow/injector stuff is kludge to get around the basic limitation that Lightroom doesn’t support geoencoding…. I sure wish they were; I’d love to dispense with my plugin. About the button, use keyboard shortcuts… that makes it much faster. —Jeffrey

— comment by Harri on July 12th, 2010 at 9:05pm JST (4 years, 3 months ago) comment permalink

I have a SONY GPS-CS3, a small unit that tracks positions. The process is to encode a SD card with the GPS data based on time syncing. I can’t get LR to provide this information, including with the use of your GPS plug-in.
Is it possible to make the SONY GPS encoded data appear in LR?

I don’t quite understand what you’re asking, but if the unit’s data is not in GPX format, you might configure the plugin to use GPS Bable to auto-convert from whatever format it is to GPX. —Jeffrey

— comment by GPS encoding on July 23rd, 2010 at 8:36am JST (4 years, 3 months ago) comment permalink

I am looking for a way to display multiple images on Goggle Earth/Maps. Not sure if that functionality exists in the plugin, but it would be very useful if it did.
Peter

Select the geoencoded photos and File > Plugin Extras > View Photos in Google Earth —Jeffrey

— comment by Peter on July 23rd, 2010 at 9:57am JST (4 years, 3 months ago) comment permalink

I’ll try to me more clear: the SONY GPS unit saves a track in a format unknown to me, and likely irrelevant.
My understanding of how the unit is designed to work is as follows: the memory card is removed from the camera and placed in the GPS unit, and the ‘match’ button on the GPS unit is pressed. Each photograph has it’s coordinates encoded on the memory card according to the time of the photograph, as metadata. However, when I put the card into my Windows computer, running Lightroom, there are no GPS fields (and no GPS data).
I am using a Leica M9, and using the dng format.
Any insights as to what is wrong or how your plug-in might help will be welcome.
Thanks,
Bob

Ah, I see. Are you sure that your camera clock is set properly? Can you compare a file on the card before and after the unit works with it, to see whether there’s any difference? (You can inspect all the many metadata fields with something like my online Exif viewer). If you see the data in there, Lightroom should notice it when the photo is imported. If you see it in there but Lightroom isn’t, email a sample DNG to me and I’ll check it out. —Jeffrey

— comment by GPS encoding on July 23rd, 2010 at 11:18am JST (4 years, 3 months ago) comment permalink

Jeffrey – writing from Friendswood, TX

I was charged to try out the GPS Support plugin, until I downloaded and unzipped it. McAfee gave me an ugly message – their event log is below. Any ideas why I’m getting this? I’m using the current registered version of McAfee.
————————————————————-
One or more items were detected on your computer.

Detection name: Artemis!50AB40889353 (Trojan), Artemis!50AB40889353 (Trojan)

File: C:\Users\BolonFamily\SoftwareBackups\AdobeLighroom\Plugins\GPS-Support=Friedl\gps-20100625.130\gsp-jfriedl.lrplugin\Win\GetCurrentGEView.exe

Process: C:\Windows\Explorer.exe

Process descriptor: Windows Explorer

They (and others) occasionally flag this file in error. No idea why it happens, but if you report it to them, they’ll investigate, realize it’s a mistake, and update their signatures. —Jeffrey

— comment by Dave Bolon on July 26th, 2010 at 1:13am JST (4 years, 3 months ago) comment permalink

Wow… you could not have been more timely with v.131. I have a week’s worth of traveling/vacation photos (and another 5 days of traveling next week) where my GPS tracker either had poor reception or was completely off track. I’ve got about 1000 photos to encode by hand… Having that keyboard shortcut to bypass the dialog saving a a few clicks per photo group is really going to add up. Thanks!

— comment by JasonP on August 4th, 2010 at 6:36am JST (4 years, 3 months ago) comment permalink

I’ll second Jason’s comment. The short cut to by-pass the menu is excellent. I’ve been trying to achieve something similar (with only limited results) using AutoHotkey to automate clicking through the menu/dialog box. BTW those folks who have/use AutoHotkey might want to remap the awkward ALT F-S-R (not Jeffrey’s fault) to something a little easier to press/remember. I’m using SHIFT-CTL-G

— comment by Ian M Butterfield on August 4th, 2010 at 8:42am JST (4 years, 3 months ago) comment permalink

In the past I’ve always had to use GPicSync, but now since integrating Lightroom and your plugin, I find that additional time/steps are saved. One aspect I did like about it was the ability to automatically add in ‘geonames’ as well (I think from the geonames.com service). I hope you might consider adding/emulating this feature. I’ve found that when I uploaded those pics to places like Picasa or Facebook, that data was automatically added in caption, which saved a lot of “where were you when you took that” comments. Not a huge deal, but a neat feature. Thank you for the work, it is quite valuable to a lot of people and definitely appreciated.

There’s a reverse-name-lookup feature in the interactive tab. The UI is not very good, sorry, but it’s there. Is that what you mean? —Jeffrey

— comment by Michael B on August 7th, 2010 at 12:18am JST (4 years, 2 months ago) comment permalink

Can anyone recommend a *small* gps track log recorder that when plugged into usb on a mac, will allow Jeffrey’s plugin to read the .gpx logs directly without using a manufacturer’s conversion software. (i.e – gps recognized as a standard USB storage device with gpx files accessible)

I can currently do this with our Garmin 60CSx but I’m looking for something much smaller. Maybe I’m wrong, but for example the gisteq units sound like they need software to export the logs as .gpx files to the hardrive before Jeffrey’s plugin can read them.

— comment by Tom G. on August 16th, 2010 at 2:13am JST (4 years, 2 months ago) comment permalink

For Tom G-

You could try an AMOD AGL3080 GPS logger. It’s small, very simple and is compatible with Macs. It logs into NMEA 0183 sentences but they are automatically converted with Jeffrey’s GPS plugin once you have GPSBabel installed.

Here’s a link to a review: http://scilib.typepad.com/techreviews/2008/01/amod-agl3080-ma.html Some issues they had about a year ago were fixed with firmware updates. And despite the review, you can select your interval (1/5/10 sec) and GPS data recorded (Full NMEA / RMC only) from the logger. The only thing you can’t switch is between static logging (no stray points, good for walking tracks) or normal (records every x-second regardless of quality of signal, good for later geoencoding).

I’ve been quite happy with mine for over a year now. For what it does it’s very handy as long as you don’t need any frills (about the only thing I REALLY would like is a display for current position/speed). It records a track at the interval you specify and that’s about it.

— comment by JasonP on August 16th, 2010 at 4:47am JST (4 years, 2 months ago) comment permalink

Can you please add Geoportail to the output of you wonderful plugin ?
The URL to build is quite easy, like Google Maps :
http://www.geoportail.fr/aide.do?typeSommaire=5741261&idDoc=5780669

Sure, just added it to v.133 —Jeffrey

— comment by Alain on August 19th, 2010 at 5:04am JST (4 years, 2 months ago) comment permalink

After geolocating and writing the data back to the photos, lightroom 3 (after a little while) tells me that the metadata has been changed by an external program (which is probably technically correct). it didn’t used to do this (at least back in LR2), i don’t think. a quick “synchronise folder” usually does the trick though (without having to manually click the “up” arrow on each photo and telling it to either overwrite or read the metadata from the file…which doesn’t make a difference from what i can tell, as it’s correct in both cases).

— comment by Patrick H. Lauke on August 21st, 2010 at 10:15am JST (4 years, 2 months ago) comment permalink

I just wanted to pass on my thanks for producing this plugin. GeoTagging is something I’d been interested in doing for ages, but only recently found myself with the equipment to do the job. I recently acquired an Android phone with GPS built in and I started using your plugin to tag my photos with the GPS data generated by the phone. This has proved most successful. I’ve documented my experiences on my blog at the following address. My process involves another great piece of donation-ware for the Android phone, GPSTracker Lite by Gábor Telek.

http://squonky.wordpress.com/2010/08/01/geotagging-with-an-andoid-phone-and-adobe-lightroom/

Donation very happily made for your great plugin.

— comment by Chris Tweed on September 13th, 2010 at 6:30am JST (4 years, 1 month ago) comment permalink

Hello, I have been using using your GPS Encoding plugin for some time. A question. Is it possible for me to let Lightroom show the location on a local map, as http://kart.gulesider.no/ since this is locally (where I live) better than the Google map? Dan Aa.

I couldn’t figure out how to show a map there given a latitude and longitude. If you can show me the URL pattern to use, I’ll try to add it. —Jeffrey

— comment by Dan Aa. on September 22nd, 2010 at 6:10pm JST (4 years ago) comment permalink

OMG. I’ve read about this plugin before but didn’t like the idea of shadow data. Now I finally tried it out and it’s just incredibly powerful, what a great piece of SW. The ability to write back makes my day. Maybe you should explain that somewhere further up in your description.

— comment by Simone on September 24th, 2010 at 11:52pm JST (4 years ago) comment permalink

Hi Jeff,

First of all I would like to thank you for all these wonderful plugins. They have really made my LR experience so much better.

Now for my question, i tried using GPS-Support Plugin along with the Shadow GPS Injector and they work fine in the RAW and JPEG files. I verified this by checking the map from LR and by looking at the Properties in JPEG. My problem is that when I try to upload to SmugMug, it does not seem to read the GPS data. When I try the ‘Map This’ link from my homepage, the sample pictures that I uploaded do not show.

Then I went back to this page and read the following:

Is this the reason why?

Thanks,
bongestrella from PA

The quote didn’t come through, but you can test whether the problem is with the export or at SmugMug by setting the local export location to a specific folder (rather than “temporary folder”), then inspecting the files left behind to see whether they include geo-coordinates. —Jeffrey

— comment by bongestrella on November 1st, 2010 at 11:23pm JST (4 years ago) comment permalink

Hi, thanks and regarding your reply above. I have now raised your question to the team behind another map service for Norway, which is better and more accurate. They provided me with the following link.

http://kilden.skogoglandskap.no/map/kilden/index.jsp?zoom=5&lon=10.792&lat=59.66533&src=4326

You may need to refresh the page before the map shows up.

The variable zoom can be set to different levels, my suggestion is 5, but you may suggest another. The last element in the link is due to a needed conversion in the mapping procedure as I understood.

Looking forward to hear your comments.

Best regards
Dan.

I just pushed out a new version with support for this mapping service. Thanks for the info. —Jeffrey

— comment by Dan Aa on November 6th, 2010 at 4:48am JST (4 years ago) comment permalink

Hi Jeffrey,

I just downloaded the latest geocoding plugin for LR3 and have the following misunderstanding/problem. After tagging I find an additional frame in the EXIF data of the Metadata called “jf Geocoding Support” . This frame consistis some tage like “Location, Map, Altitude, …, GPS Shadow = Yes). Thats fine so far. If I’m going to import the pictures in iPhoto the geodata is not available. What I’m doing wrong?

Regards
Wolfgang

See the plugin page about “shadow data”, and “write back”. Lightroom doesn’t make any of this easy, so the plugin (and you) have to jump through some extensive hoops to get things done. —Jeffrey

— comment by Wolfgang on November 6th, 2010 at 9:54pm JST (4 years ago) comment permalink

I believe it’s a plugin or preset glitch: once GPS shadow data has been written back to file… the “All Plug-In Metadata” preset only reports “GPS Shadow: No” and every other field (Location, Altitude etc.) is empty :-(

You apparently enabled the “flush shadow data upon writeback” option; don’t do that if you don’t want that. —Jeffrey

— comment by paolo savonuzzi on November 7th, 2010 at 8:23pm JST (3 years, 11 months ago) comment permalink

Hi, Jeffrey, I use the Dawntech Logger with a Nikon D 700 and Lightroom 3.2. GPS data are written into the NEF file. Importing the NEFs into Lightroom the files are converted into DNG and renamed with GPS data. The new name shows the geographical coordinates + the name of the city. In EXIF & IPTC the names of the country, the province, the city are shown, not the location. Some pictures show shadow data “yes” others “no” Maybe a result of learning by trial and error? In the window of your plug in the exact adress/name of the street is shown, greyish.
Is there any way to write this information by default (?) into the file name (geographical data in the file name don’t make much sense to me) or into ” location” in the IPTC?
Which other postive effects can I get using your plug in my workflow?
Regards from Vienna,
Gottfried

I can’t comment on what might be adding geodata to your images outside my plugin, but if they’re already geoencoded and you simply want to update the cit/province/country with data from Google (which is often fairly good), you can bring up the “interactive tab” and do a bulk-reverse-geocode of the images…. —Jeffrey

— comment by Gottfried de Frantz on November 12th, 2010 at 3:04am JST (3 years, 11 months ago) comment permalink

When using the interactive geoencoding dialog, it would be nice to have the time under the date.

It should be there… I’ve gotten one other report of it not showing up, but I have never been able to figure out why it doesn’t. —Jeffrey

— comment by Jesse Lehrman on November 18th, 2010 at 8:14am JST (3 years, 11 months ago) comment permalink

Hi Jeffrey,

I love your geocoding plugin – adds a sorely needed feature to Lightroom. I was wondering, though – is there any way to geocode by address? It would save a lot of time hunting down Google Maps URLs – which aren’t always accurate, either. I know the Google Maps API supports this (though I don’t know if that’s what you’re using) – I’d like to be able to, in the “Set the location of the image to…”, just type in something like “100 main street, new york, ny, USA” or “10001″ or “K1F 2J2″ (for Canada), and have it map to “roughly” that location. Is that at all possible?

Thanks!

- Glen

The Google Maps urls should be exactly accurate to what is centered in the browser, so long as you use the “link” link and not the url shown in the address bar. I don’t see by-textual-address geoencoding to be particularly popular, so for that you’ll have to go via a browser mapping service, or via the sorta-integration with Google Earth. —Jeffrey

— comment by Glen on November 27th, 2010 at 11:44pm JST (3 years, 11 months ago) comment permalink

Jeffrey: have you already tried if the plugin works with freshly released Google Earth 6?

thanks :-)

It works fine for me on OSX, but then, so did GE 4 and 5. —Jeffrey

— comment by paolo savonuzzi on November 30th, 2010 at 9:24pm JST (3 years, 11 months ago) comment permalink

Hi Jeffrey – This from Canada – I am working with Geocoding non-digital photos – large format and historical.

I just installed the GPS plug-in and am wondering why the Bearing/Image Direction tag is not enabled. This is something which is important for my project and it appears that I cannot set that in your plug-in. I can create it in other software, but it creates an extra task outside of LR3.
For test files where I had entered the bearing in another progam, it does show in your Metadata Viewer, but it sure would be handy to be able to set it when I am placing the static position in Google Earth.

Am I not seeing something here or is this simply not enabled? Thanks, Peter

Bearing, direction, and speed refer to the photographer’s movement while taking the photo (e.g. from a vehicle), and are calculated by interpolating from surrounding points in a tracklog. If you want to encode information about the subject relative to the camera, you’ll likely have to use other metadata fields (e.g. the caption, or keywords, or the like), or, if you don’t mind having the data only in Lightroom, a custom plugin of some kind. —Jeffrey

— comment by Peter Sramek on February 7th, 2011 at 5:10am JST (3 years, 8 months ago) comment permalink

Was hunting for an alternative to using Picasa to get coordinates selected in Google Earth into my photos, and found both your Geolocation plugin, AND your Picasa faces plugin with the warning about using Picasa for tagging Lightroom images. I don’t think I want Picasa installed anymore.

Your plugins seriously fill the gaps in Lightroom – already a happy SmugMug uploader customer. Keep up the outstanding work!

— comment by DunxD on February 8th, 2011 at 8:00am JST (3 years, 8 months ago) comment permalink

Hi Jeffrey,
I’m not sure if this is my set up or the plugin – using Lightroom 3 on OS X, having just migrated from XP. The geoencoding window doesn’t have a scroll bar on the right, and with my TV set to 720i resolution, the encode button is invisible.

I can change the resolution on my TV to 1080p, at which point the whole window is visible, but that’s migraine-inducingly painful. Can you add a scroll bar to the window in a future revision, or is this something that isn’t a problem? (This is my first time on a Mac in 5 years, so I’m aware that I may just be making some idiotically newbie error)
James, Hong Kong

There’s an option in the plugin manager for small screens that you can give a try, but I wonder whether you aren’t trying to run Lightroom on a screen smaller than the minimum supported setup…. —Jeffrey

— comment by James on February 14th, 2011 at 2:42pm JST (3 years, 8 months ago) comment permalink

Hi Jeffrey
I have a bunch of images already containing GPS lat/long, but not altitude. Is it possible to add a feature that can query Google Earth using the lat/long and return with the altitude, for all selected images.

Keep up to good work!

That’s actually harder than it sounds… I can tell Earth where to move to, and I can fetch the altitude at its current location, but I can’t be sure it’s actually there yet (with full data) after I tell it to move, unless I put in a “long enough” wait each time, but “long enough” depends on a lot of things like your network connectivity. It’s not insurmountable, but it doesn’t seem like it’s a feature that would benefit enough people to make it worth it. You might consider some kind of ExifTool script…. —Jeffrey

— comment by Mike on February 23rd, 2011 at 9:15am JST (3 years, 8 months ago) comment permalink

Hi

Any chance of adding http://www.opencyclemap.org/ support in the plug-in extras menu.

Its based on openstreetmap.

Sure, just pushed a new version. —Jeffrey

— comment by Mark Duncombe on March 11th, 2011 at 10:27pm JST (3 years, 7 months ago) comment permalink

Hi,

What is the maximum number of files/trackpoints that this plugin can process? I’m trying to geoencode 1 month worth of tracks (1 file per day) and I can’t do it selecting all at the same time because the track isn’t fully loaded (tested with the “view tracklog on Google Earth” button). However, if I process the files 4 or 5 at a time it works.

Regards,
Mike

There’s no explicit limit, and I’ve successfully used tracklog sets with 30,000 trackpoints, but it depends on your system and memory, I suppose. —Jeffrey

— comment by Mike on March 13th, 2011 at 11:39pm JST (3 years, 7 months ago) comment permalink

Hi Jeffrey,

Another question: Is there any way to select only pictures that have been successfully geoencoded?

Thanks,
Mike

In the Library Grid, select “Shadow GPS” —Jeffrey

— comment by Mike on March 14th, 2011 at 12:10am JST (3 years, 7 months ago) comment permalink

I am using reverse geocoding, which I think is amazing, but have one question. If I bulk reverse geocode it does not fill the “location” field. To do this I have to go through them one at a time and tick the “apply” box next to the location. Is there anyway to include the “location” field in a bulk reverse geocode?

I’ve just pushed out a new version of the plugin that now has this box’s setting be sticky, and allows you to turn on “location” during a bulk reverse geocode. I rarely get good values for the location, but if you do, you’ll now be able to use it automatically. —Jeffrey

— comment by D J Clark on April 9th, 2011 at 4:55pm JST (3 years, 6 months ago) comment permalink

Many thanks Jeffrey for responding so quickly. I had seen some of your previous comments about “location” not being must use but in my case it often has the most crucial data. Thanks again DJ

— comment by D J Clark on April 11th, 2011 at 10:22pm JST (3 years, 6 months ago) comment permalink

Hello, Many thank’s for your hard work for Lightroom jusers.
That very fine. I’ve bought your plugins and it’s perfect.

Best regardes from Switzerland :-))

Christophe

— comment by Christophe Zawadzki on April 18th, 2011 at 4:56pm JST (3 years, 6 months ago) comment permalink

Several months ago I didn’t have any problems with this plug-in, but after updating to the new version, geo-tagging with GoogleEarth is impossible.

Each time I try to import a location from GE, I get that disgusting “Windows Scripting has not been initialized” – Error. I tried reinstalling the plug and GE, but without any effect.

My OS is Win7 Ultimate.

I saw, that other users encountered that problem as well, but without any solution for solving it.
Maybe in the meantime somebody found a solution?

Regards,
Tom

I’m not sure why it works for some and not for others, but perhaps if you install Windows Scripting support manually, it will work? —Jeffrey

— comment by Thomas on April 20th, 2011 at 4:00am JST (3 years, 6 months ago) comment permalink

Hi Jeffrey,

I tried the manual install but without any effect on the problem. It would be usefull if those users, who solved the problem – if they managed to solve it – , would write a short note about the reason for that error.

— comment by Thomas on April 20th, 2011 at 10:13am JST (3 years, 6 months ago) comment permalink

Just got around to updating to LR 3.4 and then updating all of my plugins. I went from .139 to .143 and somewhere in between, the distance slider on the Reverse Geocoding dialog disappeared. I went back to .139 to verify it was there. Screenshot as proof :)

It’s not showing because you don’t have any of city/state/country checked. That’s a bug… I’ll fix it soon. —Jeffrey

— comment by JasonP on April 30th, 2011 at 8:44am JST (3 years, 6 months ago) comment permalink

Maybe I’m missing something fundamental…

Using this plugin I’m able to geotag based on a data logger… All the plugin options to “SHow in Google Maps” it are correct picture to picture.

Yet when I export to disk (local JPG) or to SmugMug using the inbuilt plugins, no geo data is included in the files. EXIFTOOL.EXE in Windows shows nothing, and SmugMug doesn’t seem to think there’s any geo data present (no Map This options.)

The Shadow GPS Injector is listed in the SMugMug plugin as a post-process action. Am I missing a fundamental setting somewhere to tell it to actually write this data on export?

— comment by ETHAN HB on May 2nd, 2011 at 5:59am JST (3 years, 6 months ago) comment permalink

Never mind, Lightroom’s dialogs are confusing. While the “Shadow GPS Injector” was *listed* in the Post-Processing Actions section, it’s not enabled until you select “Insert” and it gets a little checkbox. Duh — so it was something fundamental!

Once I Inserted that PPA everything works as expected and SmugMug joyously geotags and maps my published gallery.

I did notice that any photos in Lightroom where the geo-location changes, is not enough to flag the image for republication. So you have to manually mark the ones you’ve encoded for re-publication if adding data after the fact.

— comment by ETHAN HALLBEYER on May 2nd, 2011 at 8:21am JST (3 years, 6 months ago) comment permalink

strangely, since the last update i’m having issues again with lightroom dealing with images where the location has been saved back to the file. i used to be able to force lightroom to recognise the change in file metadata by doing a sync of the folder, but now, even after a sync, each individual photo comes up with the little exclamation mark warning that the metadata has changed, and forcing me to manually click and “import settings from disk” for each image…any idea how to work around this?

I’ve never quite pinned down the magic involved here, but also would have expected that a sync would have done it. Are you sure you checked “scan for metadata changes”? Wow, it’d be really annoying if that didn’t do it. Not much I can do, though )-: —Jeffrey

— comment by patrick h. lauke on May 3rd, 2011 at 9:09am JST (3 years, 6 months ago) comment permalink

managed to work around the problem – it seems that, as i literally just imported those photos, lightroom got itself confused somehow. going to each individual folder with those freshly imported pics first and doing a “read metadata from files” to get LR to get itself on track first seems to have solved it…after that, i managed to geotag and then sync / scan for metadata changes as before. wonder if this is due to the recent LR update to 3.4 *shrugs*

— comment by patrick h. lauke on May 4th, 2011 at 3:39am JST (3 years, 6 months ago) comment permalink

I’m getting ‘couldn’t reverse-geocode this location’ trying to pull the city/location data from the gps info tagged via Picasa – yet it shows in Lightroom’s gps info panel bit.

51.50148 -0.1264017 (Whitehall, London UK) doens’t seem to work if gps’d in Picasa. Not sure what could be wrong, no obvious explanation.

It seems to be a bug at Google, because they return a lot of detail in a note about the location (“Westminster, Parliament Square (Stop C), Westminster, London SW1A 2, UK”), but they don’t have any information in the “City”, “Country” fields, and in fact don’t even return those fields. Very strange. Perhaps report it to them. —Jeffrey

— comment by Dan on May 7th, 2011 at 7:18pm JST (3 years, 5 months ago) comment permalink

I just had what I’ve come to call a catastrophic Lightroom crash – when it freezes up and after rebooting and starting Lightroom again it has lost all of your preferences. (It’s happened to me three or four times over the years, although I have no idea what the cause is.) One of the things it loses is plugin registrations (in fact it forgets all the plugins), and now when I re-add your geoencoding plugin it has lost all my presets. I have a backup, but it’s from 3 months ago.

Which leads me to wonder, where are the currently installed presets stored? Could it be that they are still there somewhere on disk, or could they be another victim of this preference-deleting crash? It’s not a big deal, because I can rebuild the presets from my geoencoded files, but if they are stored somewhere on disk and I can restore them again, please let me know.

The presets are stored in the preferences file, which sounds like it got corrupt. If Lr freezes when it starts, you’ll have to blast the preferences file. But, once you build the list of presets, there’s a way in the plugin to export them to disk, and re-import them later. I built it so that one can transfer presets to another computer, but it serves as a backup method as well. By the way, I use the LR Backup plugin to backup my preferences, presets, and other misc Lr-related config files. —Jeffrey

— comment by Thorf on May 9th, 2011 at 2:29am JST (3 years, 5 months ago) comment permalink

Is it possible that you will add a feature in the future to set shadow GPS data based on the Sublocation/City/State/Country fields? Most of my photos have those fields, and no GPS data, but it would be great if I could export photos with the GPS injection on and get GPS locations.

Most likely I would need to set the GPS coordinates myself for each Sublocation, but done once, it would be easy for the plugin to add the same coordinates to other photos from the same location

If you’ve got the images with the same location collected, and the location handy, isn’t it just as easy to geoencode? Especially if you have the location marked in Google Earth and use a keyboard shortcut to “Geoencode Selected Images From Google Earth”, manual geoencoding like this is a snap. If you want to do it based upon the location, then set “Location” in the grid filter, and go from there. —Jeffrey

— comment by HEK on May 19th, 2011 at 4:56am JST (3 years, 5 months ago) comment permalink

Thank you for your response.
As a one time solution it would be easy to do it the way you suggest, but later when I add new photos I will have to do the same thing again. So it would be much easier for the plugin to handle it automatically :)

I know some people uses keyword instead of the location fields, but I guess the requirements would be the same: tie a location-keyword to a GPS coordinate and let the plugin add shadow GPS data :)

I see what you mean. Still, it flies in the face of what geoencoding is all about to be so rough with the coordinates, unless you’re always standing in the exact spot for each location you might name. I’ll give it some thought…. —Jeffrey

— comment by HEK on May 19th, 2011 at 9:05pm JST (3 years, 5 months ago) comment permalink

First of all I want congratulate for this great plug-in . . . I’m loving it.
Now I have a question:
How is it possilble to write the location: city/state/country fileds from the “Location currently indicated” to the fields in the lightroom database? Or is this not possible, do I have this to do manually?
Thanks
Michael from Switzerland

Visit the “Interactive” tab, and open the one-by-one dialog, and from there you can do reverse geocoding on a one-by-one basis, or bulk basis of all the selected images. The UI is really bad, sorry. —Jeffrey

— comment by Michael on May 19th, 2011 at 10:17pm JST (3 years, 5 months ago) comment permalink

The Expand “state” codes to full names (e.g. “NY” becomes “New York”) option doesn’t seem to work when I perform a reverse geocode in the Interactive tab. Previously, it used to replace ‘NSW” with “New South Wales”. Is there something I should do to enable that feature?

The coordinate I used was: -33.990450, 151.232270 with an altitude of 4.1 m.

Thank you for making such a cool plugin. I love it!!!

I’d never had Aussie support in there, but as of v.147, which I just pushed, it does. —Jeffrey

— comment by Jesse on May 20th, 2011 at 6:56pm JST (3 years, 5 months ago) comment permalink

Hi, I’m trying to utilise yourGPS plug in with my new QSTAEZ travel recorder model BT-Q1000XT – is there a straightforward way I can do this as it does not appear so at present. GPS babel doesnt seem to be able to convert the data files either. Help!!!! please!

The product website says it can output GPX, which the plugin reads natively, so that’s your best bet. —Jeffrey

— comment by Greg on May 23rd, 2011 at 8:27pm JST (3 years, 5 months ago) comment permalink

Hi! I think there’s a little bug in the plug-in. As I noticed it changes access rights for the proccessed file. It allows RW access for ALL users. In some cases it may be not suitable way.
I use it on Win7 x64.

Good luck)

— comment by Dmitriy on May 25th, 2011 at 6:54am JST (3 years, 5 months ago) comment permalink

I may be wrong, but I’m sure that in the past when I select “Pinpoint location in Google Earth” it used to show an actual marker on the map whereas now it just zooms into the map and you have to guess exactly where it is pointing to (I know the map is centred on the location but an actual pinpoint would be useful).

You probably had the crosshair-target object enabled before, but not now. See the “Show crosshair target in Google Earth” button in the Static Location tab of the geoencoding dialog. —Jeffrey

— comment by Steve h on June 1st, 2011 at 10:54pm JST (3 years, 5 months ago) comment permalink

It seems that your reverse geoencoding is truncating the Sublocation field in some cases. I have one photo with the location 51.751641, -1.263292 which converts to “Oxford, Oxfordshire OX1 1NG, UK” and another at 51.751719, -1.262855 which converts to “1-13 Tidmarsh Ln, Oxford, Oxfordshire OX1 1, UK” you will see that the postcode has lost its last two characters “NG”

Unfortunately, that’s how Google is returning it. It’s very hit and miss. Trying to reverse-geocode the location of Kyoto Station (the central hub of a city of 1.5 million) returns “Japan”, but not even the state.. no mention of “Kyoto”. But a spot 100m away and it’s got extremely detailed data. No rhyme nor reason as far as I can tell. —Jeffrey

— comment by Steve h on June 1st, 2011 at 11:13pm JST (3 years, 5 months ago) comment permalink

The Enable flag on the beta KML Personal Location Mappings function only seems to take effect after you have quit Lightroom or reloaded the plugin. I wanted to reverse geocode some pictures but without using the Mappings file, so I unchecked the enable box but it still processed them using the mappings file until I reloaded lightroom.

Ah, I’d forgotten to invalidate the reverse-lookup cache when the flag was changed. Rookie mistake. I just pushed v.153 that fixes it. Thanks for the report. —Jeffrey

— comment by steve h on June 13th, 2011 at 11:19pm JST (3 years, 4 months ago) comment permalink

Been using Geoencoding plugin for a while and just started using your Reverse Geo tab.

It seems to be incorrectly locating stuff but this may be due to semantics.:

My shots are in UK and I get the following:

Country: UK correct
State: blank
City: West Somerset incorrect (That should be in state)

Sub location: B3223, Winsford, somerset, TA22 9, UK

Winsford (which is the local village ) should be in City and sublocation I am happy to leave although I may overwrite it.

I have been using the “State” box to hold the name of the “County” that the shot is in which the package correctly pulls out as West Somerset.

Also would be nice to have a check box list to allow or exclude an item (As above I would exclude sub location)

Thanks for still a great piece of plugin. (version 20110613.152)

Uh, there is a checkbox to exclude the sublocation. As for the quality of the results, what Google returns can be very flaky. As an example, a lat/lon in the middle of Kyoto Station doesn’t identify anything more specific than “Japan”, yet the lat/lon for a location a minute’s walk away is specific down to the street. No rhyme nor reason I can come up with. —Jeffrey

— comment by Mike Watson on June 14th, 2011 at 4:48pm JST (3 years, 4 months ago) comment permalink

I can’t see the checkbox to exclude sublocation on the reverse geo tab – am I looking in the wrong place?

You can’t actually do any reverse encoding in that tab, but if you bring up any of the dialogs from it, those dialogs have the option. The “location” data is so very flaky that I didn’t include it for years, but occasional requests for it kept coming in, so I eventually added it. —Jeffrey

— comment by steve h on June 14th, 2011 at 7:31pm JST (3 years, 4 months ago) comment permalink

Regarding the poster with the question on QStarz, here’s something I posted to a local forum recently discussion QStarz+LR+Geoplugin: http://goo.gl/UVbUA

— comment by ETHAN HB on June 24th, 2011 at 10:52am JST (3 years, 4 months ago) comment permalink

This sounds simplistic compared to all the comments above, but when I open the plugin extras menu item, I get 21 options from where to get the information, including some in Germany, Korea, etc. I really only want the first two options, geoencode… and geoencode from Google Earth. Can I made these options disappear from the drop-down list?

Thanks, and love the plugins– and hello from Boston.

Yes, there’s a button to edit the sources in the plugin manager. —Jeffrey

— comment by Lindsay on June 25th, 2011 at 1:02am JST (3 years, 4 months ago) comment permalink

I love your plugins – nice job!
One thing is boterhing me – I’ve installed gps-support in LR3 and my images have been tagged before that (with PhotoMapper and GeoSetter).

I can see the Geotag in the image metadata (the file direct) but not in LR3????

Pls. help.

If the images have Exif GPS fields, you don’t need the plugin (at least not for geoencoding, though it’s still useful for its many other services). If you tagged them with an external app after they were already in Lightroom, you’ll need to invoke “Metadata > Read Metadata From File” to suck that data into Lightroom. But be careful because that can delete all the other changes you made, so experiment a bit with writing and reading metadata. If you did the tagging before you imported into Lightroom, it should be there in Lightroom. In either case, it’s there as “real” GPS data, and not the “shadow” kludge I had to come up with for my plugin, so be sure you’re looking at the right metadata fields. —Jeffrey

— comment by Andreas on June 29th, 2011 at 9:58am JST (3 years, 4 months ago) comment permalink

Me again – I’ve synced my folders – it’s showing GPS and height data now – but not in Geoencoding Support. The strange thing is that Proximity Search works!???!

Please read the docs above about how shadow data works. —Jeffrey

— comment by Andreas on June 29th, 2011 at 8:04pm JST (3 years, 4 months ago) comment permalink

One request for Geoencoding support… It would be easier to geoencode if you select a photo to start with and do some sort of matching to it.

For example:
I usally shoot a foto of my gps – I can match the time with it.

If I don’t have a foto of my gps – I’m using a foto and try to locate it in Google Earth and then in my tracklog.

That’s really the wrong way to go about it… you should set your camera time to the GPS unit, but if you can’t but do have a photo of the unit showing the time, use Lightroom’s built-in time-adjust features to fix incorrect photo times. But the best is to just set your clock as per your GPS unit…. why would you not want to? —Jeffrey

— comment by Andreas on June 29th, 2011 at 9:11pm JST (3 years, 4 months ago) comment permalink

Bonjour Jeffrey,

I use GPS-Support Geoencoding and I have a little question : is this possible to use this goodie to set a location from an original picture (with its own GPS settings) to a virtuel copy ?

I geoencode all the original picture after to create virtual copy, and unfortunately it seems impossible in Lighroom (v3.4.1) to synchronise this settings…

Regards,

Jacques

There’s no easy solution, unfortunately. You can copy data from one image to another with the plugin, but it’s a one-by-one thing, so it’ll get old quickly. Better to geoencode before importing into Lightroom (or, at least, before making the virtual copy), or perhaps use the plugin to geoencode. —Jeffrey

— comment by Jacques GRILLOT on July 3rd, 2011 at 10:22pm JST (3 years, 4 months ago) comment permalink

Bonjour Jeffrey,

Thank you for your answer about my last question :)
I agree with you about the workflow : it’s better to geoencode images before importing into Lightroom, but at the beginning with Lightroom and before find a good way for my workflow, I didn’t geoencode first, I thought it’ll be possible laterw ithout lost any data.
So, woud you mind telling me how to copy data from one image to another (my version is 20110615.153) ? Time is not a problem ;)

Regards,

Jacques

Select all the photos/copies taken at one location, being sure to have one with coordinates be the “most selected” image. Invoke the Geoencoding dialog and in the “Static” tab, press “import location from most-selected image”. Then press the “Geoencode…” button to apply it to all the selected images. —Jeffrey

— comment by Jacques GRILLOT on July 4th, 2011 at 12:07am JST (3 years, 4 months ago) comment permalink

Thank you Jeffrey for your quick answer ! :)

For your information (I don’t know if you have tested to copy GPS data from an real image to a virtual copy), it seems to not work : I selected the real image and its copy, the most selected was the real image of course. When I clicked on “Geoencode” button, option ‘Process only images that still have no GPS data (neither “real” nor shadow)’ is selected, the next message appeared : “Images selected : 2, Images bypassed : 1 (<- I think it's the real image), Images processed successfully : 1 (<- virtual copy)".

Ok, cool I thought ! But I was a little disappointed to see no GPS data seems to be copied, at the right side of LR, in Metadata view, no GPS setting appears if I select virtual copy instead of the real image.

I'm sorry to disturb you about this and I understand that you cant't give time to support all problems with your useful goodies, but if you've a good idea…

Regards,

Jacques

It’s copying it to the “shadow” data, which is the kludge my plugin uses to get around the limitation that Lightroom doesn’t allow the real GPS data to be updated. You’ll see the GPS data in the “all plugin-metadata” view (or your own private view that includes it if you build one), and if you enable the “shadow GPS injector” for your exports, it’ll be there in the proper spot in exported copies. —Jeffrey

— comment by Jacques GRILLOT on July 4th, 2011 at 12:42am JST (3 years, 4 months ago) comment permalink

Your Geoencoding pluggin is fantastic. Thanks!

I have been exporting my RAW pictures to JPG and using Picasa and Google Earth to geotag for over a year. Though this method has worked, it leaves the RAW files within lightroom without the geotags. Do you know of a way I can create a GPS tracklog from my JPG files. Then I could use your tool to tag the RAW files and simplify the workflow when I re-edit and export to JPG.

thanks!
Alexis
Exiftool should be able to do it… see the last example here. —Jeffrey

— comment by Alexis on July 10th, 2011 at 3:28am JST (3 years, 3 months ago) comment permalink

Jeffrey,

I have figured it out. Wow! My head is spinning.

I have to other questions though. I am concerned about the Metadata>Read Metadata from File step can erase develop edits. Can I work around this by doing the geoencoding first in my workflow, including all the steps in Write Back and then do my Develop Module tweeks?
Also, when you say ‘Clear out XMP files’ does this mean move them to the trash?

Thanks for your help.

Rebecca

It’s best to do a metadata write, then the geoencode writeback, then metadata read, even if this is the first thing in your workflow because one can apply develop and metadata presets during import, and those will be lost if one is not careful. Yes, clearing out XMP files means moving them to the trash. You can leave them, but unless you specifically want them, they just take space. This is all a big kluge until Adobe grants plugins the ability to update the gps data directly. —Jeffrey

— comment by Rebecca on July 20th, 2011 at 10:10am JST (3 years, 3 months ago) comment permalink

So, I carry around a GPS logger with me whenever I’m taking pictures so I can geotag them, and whenever I pull photos into LR and wipe my memory card, I also download the GPS tracks and wipe the logger’s memory. Sometimes, I’ll go a week or two between data dumps, and this results in a few hundred pictures, and a bunch of GPS tracks. I’ve noticed that there seems to be some limit to how many tracks, or lat/lon points the plugin can deal with. Often only the first N photos will successfully geotag, and I have to go through repeatedly, eliminating tracks from the list of files such that only those applying to the date range of the remaining un-tagged photos are still available. This seems inefficient. Is there any way to increase the number of GPS points or tracks that the plugin can accept simultaneously?

There’s no hard limit… it’s up to what the system will bear. I load tracks with 10s of thousands of points with no problem, but everyone’s system is different. —Jeffrey

— comment by Zane Selvans on July 21st, 2011 at 4:27pm JST (3 years, 3 months ago) comment permalink

I had the same problem as many others. Each time I tried to import a location from Google Earth, I get the famous “Windows Scripting has not been initialized” – Error. However, i installed Windows Scripting support manually (on Windows Vista) as suggested by Jeffrey and now everything is working great!

— comment by Alejandro on August 4th, 2011 at 6:28pm JST (3 years, 3 months ago) comment permalink

Geoencode Plugin: Problems with TTQV (TouratechQuoVadis) GPX Export.

TTQV5 exports GPX in UTC BUT without the “Z” in the -Stamp, there is no way round.
so TTQV5 exports: 2011-08-11T07:01:16 that should be 2011-08-11T07:01:16Z
So the result ist that pictures are taged 2h wrong, in my case the GPX is UTC and the pics are UTC+2 and the setting of the “Timezone” is ignored.

Other Geataging progs overcome this situation with a checkbox like:
[X] GPX Timestamp is UTC (or something else)

Would it be possible to add such an option to this great plugin?

best regards
Christian from Austria

The “Z” is required for times in tracklogs (ISO8601 allows it to be omitted, but the GPX standard says that times must be presented in UTC, so the “Z” is mandatory). I see by your bug report to the company is getting some traction, so I would prefer that they fix their stuff to my updating the plugin to allow for broken GPX files. Hopefully they’ll respond quickly…. —Jeffrey

— comment by Christian on August 12th, 2011 at 4:44pm JST (3 years, 2 months ago) comment permalink

Forgive what may be a dumb question – I’m new to shooting RAW and using XMP. Doing so for the first time on a trip to Maui. :)

The dialog box for the “write back” process mentions a 4 step work flow, and also mentions blowing away the XMP sidecar files. I can’t seem to find them, however. In the directory with the .CR2 files there is 1 .XMP file per image. Are there “extra” XMP files that I am supposed to delete somewhere?

No, those are the XMP files in question. As the dialog says, you’re free to delete them if you want to, but you can keep them if you like. Personally, I don’t keep XMP files with my raw files, and I don’t do the writeback (because I have no particular need for apps other than Lightroom to have access to the gps location for the originals; it’s exported copies that I want the location info embedded in). —Jeffrey

— comment by John Kilpatrick on August 15th, 2011 at 7:23pm JST (3 years, 2 months ago) comment permalink

Something’s up with GPS Support. Shouldn’t the Lat Lon show up under the Default Metadata option in Lightroom, the same as if it had been tagged with my di-GPS receiver? If I select All Plug-In Metadata, I see Shadow Lat Lon Alt, however the Map button doesn’t work. I;ve got gps-20110813.155.zip, Mac OS 10.6.8 and Lightroom 3.4.1.

I think you’re missing the concept of “shadow data”. Lightroom doesn’t let a plugin update the real gps metadata without a lot of kludge (the plugin’s “writeback” operation), so I had to come up with the shadow data idea. —Jeffrey

— comment by Lawrence G Sobczak on September 26th, 2011 at 11:39am JST (3 years ago) comment permalink

“No, those are the XMP files in question. As the dialog says, you’re free to delete them if you want to, but you can keep them if you like. Personally, I don’t keep XMP files with my raw files, and I don’t do the writeback (because I have no particular need for apps other than Lightroom to have access to the gps location for the originals; it’s exported copies that I want the location info embedded in).”

Doesn’t Lightroom keep other data in there as well? Or does the other Metadata (like keywords, EXIF data, etc) go directly into the RAW file (.CR2 in my case)? I don’t see XMP files for things I haven’t geotagged but I see a lot of metadata in the XMP file (like lens data, the copyright data I have Lightroom add) that makes me thing I might lose something if I delete them other than the shadow data.

The XMP files are optional, so you can get rid of them if you don’t want them, but of course you can keep them if you like. Their primary use is to communicate develop settings and such to compatible applications that might work with your images, but some people use them as a poor-man’s backup of the Lr catalog. I don’t use them for either, so I don’t keep XMP files around. (Then again, I don’t bother with the write-back operation either.) —Jeffrey

— comment by John Kilpatrick on September 28th, 2011 at 5:19am JST (3 years ago) comment permalink

“The XMP files are optional, so you can get rid of them if you don’t want them, but of course you can keep them if you like. Their primary use is to communicate develop settings and such to compatible applications that might work with your images, but some people use them as a poor-man’s backup of the Lr catalog.”

I think I’ve got it figured out by playing with some images today. LR creates an XMP file when you “save to disk”. The keywords and stuff I had been tagging with were stored in the LR catalog file, but “saving to disk” also puts that stuff in an XMP file as well. I wasn’t finding anything online that explained that well. And I was wondering why someone I gave the CR2 file to didn’t see my keywords and whatnot in the EXIF info.

If there is a good beginners guide to understanding all that I’d love to know about it. :)

— comment by John Kilpatrick on September 28th, 2011 at 3:17pm JST (3 years ago) comment permalink

One thing I’d like to clarify – does the “write back” operation writes the GPS data into the CR2 file or into the Lightroom catalog? Because ‘saving’ metadata in Lightroom just seems to make an XMP file.

The plugin never touches non-DNG raw files, so no, it doesn’t update the CR2 files. It also doesn’t update the catalog…. the writeback operation updates the XMP, which are used as the basis for updating the catalog when you “read metadata from file”. It’s all a horrible kludge, but one you need to go through only if you have a specific reason for wanting the gps data in the “official” gps fields. There’s not really much reason I can think to for it, other than personal preference, but to me it’s way too much kludge for too little value, so I just leave the data in the shadow fields and am done. —Jeffrey

— comment by John Kilpatrick on September 28th, 2011 at 3:19pm JST (3 years ago) comment permalink

Well, the value for me is if one is using the default export functions they understand the “official” fields. I assume that your Flickr plugin would somehow make Flickr understand the “shadow” data? Thanks, John

Please read the docs about the “shadow GPS injector”. All this is covered in the docs…. the “intro page” link above. —Jeffrey

— comment by John Kilpatrick on September 28th, 2011 at 3:29pm JST (3 years ago) comment permalink

I typically add GPS coordinates before I import new pictures so this would not be needed, but I have lot’s of older pictures from far away places to which I’d like to add the GPS coords. How well does your plugin work with files that already have the GPS fields populated?

Thanks

Just fine… you can have the plugin overrride existing data, or explicitly not override existing data. Up to you. —Jeffrey

— comment by Ross Dillon on October 4th, 2011 at 4:22pm JST (3 years ago) comment permalink

Hi Jeffrey

GPS Babel doesn’t run under Mac OS X Lion. Do you know an alternative way to covert gpx files inside your plugin?
Thanks for your help!

I can’t imagine why it wouldn’t run on Lion… are you sure it doesn’t? —Jeffrey

— comment by Christian on October 14th, 2011 at 4:40am JST (3 years ago) comment permalink

Because GPSBabel uses Rosetta and Rosetta is no longer supported under Lion. Shame, because I built scripts that would allow a drag and drop conversion of my gps NMEA files to KML and gpx.

Find a different build… anyone can compile it. I haven’t used Rosetta in years.—Jeffrey

— comment by Ross Dillon on October 14th, 2011 at 9:40am JST (3 years ago) comment permalink

I like the concept a lot, i do have one request is it possible to integrate this with google latitude ?

I alway’s have this one on my phone and it would be amazing if i could import this into the plugin.

I already tried to import the exported kml but this doesn’t work and also its a extra step which i would like to avoid. The google latitude api allows direct acces to the data.

Probably not, sorry. The plugin works with industry-standard GPX files. —Jeffrey

— comment by Wieger Wijnia on October 23rd, 2011 at 4:09am JST (3 years ago) comment permalink

Ok thank u,

I worked around it, i found a amazing android app and sweet talked the developper into including gpx support which he did.

It integrates with google lattitude, ads a load of extra options and integrates with tasker for android which makes it very flexible.

Its called latify for google latitude and if u own a android phone and wants a cheap gps tagger i can highly recommend it. I tested it with the gps plugin and its working fine. U can also export the latitude history as gpx.

The website of the app is https://market.android.com/details?id=com.ecs.latify

— comment by Wieger Wijnia on October 28th, 2011 at 2:34am JST (3 years ago) comment permalink

Hi Jeffrey,

I have moved my lightroom to a new computer and downloaded the latest version of all your googlies. The only problem I have is with the Geoencode. (I have Google earth loaded and running). When I try to import location from Google earth a window appears GetCurrentGEView.exe Windows Scripting has not been initialized Exiting application.

I have configured the path to Google earth (show cross hairs will open earth) reloaded the plugin and uninstalled and reinstalled Earth but the problem remains.

Plugin Version 20111018-158
Lightroom 3.5 64 bit

I’ve heard of this before, but don’t know how to solve it. There’s apparently some kind of “allow scripting” setting somewhere, but I don’t know where. Anyone have any idea? —Jeffrey

— comment by Jason Clarke on October 29th, 2011 at 9:48am JST (3 years ago) comment permalink

It was me who raised the windows scripting error in google earth a couple of years ago. After a fair bit of digging around on the Internet I never found the cause, all required services appeared to be running. I since moved my entire windows installation to a ‘new’ virtually identical pc and didn’t have the problem, so it seems very odd.

The workaround on the old computer was to find the location in google earth, read the coordinates and manually enter into the geo encode static location box in the plugin.

— comment by Brian on November 6th, 2011 at 5:42pm JST (3 years ago) comment permalink

I’m really fond of this plugin and it’s almost perfect for my use. So far I miss possibility to get nearby area name to Sub-location field but it looks to me that this is something which is not available in google maps but geonames.org and others are offering it.

Second thing which would be nice is “establisment” field like in these examples. It tells name of the airport and even terminal number. Many time I could but this data to headline or caption or as a keyword.
http://maps.googleapis.com/maps/api/geocode/json?latlng=40.64732,-73.790424&sensor=true
http://maps.googleapis.com/maps/api/geocode/json?latlng=60.318831,24.968104&sensor=true

— comment by Tomppa on November 12th, 2011 at 10:49pm JST (2 years, 11 months ago) comment permalink

Hi
I wonder if it is possible to “write back” GPS data “the other way” – by that I mean from “real” data to shadow data? Would be interesting since my workflow is based on the shadow data, but I have, and still gets more of, images that are positioned by other means.
And thanks for great plugins!
Regards, Odd H.

Sure, I just pushed a new version that adds it to the “Etc.” tab. —Jeffrey

— comment by Odd Harald on December 1st, 2011 at 6:51pm JST (2 years, 11 months ago) comment permalink

Getting ready to use your Geoenclding LR Plug in on my Lightroom 3 photos. Both are the latest versions. The camera times and the geoto tracker I used had the same time set for Turkey where all photos were taken. When I pull up your plugin it asked what Time Zone in which to interpret photo dates. I am not sure what to enter here. Would this be the time zone in which the photos and track were taken?

What is the difference between selecting photos without “real Exif GPS” and “GPS data?

Looks like a great plugin. Thanks for helping with these questions.

The timezone should be the one you had in mind for the camera’s clock when the photos were taken. If the time shown on the camera clock matched the local time when they were taken, you want to choose the timezone for the local area. Tracklog times are absolute so you don’t need to tell the timezone, but photo-metadata times don’t include the timezone, so you have to tell the plugin so it can convert the wall-clock time to an absolute time.

The “real Exif GPS” refers to GPS data that got in there directly from the camera, or via some other software app before loading the images into Lightroom. Read on the plugin page about the plugin’s “Shadow” kludge. —Jeffrey

— comment by Terry on December 5th, 2011 at 11:38am JST (2 years, 11 months ago) comment permalink

Hi, I’ve found a tiny issue with this amazing plugin (it’s still amazing even with the issue).

If the title of the image contains an ampersand, the resulting .kml when exporting to Google Earth will be invalid – making it not load into Google Earth. Do you think you can sanitize the title?

Thanks!!

Oops, sorry about that… nothing to blame but sloppiness on my part. I just pushed a fix. Thanks for the report. —Jeffrey

— comment by talsit on December 5th, 2011 at 7:07pm JST (2 years, 11 months ago) comment permalink

Hi, Jeffrey,
Renaming the files on import into LR allows to write the gps coordinates into the new file name. Is there any real use for this feature?
According to a review on Lumix DMC-FT3 this camera shows country and city and iights in the area an saves this data if desired (500.000+ sights in 173 countries). I wonder if this program is available outside the Panasonic environment , too. (I’m using Nikon D700 with Dawntech Logger)
Neither Adobe help desk nor Adobe Forum could answer this questions. They sent me to your blog…
Best regards,
Gottfried

I can’t think of any good use for having the mapping coordinates in the filename. And I don’t know of any way to access the maker-specific data like location from within Lightroom, until Adobe supports it natively, but you can view it one-by-one with this plugin. —Jeffrey

— comment by Gottfried on December 15th, 2011 at 5:23pm JST (2 years, 10 months ago) comment permalink

Any chance of getting barometric pressure / altitude included? I realize it’s not very accurate, but I have a specific application that could use it. I use a Panasonic TS3 for keeping flyfishing records, and having a way to correlate atmospheric pressure with photographs of locations / fish caught would be absolutely amazing.

Thanks in advance.

mrm

Altitude is included, but it’s unlikely barometric pressure will be.. I’ve not seen that as part of a gpx file, and even if so, it’s unlikely of interest to most people. For your needs, you might consider something with Lr/Transporter to get the data into Lightroom. —Jeffrey

— comment by Michael Magnan on January 2nd, 2012 at 2:08pm JST (2 years, 10 months ago) comment permalink

Can you comment on your plugin and the fact the LR4 now appears to do geotagging? Similarities and differences?

I posed about that on my blog earlier today, here —Jeffrey

— comment by JD on January 11th, 2012 at 12:22am JST (2 years, 9 months ago) comment permalink

Does your plugin support LR4?

Yes. I’ve added a note to the top of the page about it. —Jeffrey

— comment by Michael on January 11th, 2012 at 4:42pm JST (2 years, 9 months ago) comment permalink

Hi Jeffrey,

i have tested GeologTag http://www.galarina.eu/geologtag . That App can export the GPX files via a http Link on the iOS Device. It would be handy if your GPS Plugin can open http URLs directly.

I also raise my hand for the “fill the street field” feature… :)

Thanks for your great work!

— comment by Mr. Bean on January 12th, 2012 at 1:12pm JST (2 years, 9 months ago) comment permalink

Just downloaded and used the plugin. Wonderful – except that after exporting the images (including ones from Canon S95) and then pointing to that subdirectory in LR, the GPS coordinates for the Canon images did not show up. But when looking at those images in WinExplorer, sure enough the data was there?? Problem. So I tried going to the Metadata>”read metadata from file” and then it appeared. So I got what I wanted but is the way to do it? — Gary

I’m not sure why you’d want to re-read into Lightroom copies that you exported (so that you end up with the non-destructive-edited master and a destructively-edited copy). Generally after geoencoding with the plugin you’ve got access to the location via the plugin-specific metadata (though in Lr4 it’ll work with native location metadata) and through the shadow injector you’ve got it in the copies. Still, if you can’t wait for Lr4 and you want “real” geoencoded locations with your master images, check out the write-back tab of the geoencoding dialog. —Jeffrey

— comment by gary little on January 15th, 2012 at 1:38am JST (2 years, 9 months ago) comment permalink

Hi Jeffrey,

I’ve tried your powerful gps module in lr3, really helpful. But how can I return to the configuration before especially in terms of shadow data? Assumed that in all pictures shadow data are flushed does the catalog and/or the lr database still contain the structure or fields? (There was a notification of a general change to be confirmed at the first use)
Thanks in advance for some explanations about where and how your shadow data are implemented!
Also thanks for your great work for the community!

I don’t know of any way to flush all the data from the catalog. I wish Lightroom provided for this, because in all my years of testing I’m sure I’ve built up quite a bit of cruft. The best I can suggest, if you don’t have a backup to return to, is to select every image and flush the data (via the “Un-Encode” tab of the geoencoding dialog) then disable the plugin. It won’t remove everything last trace, but that’ll get rid of the bulk of it. —Jeffrey

— comment by Manfred on January 15th, 2012 at 6:40am JST (2 years, 9 months ago) comment permalink

Jeffrey,

Would it be possible to load the city and State information in the Metadata from your Plugin once the GPS location has been established?

Sure, that’s reverse geocoding and it’s supported in the “Reverse Geo” tab of the geoencoding-support dialog, and also in its “one-by-one” tab. —Jeffrey

— comment by Chuck on January 29th, 2012 at 6:27am JST (2 years, 9 months ago) comment permalink

Jeffrey,

I have installed the latest version of the plugin, and it seams that it doesn’t “understand” anymore the location I paste from Google Earth. It looks like :
47°06’24.37″ N 2°06’15.49″ W
I’ve put a comma, spaces, etc…
It’s something I have done many times before, with older versions of the plugin.

Can you help me ? Thanks.

Not sure what I did, but I’ll get it fixed in the next version. Until then, you might try taking advantage of the “Geoencode Selected Photos from Google Earth” option from the plugin-extras menu. With a keyboard shortcut, it makes geoencoding with Google Earth quite simple. —Jeffrey

— comment by JC on February 2nd, 2012 at 3:35am JST (2 years, 9 months ago) comment permalink

I entered a google maps URL in the location box:
http://maps.google.co.uk/maps/place?q=the+hob+forest+hill&hl=en&cid=2754844324650035941
Location currently indicated says nothing
Also it says “Valid location not yet specified”
I am using 20120123.165
(London, UK)

The plugin looks for a latitude and longitude pair in the URL itself, which most Google-Map URLs have, but that business search result URL doesn’t have it. —Jeffrey

— comment by Jack James on February 2nd, 2012 at 7:54pm JST (2 years, 9 months ago) comment permalink

I did not notice this option ! It works great ans fast. It’s wonderful how your plugin are easy to use AND powerful !
Thanks again

— comment by JC on February 3rd, 2012 at 3:45am JST (2 years, 9 months ago) comment permalink

Hi,
a couple of weeks ago I asked if it makes sense to write the gps data into the file name during import.
Your answer was that you could not imagine any good reason to do this.
Editing the file names you can choose to write the ISO country code into the new file name. It works if you have the gps code in the file name. Do you know any other way how to make this feature work?
LR 3.6 doesn’t provide this feature in the import preset dialog.
Maybe I didn’t find it?
Best regards,
Gottfried, Vienna
I’m not quite sure what you’re asking (I wouldn’t think that Lightroom would make up a country code on the fly from a lat/lon pair). Best to follow up by email if you have more details. —Jeffrey

— comment by Gottfried on February 23rd, 2012 at 5:40pm JST (2 years, 8 months ago) comment permalink

Hi Jeffrey,

I tried to bulk reverse geocode a number of images (~50) and noticed that some of the location data was incorrect. It seems that the first reverse geocoded location was applied to all the images. I removed the incorrect locations, and tried again. This time I received the message that nothing had changed. Went to the one-by-one method and it worked; although much slower.

Any thoughts as to why the bulk reverse geocoding didn’t work?

Thanks and a great plugin. Use it all the time.

Jerry

When you do a bulk reverse, there’s an option to indicate how far away a location has to be to warrant a new lookup. It sounds as if you picked a large value such that all locations were “close enough” to the first lookup to get its results. Try picking a smaller value for that option. —Jeffrey

— comment by Jerry Mergen on February 28th, 2012 at 4:02am JST (2 years, 8 months ago) comment permalink

Jeffrey,

Thought that might be the case, so I went back and changed the location value to ’0′, no overlap. The resulting bulk recoding returned a message that nothing had changed/updated.

Thanks … Jerry

— comment by Jerry Mergen on February 29th, 2012 at 7:51am JST (2 years, 8 months ago) comment permalink

Hi Jeffrey,

I’m having trouble getting this plugin and the Metadata-Wrangler to work with LR4 on Win7-64bit.

The plugin asks to upgrade the catalog and then I get the following errors:
**** Error 1

The plug-in’s metadata was not fully updated.
LrCatalog:withPrivateWriteAccessDo: could not execute action ‘(unknown)’. It was blocked by another write access call, and no timeout parameters were provided.

**** Error 2

An error occurred while attempting to run one of the plug-in’s scripts.
Attempt to access property “data” that’s not declared in Info.lua

**** Error 3

An error occurred while attempting to enable the plugin.
Attempt to access property “data” that’s not declared in Info.lua

I auto-istalled the plugin to the latest version from LR3.6 and tried a manual install as well afterwards.

2 things I can think of:
- I’m using LR4 in trial mode until the upgrade with the serial number arrives.
- I did a complete reinstall of my system recently after getting a SSD. Afterwards I had to change permissions to my LR-plugin folder to get the auto-updating to work again. While this works now in LR 3.6, maybe there are some other permission issues I have to resolve? I have changed the catalog permissions already, but that did not change anything.

Anyway, thanks for your continued work on all your plugins. They really help a lot.

Marc

Ah, I’ve seen this once or twice before, but we’ve never been able to track it down, but it’s easy enough to work around. Disable all plugins in Lr4 (or in Lr3 then upgrade to Lr4). Then enable only the geoencoding plugin so that it can do its own upgrade and data migration. Perhaps for good measure, restart Lightroom, then go ahead and enable other plugins as normal. Hopefully that should allow things to go smoothly. —Jeffrey

— comment by Marc D on March 6th, 2012 at 10:31pm JST (2 years, 7 months ago) comment permalink

I’m just wondering whether it would be possible to geotag an image based on existing IPTC location data? I have tagged mosted of my Lightroom collection with Country / City metadata and was hoping that Lightroom 4 would be able to use that to plot them in the Maps module but it seems to ignore that. It would be great to be able to process the location fields and create an approximate GPS location for any that parsed correctly?

The problem with that idea is that you’re taking something that’s fairly vague (cities can cover a huge expanse) and turning it into something with apparent pinpoint accuracy, and there’s no way to tell that it’s not really that accurate. It would be nice if each location could have some kind of “confidence” or “accuracy” field associated with it. It’s easy enough to have the plugin run through and, with Google’s help, come up with a latitude/longitude pair, but I’m just don’t think it’d be all that useful. Maybe if I also had them thrown into a special “Location needs to be refined” collection, that would be enough to make it useful? —Jeffrey

— comment by Rob Boltman on March 10th, 2012 at 10:34pm JST (2 years, 7 months ago) comment permalink

I upgraded from LR3.6 to LR4 a couple of days ago. I have a problem; apart from a few images the GPS location is not appearing in LR4 Map. (even after giving it lots of time)

I am not sure I consistantly did the write back the data (in LR3.x using the plug in). Would this be the cause of the issue. Should I reopen the catalogue in 3.6 and do a writeback on all images? Then open in LR4?

No, the writeback thing was a kludge. Maybe you did a writeback but hadn’t re-read the metadata back into Lightroom? This is a dangerous area because if you “Metadata > Read Metadata From File” at the wrong time you can end up destroying all your Lightroom changes.

To test, pick a photo you believe is geoencoded and make a virtual copy, then with the copy do a “Read Metadata From File” to see whether the location is added. If so, your data had been in the file but not in Lightroom. If so, go back to the original and do a “Metadata > Save Metadata To File” followed by a “Metadata > Read Metadata From File”, and if the location data comes in, the solution for all your images is to do the save followed by the write.

It would be good, first, to check in Lr3 to see whether the shadow data is there… if it had been but got lost during migration to Lr4, that would be a bug in my system that needs to be addressed, and I’d ask for a zipped copy of you lrcat file to test with. —Jeffrey

— comment by scotta on March 11th, 2012 at 11:32am JST (2 years, 7 months ago) comment permalink

Updated to LR 4, updated and registered the plugin. Despite new Maps module in LR 4 the usability of the plugin is much better but I have a problem.
I load a gpx file from my last trip to Argentina, set time to UTC -3, the plugin displays “Selected tracklog has 599 datapoints, running from Thu, Feb 23, 20123:51PM to 5:31PM”, the picture I want to tag is taken at 17:05:06 but the plugin tells me “Tracklog misses selected images (by 4 hours: check the timezone setting?). Tried several other pictures and tracks unsuccesssfully.

I just pushed version .172 that’s a bit more rigorous in how it handles timezone issues… please give it a try, and if it’s still not working correctly, send a log with a description of what’s going on. —Jeffrey

— comment by Alain on March 12th, 2012 at 11:48pm JST (2 years, 7 months ago) comment permalink

172 works fine, thanks

— comment by Alain on March 13th, 2012 at 4:43pm JST (2 years, 7 months ago) comment permalink

Having geo-encoded my photos in LR3 using this plugin I have noticed that when I export to jpg files and use the shadow gps injector you seem to also be setting the xmp field GPSDateTime – is that correct? My problem is that having transfered a number of photos to a tablet (Android) – some with and some without GPS data, the tablet seems to sort the photos by this GPS time in preference to the Exif datetime taken and so the photos are out of order. I wondered if there was some way to either not set the GPSdateTime field or have it set to the local time taken as an option? Thoughts?

That’s really a bug in your tablet photo-viewing app… you should ask them to fix it. In the mean time, perhaps you can strip the troublesome fields with my Metadata Wrangler plugin —Jeffrey

— comment by Steve on March 14th, 2012 at 1:06am JST (2 years, 7 months ago) comment permalink

Hi Jeffrey,

I’ve been using your GPS-Encoder for quite some time in conjunction with a GPS tracker. That was a feasible solution. Nowadays I switched to using my iPhone with Google Latitude for GPS tracking. Thus I would love to have a plugin that just accesses my Latitude account via its API, fetches GPS data as available and attaches that to my photos.

What do you think – is that possible? Would love to see that as an addition to your collection. ;)

Cheers,
Alexander

It’s a good idea, but not one I can do soon, sorry… my “todo” list is very long. —Jeffrey

— comment by Alexander Czernay on March 14th, 2012 at 11:58pm JST (2 years, 7 months ago) comment permalink

I am now using your geoencoding plug in (v 173) with Lightroom 4. With previous versons there was a four or five step process to geoencode pictures (encode, read metadata, flush, write metadata, delete .xmp file) . Am I correct in that’s now a one or two step process (encode, delete .xmp) , and that the r/w metadata steps are no longer necessary? Thank you for your plug-in. I had a problem with the software that came with my traker in Vietnam and was able to use your plug in to save the day. I also use it when I take GPS with GPS Stone with my iPhone.

Now it’s just a 1-step process (encode). XMP now plays no part in it one way or the other. —Jeffrey

— comment by Terry Straehley on March 17th, 2012 at 7:20am JST (2 years, 7 months ago) comment permalink

Hi Jefrey,
with the plugin’s »Pinpoint in Google Earth« the range ist 100. For me its better >300. So, can I enywhere set the value? Or edit the .lua file? Thanks and Regards Thomas

The plugin just tells Google Earth the location… anything about the default view comes from Google Earth. Perhaps it’s a setting you can adjust? —Jeffrey

— comment by Thomas Kemnitz on April 2nd, 2012 at 11:33pm JST (2 years, 7 months ago) comment permalink

I’m still running Lightroom 1, never liked the layout of 2 or 3 for adding/checking metadata, would this plugin work with it?

No. —Jeffrey

— comment by ChrisN on April 6th, 2012 at 3:43pm JST (2 years, 7 months ago) comment permalink

LR 4 under Windows 7 64bit, Geoencoding plugin 20120330.174. For some reason Import location from active image button is always disabled, even when the active image has a geolocation. Could this be because I haven’t provided any altitude information? Thanks.

No, altitude is imported if available, but isn’t required. Are you sure the most-selected image has a geoencoded location? If it is, then please send a log, though make sure you’re using the latest version, because I just added some extra debug logging in this area. —Jeffrey

— comment by rubin110 on April 11th, 2012 at 6:58pm JST (2 years, 6 months ago) comment permalink

Thank you for doing something to your plug-in! I opened up the latest incarnation (.175) and it asked to update my geo data. Previously the photos geo-encoded with your plug-in had not appeared in Lightroom 4′s Map module, possibly because of some oversight on my part. After a couple of minutes work 7,541 photos were visible on the map! That was 5,000 more than had been before.
I could get your plug-in ones to appear by copying from the jf geocoding support area of the Metadata to the GPS area via Google maps, but doing that 5,000 times was not an option. So, once again, Thank You Very Much!!!

— comment by GOC on April 20th, 2012 at 8:12pm JST (2 years, 6 months ago) comment permalink

Done and Fixed

It was Mcfee Anti Virus (which was one of the first programs I removed) had left some registry keys. I used the Mcfee removal tool and bang it all works again.

Cheers jason

Hi Jeffrey,

I have moved my lightroom to a new computer and downloaded the latest version of all your googlies. The only problem I have is with the Geoencode. (I have Google earth loaded and running). When I try to import location from Google earth a window appears GetCurrentGEView.exe Windows Scripting has not been initialized Exiting application.

I have configured the path to Google earth (show cross hairs will open earth) reloaded the plugin and uninstalled and reinstalled Earth but the problem remains.

Plugin Version 20111018-158
Lightroom 3.5 64 bit

I’ve heard of this before, but don’t know how to solve it. There’s apparently some kind of “allow scripting” setting somewhere, but I don’t know where. Anyone have any idea? —Jeffrey

— comment by Jason Clarke on June 1st, 2012 at 6:30pm JST (2 years, 5 months ago) comment permalink

Hi Jeffrey,

Would it be possible import from active image and save into static preset the metadata fields: location, city, state, country and ISO country code? And when load from static preset fill this fields automatic.

Thanks, from Spain

It sounds as if you’re describing the metadata-template stuff already built into Lightroom. —Jeffrey

— comment by Jose on June 4th, 2012 at 5:32am JST (2 years, 5 months ago) comment permalink

Some requests:
When uploading to flickr, the pictures appear in the photostream and in sets in the order in which flickr thinks they are uploaded. Unless I specify that the update time and date should be set to the time and date taken. I don’t have my flickr account very long, and cannot set the time and date to before the start of my subscription. I am processing my photos from old to new, and that means that the only option currently available to me is the order in which the pictures are uploaded to flickr.
Your plugin does not seem to take the time and date into account, if not using the time and date taken. It seems that often it works backwards in the collection it is publishing.

Now my requests:
Could you make it so that pictures to be published are uploaded with oldest time and date first and then working to the newer ones? That would keep my photostream on flickr in a much better sort order than it currently is.
Would be even better if you could make it possible to sort my entire photostream by putting fake upload (please don’t change time and date taken :-) ) times and dates in all my pictures. This should then use a configurable time and date period for the fake times and dates. For example, use a publish time and date going up a second or minute for every picture, starting at a given time and date.
Another thing that would be very nice in the plugin would be the ability to keep all my sets sorted automatically. In the flickr organiser and set pages it is possible to sort sets, but it is a bit of a chore to go through all my sets every time I uploaded something. Perhaps sorting sets is possible through the flickr API. If that is so, I would dearly like to see it as an option in your plugin. I like my sets ordered new to old on date taken, but there are other options as well.

Thanks for listening…

The plugin uploads photos in the order you have them in the grid when you invoke the export, so you have full control of the order. —Jeffrey

— comment by Marjo on June 25th, 2012 at 7:49am JST (2 years, 4 months ago) comment permalink

Hi Jeffrey,

thanks for this great plugin. Could you please add support for openstreetmap in the “configure map url” menu. This would be really great. Tank you very much.

Viele Grüße aus Berlin. (I read you can speak german. ;-) )

Patrik

Done… just pushed a new version out. —Jeffrey

— comment by Patrik on June 30th, 2012 at 6:33pm JST (2 years, 4 months ago) comment permalink

Hi Jeffrey,

I can’t figure out how to transition my routine. I used to go to Static Location, pull the coordinates down from Google Earth, and geoencode the selected pics. Then I’d go to Write Back to put the data into the file, then exit. Back in Lightroom I’d select “Metadata>Read metadata from files.” When I exported to Flickr the Map would load the location I wrote to the file.

Now there’s no “Write Back” and when I go to Flickr it doesn’t find my location automatically Is there any workpath tip I need to know?

Thanks,

Gene

Sounds like you’re on Lr4 now… write back and all that is no longer needed. (You didn’t need to write back with Lr2/Lr3, either, if you used my plugin to upload to Flickr, but that’s beside the point now with Lr4.) If the geoencoding is not getting to Flickr, check all the metadata options (about stripping metadata, etc.), and make sure the location is not marked “Private” in Lightroom’s map module… —Jeffrey

— comment by Gene on July 17th, 2012 at 9:27am JST (2 years, 3 months ago) comment permalink

Hi Jeffrey, thanks for this great plugin! It works very well for me. At the moment, I’m working through a backlog of old photos and old tracklogs. I’m in the central European time zone. It would be ideal if I could select a few years’ worth of photos and select all tracklog files simultaneously, and the plugin would work out for itself – based on the timestamp of the photo – whether the timezone is CEST (summer time) or CET (winter time). Summer time starts on the last Sunday in March and ends on the last Sunday in October (see http://en.wikipedia.org/wiki/European_Summer_Time for formulas). I’m not sure if there are similar straightforward rules for other time zones. Would it be practical to add timezone offsets that are automatically compensated for summer/winter time (e.g. CET/CEST auto)?
Finally a suspected bug: when I select dozens of GPX files simultaneously, it seems that only the first few files are actually read by the plugin. E.g. I selected GPX files from 21st April to the 21st July and the plugin says “Tracklogs have 3.378 datapoints, running from Sat, 21 Apr, 2012 11:04 am to Sat, May 19, 2012 11:43 am UTC+2″ so it misses out many files after 19th May.

That’s a huge can of worms that’s way too complex for the plugin to get into. You can use Lightroom’s ability to filter by date to select blocks of photos that you know to be in one timezone, then select all your tracklogs and apply them, then repeat for other timezones. —Jeffrey

— comment by David van Kemenade on July 22nd, 2012 at 3:03am JST (2 years, 3 months ago) comment permalink

I’ve been using your geoenoding plugin for years, and value the utility and convenience of it. Thank you.
Recently I’ve started using a Canon GP-E2 to directly encode my raw files with location data, and although Lightroom 4 displays the location data, it doesn’t display the compass data, even though (I’ve been told) dng contains the information. While I hope LR eventually will display that information, I wonder if your plugin can fill the gap until they do. I assume “bearing” isn’t the same thing, as it remains blank.
(FYI: West Bloomfield, MI, USA)

There’s no easy access to that extra information, but you can view it on an image-by-image basis with my metadata-viewer plugin, which runs ExifTool on a master image and displays everything it finds. —Jeffrey

— comment by Daniel Ernst on July 23rd, 2012 at 5:29am JST (2 years, 3 months ago) comment permalink

Geoportail released a new version, the URLs syntax changed, which breaks old links.
New syntax is :
http://www.geoportail.gouv.fr/accueil?c=-0.48694444444444,42.849722222222&z=0.00005&l=ORTHOIMAGERY.ORTHOPHOTOS$GEOPORTAIL:OGC:WMTS%281%29&l=GEOGRAPHICALGRIDSYSTEMS.MAPS.3D$GEOPORTAIL:OGC:WMTS@aggregate%281%29&l=TRANSPORTNETWORKS.ROADS$GEOPORTAIL:OGC:WMTS%281%29&permalink=yes

Can you please update your plugin ?

Just pushed a new version; thanks for the heads up. —Jeffrey

— comment by Alain on August 16th, 2012 at 4:35pm JST (2 years, 2 months ago) comment permalink

Hi Jeffrey,
I am a very sporadic, but long time user of your plugins and they are just awesome. Mostly I use the smugmug one, which I registered already starting with Lightroom 2.2 or so. Since I use the programs so rarely I am a bit reluctant in posting bug reports, but I believe I still have found two small bugs in the gps plugin:

The first one is related to how the plugin handles geoencoding from track files with MULTIPLE track files (which I never expected would be possible in the first place – it is a great feature!)
- firstly (very minor), if some pics can not be encoded, the error message in the log is sometimes wrong: It says, for example “track lock starts 22 hours later”, but the 22 hours here are calculated always from the first point of the first file, it seems, not from the overall earliest point. No problem if you select the files in the correct order, of course, but at first I thought the multi-file encoding does not work because of the wrong error message.

The second problem I noticed is in the “view in Google Earth as KML” function: The Thumbnails always seem to be 500px, no matter what I enter in the dialog. This is the most annoying one, as it means the number of images per KMZ is severely limited if you want to show the KMZ on google maps (instead of google earth), which supports 3MB max at this point.

I work with Lightroom 3.6

Finally: two questions – since you seem to have found a way to access the preview cache images: Could the KMZ file creation not be much faster if you just used those and rescaled them for generating thumbnails rather than calling the renderer each time? That is, I am assuming the renderer is called, as it takes so long per image. Second question: Generating KML files also seems to take quite a while with many images – but there is no progress dialog. Somehow nothing happens for a long time, and then suddenly Google Earth pops up when you no longer expected it. Maybe you could look into it next time you geoencode for your own pictures.

Thanks for your consideration, and thanks for the great software, keep up the great work!

- Simon (from Germany & USA)

I just pushed v.288, which fixes the bugs you cited; thanks for the report. About the preview cache, I can’t use it (even if I had access, which I don’t in Lr3) because you’re never sure how up-to-date it is. About the progress dialog, if you’re not generating images, it should be very fast… on my slow laptop, 2,000 images took just a few seconds. Nevertheless, I added the progress dialog if there are more than 100 images. —Jeffrey

— comment by Simon on September 1st, 2012 at 5:01am JST (2 years, 2 months ago) comment permalink

Not sure if your plugin will do this or if you have seen anything that would. Here is the problem I am trying to solve. I have a Nikon D300 with the GPS attachment (Phottix). It is set to power up when the camera is turned on so that its not draining the battery the rest of the time. However because of the time lag before it acquires its position, I always find that I have anywhere from a couple to a half dozen photos that aren’t geo tagged at the beginning of each sequence of new photos. I’m ideally looking for a way that the coordinates could be automatically attached to non tagged photos based on the geo data in photos within X minutes of their exif date. Any ideas?
Thanks

An easy, automatic solution doesn’t come to mind, sorry. This is one reason I use an external logger. Of course, you could use both, and rely on the external logger only for images not otherwise geoencoded, so you’ll get most of the best of both worlds. —Jeffrey

— comment by Roger Miller on September 1st, 2012 at 10:33am JST (2 years, 2 months ago) comment permalink

I’ve used your geoencode plugin for a while now and have been more than satisfied with it. It works great. However very recently it has started to give unexpected results. I returned from a long vacation in Oregon and when I tried to put read the tracklog I received endless error messages. I ended up manually inserting the coordinates. On more local shorter trips I find it still works but often one image will work and the other one will not. I don’t get it as it should be more and more accurate not less. I use a Garmin 62s GPS and a Pentax DSLR. From my end nothing has really changed and I’m still using the latest version of 3.x of Lightroom. Hopefully a future version will work better. Note that my DSLR was acting up and is now in for repairs but the images were fine so I have to think that the metadata was fine too.

Not much I can glean from “error messages”… did they perhaps give information on the kind of error? Perhaps try a small batch (one photo?), and when you get the error, send a log along with a note about the problem. —Jeffrey

— comment by Glen on September 23rd, 2012 at 8:54am JST (2 years ago) comment permalink

Google Photo Sphere – GPano XMP: Is it possible to write the Google GPano data into stitched 360° panoramas to trigger the flag “UsePanoramaViewer” in the Google+ image viewer?

Sample XMP code from a Photo Sphere jpg file:
---- XMP ----
XMP Toolkit : XMP Core 5.1.2
Use Panorama Viewer : True
Projection Type : equirectangular
Pose Heading Degrees : 157.0
Cropped Area Left Pixels : 1095
Full Pano Width Pixels : 6258
Cropped Area Top Pixels : 758
First Photo Date : 2012:10:26 11:44:57.233Z
Cropped Area Image Height Pixels: 1541
Full Pano Height Pixels : 3129
Source Photos Count : 17
Cropped Area Image Width Pixels : 4002
Last Photo Date : 2012:10:26 11:45:42.942Z
Largest Valid Interior Rect Left: 0
Largest Valid Interior Rect Top : 0
Largest Valid Interior Rect Width: 4002
Largest Valid Interior Rect Height: 1541
Creator Tool : Google

I’m not quite sure what you’re asking… if you have a tool writing XMP into the JPG, that should remain in the image through export, I would have thought. I don’t see what a plugin can do here. —Jeffrey

— comment by Thomas on November 18th, 2012 at 5:23pm JST (1 year, 11 months ago) comment permalink

The GPano tags are written by the new Nexus 4 cellphone into Photo Sphere image files to enable the spherical panorama viewer in Google+. To enable the viewer also on panorama images stitched with other software on workstations the xmp code can be imported in Photoshop into the image file. I used the following snippet to display this panorama on Google+
https://plus.google.com/u/0/117871522935757196443/posts/9HQZm1UcoaK

I’m still not sure what you’re asking of me, though. It seems that whatever is creating the panorama should add these tags. A Lightroom plugin could be built to construct the tags from a given set of photos, but it’s not something that falls into the range of what the geoencoding plugin would do, and I’d think it’d be more appropriate for a Photoshop plugin to do it, since Photoshop is building the pano and has all the info. —Jeffrey

— comment by Thomas on November 20th, 2012 at 7:31am JST (1 year, 11 months ago) comment permalink

Two feature requests

One for the reverse geo-coding option.

I mistakenly had the wrong field selected when I did a sync, resulting in many different location names being replaced with one location name. The lat/long was unaffected so I used a metadata filter to isolate the state name. I then reran the reverse geo-code to restore the correct location information.

Currently the reverse geo-coding options are “Fill in only if blank” and “Overwrite”. It would be nice to have an option along the lines of: replace only if there is mismatch between the lat/long and location name returned from query.

Two, it would be nice if one had the option to use the three-character ISO, instead of the two character code.

thanks and happy new year.

— comment by Alex on December 30th, 2012 at 8:46am JST (1 year, 10 months ago) comment permalink

In the past few days, I’ve been experiencing an error from the plug-in that I haven’t seen before. It complains that Google is rejecting reverse geo-encoding requests because I’m using the plug-in too much or too often. I had this happen when reverse encoding 140 or so photos. In the past, I’ve done 1,000 or so at a time and not had this happen. I can wait a little bit and go back and hit the photos that got missed and it works fine. It’s almost as if the plug-in is hitting Google with requests too quickly.

I’m guessing that Google must have changed something, since this hasn’t been a problem in the past. Let me know if there’s any diagnostic information I can send you that will help find the issue behind this.

I haven’t heard of any changes on their side, but they do reserve the right to make changes any time…. —Jeffrey

— comment by Paul Mensch on April 18th, 2013 at 8:48am JST (1 year, 6 months ago) comment permalink

Hi Jeffry,
Is it possible that when geoencoding from Google Earth, it will add the directions to the new function in Lightroom 5, with the direction that Google Earth is pointing to? That would be really nice…
Tomas from Östersund, Sweden

That would be nice, but it’s not easy… I don’t know how to get the direction being faced from Google Earth (they’ve dropped official support for the API I was using to get the location, though that part still at least works), and there’s no place in the Lightroom-native metadata to stuff the location. —Jeffrey

— comment by Tomas Johansson on May 5th, 2013 at 2:41am JST (1 year, 6 months ago) comment permalink

Import location from Google Earth doesn’t work anymore
Google Earth 7.0.3.8542
Mac OS 10.8.3
Lightroom 4.4

I’ve gotten no other reports, and just tried with the same OS/LR version and GE 7.1.1.1580, and it worked, so perhaps you should upgrade Earth, and if it still doesn’t work, send a log. —Jeffrey

— comment by alain on May 14th, 2013 at 4:39pm JST (1 year, 5 months ago) comment permalink

Jeffrey,
thanks so much for your plugins, they are a lifesaver.

I have an enhancement request for Geocoding…

I often have data points that are as much as 15 minutes apart, but only a couple of meters apart.
I would like an option that if a pic occurs between 2 gps points and they are only x meters apart, interpolate the distance based on the time of the pic, where the user specifies x. I don’t happen to have photos at bounding gps points so that option doesn’t work very well for me.

Thanks,
:-)

— comment by Anonymous on May 21st, 2013 at 12:31am JST (1 year, 5 months ago) comment permalink

How granular is the reverse geocoding…does it return just city/state, or can it determine house-number and street-name from GPS coordinates and write this info to metadata (perhaps to the IPTC Image ‘Sublocation’ field)?

I’m looking for a plugin which will do basically what this website does (just automated): http://www.findlatitudeandlongitude.com/batch-reverse-geocode/

Thanks!

It’s very dependent on the specific location, both broadly (some countries have better coverage than others), and specifically, as in I’ve seen examples where the reverse data for one location is simply city/state, but another location 100m away has data down to the street number. I’ve seen no rhyme nor reason to it, but it’s a remarkably difficult problem to solve, so I’m appreciative of whatever Google offers. —Jeffrey

— comment by Stephen on May 25th, 2013 at 5:06am JST (1 year, 5 months ago) comment permalink

Love your plug-ins, but I’m having a problem entering location metadata, either using your plug-in, or the LR Map module. After I geoencode a set of images from a GPS track, I return to the Library module and the GPS location and elevation is entered correctly for each image, but the location metadata (city, state, etc.) is grayed out. I understand that I can accept that information by clicking on the name of the field and selecting the proper data. This is very tedious for large numbers of images. If I select a group of images together, the data disappears unless all of the images have identical locations. What I really want to do is accept all of the location data for a folder of images at one time. Is this not possible? Is everyone else doing this one image at a time? Running LR 4.4 on Win7/64 (in upstate NY, USA). Thanks.

I don’t care for Lightroom’s reverse-geocoding implementation, so I’m not familiar with the details. Rather, I use the reverse-geocoding that my plugin provides. It doesn’t have this grayed-out problem, so you might give it a try. But if you prefer the built-in way, the following might work: bring up the images in Library with the filter grouping images by city, then for each city, select one image and un-gray the location info. Then copy/paste the location metadata to all the other images for the same city. That might work. —Jeffrey

— comment by BruceJ on July 7th, 2013 at 4:36am JST (1 year, 3 months ago) comment permalink

I’ve happily used your Geoencoding plugin off and on over the past few years. But just now I’ve started trying to use it for the first time in a while, and every time I select “Geoencode selected photos from Goolge Earth” I get the error message “Can’t get location from Google Earth.” Same thing happens if I click the “from Google Earth” button in any part of the plugin interface.

This is with Google Earth running, and the location I want to use centered under the cross-hair.

I can copy locations from GE and paste them into the plugin dialog, but that’s more cumbersome than the way I used to be able to use the plugin.

Mac OS X 10.8.4; LR 5.0; Google Earth 7.1.1888

I’ve sent a recent log in case that helps.

Oh, and I’m visiting from Albany, California ;-)

Victor

I’ve never figured out why it just doesn’t seem to work for some folks. I’ve tested on the exact same kind of system (same OS and GE version) as ones where I’ve had reports that it doesn’t work, and it’s always worked for me. I’m sorry to say, it’s a mystery. )-: —Jeffrey

— comment by Victor Gavenda on July 28th, 2013 at 11:11am JST (1 year, 3 months ago) comment permalink

Jeffrey.
Really want to get your reverse geocoding to work. I used LR5 to analyse my GPX files and extract the Lat/Lomg coordinates for each photo. Now I install the plugin and run it, first for individual images (Geoencode Static location). Click Geoencode Image and it reports image successfully encoded. But I see nothing in the LR5 meta data location fields.

Have tried with LR Catalogue settings to enable reverse gecoding ON and OFF -makes no difference.

Is there some other setting I am missing to enable your plugin to write and commit the data to the image(s).

Thanks
David (UK)

— comment by David on August 6th, 2013 at 5:12am JST (1 year, 3 months ago) comment permalink

Follow up: LR5 Geoencode option OFF. I copy the GPS co-ords, then photo>clear location metadata to make sure all fields are empty. Then Plugin > Geoencode Static Location, paste in the copied location and Geoencode. GPS co-ords and map URL are written back to the photo meta-data, but still nothing in the location address fields. The Geoencode lookup worked, because info is displayed in the “Location Currently indicated” field in the Plugin.
Thanks again, David.

The built-in reverse-geocoding support is unrelated to the plugin’s. With the plugin, you must do it manually via the reverse-geocoding tab in the dialog. Personally, I use my plugin for tracklog geoencoding and all reverse-geoencoding; I use Lightroom’s Map Module for manual drag-n-drop geoencoding, and location browsing. —Jeffrey

— comment by David on August 7th, 2013 at 10:48pm JST (1 year, 2 months ago) comment permalink

Hi Jeffrey–
It seems like (about a year ago) there used to be a facility to create a KML file with a track and photos taken along the track. I used it to create a KML file of my vacation last year and I would like to do it again for this year’s vacation, but I can’t for the life of me find that now. Is it still in the plug-in, and if so, where to I enable it?
Thanks,
Dan

It’s in “File > Plugin Extras > View selected locations as KML in Google Earth”. If you don’t see it, visit the plugin in the Plugin Manager and “Configure Plugin Extras menu items”. —Jeffrey

— comment by Dan Roeder on August 20th, 2013 at 5:00am JST (1 year, 2 months ago) comment permalink

Hi Jeffrey – Great plugin! Many thanks!

A feature request, if it makes sense for others… this would turn a still-somewhat-manual process into an almost completely automatic one for me.

I wear an AMOD GPS logger almost every day, and have done for years. I copy the log files from it every week or two, and then generally go and geotag my recent photos, but I have a few thousand I haven’t yet caught up with!

The tracklogs all have nice predictable filenames based on the start of the log. And my camera is always set to GMT. It would be wonderful if, rather than having to select batches of photos and then go and find and open the matching logs, I could have it find the log file based on the photo’s timestamp… essentially, for each photo, go and load YYYYMMDD*.gpx files and try tagging from them.

Of course, I might be the only one for whom this would be useful… :-)

Thanks again,
Quentin

Just select all the photos and all the logs, and let the plugin deal with it. It may take a while if the amount of data causes your OS starts thrashing, but it should complete. —Jeffrey

— comment by Quentin Stafford-Fraser on August 25th, 2013 at 8:15pm JST (1 year, 2 months ago) comment permalink

Thanks Jeffrey – I’ll give it a go. I hadn’t had the nerve to feed it 1800 log files at once :-)

(I might do it one year at a time!)

— comment by Quentin Stafford-Fraser on August 25th, 2013 at 10:29pm JST (1 year, 2 months ago) comment permalink

Can you add catalan maps to the output ?
Like that :
http://www.icc.cat/vissir3/index.html?Y=4715414&X=333396&zoom=5&layers=Topogr%26agrave%3Bfic,Cims,vector,Marker&layers_opacity=1,0.8,1,1&historic=24&lang=eng
Thanks.

I added it, though it was a heck of a lot more difficult than I expected because, it turns out, they don’t take latitude and longitude; I had to translate to UTM. —Jeffrey

— comment by alain on August 29th, 2013 at 1:08pm JST (1 year, 2 months ago) comment permalink

Any plans to re-support location history from Google? Even though Latitude is dead, Android devices (and I’m guessing iPhone devices with Google+) will continue to report history to Google and it’s retrievable through Location History. Sadly there’s no API, but there’s this little nifty trick…

http://stackoverflow.com/questions/17589718/future-of-google-location-history-api

Not without an API, no, and perhaps not even with one, unless it’s popular enough. Sorry. —Jeffrey

— comment by Rubin Starset on October 2nd, 2013 at 10:59am JST (1 year ago) comment permalink

Since google cut off the v2 maps API, I’ve switched to using the v3 API for reverse geo-encoding. This seems to work great, except your plugin no longer seems to fill in the lightroom “Sublocation” field like it did with the v2 API. Is this lacking in the v3 API, or just something that was overlooked?

It looks like I broke it somewhere along the way, sorry. I just pushed a fix. —Jeffrey

— comment by Eric on October 2nd, 2013 at 11:19am JST (1 year ago) comment permalink

A big thank you for the “Added the ability for Windows users to set the keyboard-accelerator for plugin-extra items.”!

— comment by Newsky on October 6th, 2013 at 4:38pm JST (1 year ago) comment permalink

I just reverse encoded a batch of photos, and the Sublocation field is showing a “?”. Yes, I just downloaded the most recent update :). I can see a formatted_address field in the debugging info from Google, and this address is correct, but it seems it is not getting inserted into Lightroom.

If you could try doing that image again, then send the log, I’ll take a look. —Jeffrey

— comment by Paul Mensch on October 7th, 2013 at 8:32am JST (1 year ago) comment permalink

Hi Jeffrey,

I am wondering what information from the reverse geo-encoding output you use to populate the location, city, state and country fields. Is it possible to make this user configurable

Greetings from Berlin
Jacques

Configuration might be a way to go, but it probably depends more on the data Google has for a location than personal style, so configuration would help for only those who geocode in a small area, I think. But for the record, as of the most recent release (20131022.209), the location is taken from the first from among: point_of_interest, airport, park, subpremise, premise, establishment, street_address, train_station, transit_station, bus_station, colloquial_area, neighborhood, address +route, and finally route. —Jeffrey

— comment by Jacques on October 8th, 2013 at 5:06am JST (1 year ago) comment permalink

The OSGB36 conversion no longer works (the URL of the online tool has changed).

Perhaps you could add an option to use GPSBabel for the conversion, for example:

echo -e “bng\nSU 19000 19000″|gpsbabel -i unicsv -f – -o csv -F -

Thanks for the heads up. I’ve just pushed a new version that now handles this internally. —Jeffrey

— comment by Dudley on October 19th, 2013 at 12:27pm JST (1 year ago) comment permalink

Hi Jeffrey,
When I try to load a local KML file, the plugin tells me :
“That’s a network KML file… the raw KML data URL will be inserted into a network-KML entry for you”

I use Lightroom 4.4. The KML file was in Google Earth as explained in your tutorial.

Am I doing something wrong ?

JC from Paris, France

The KML file you downloaded is one that doesn’t actually include the polygon data… it just has a URL that references the data in Google’s cloud. The plugin is telling you that it’s isolated that cloud URL and put it into one of the network-KML slots, where you can give it a name and such, and download the polygon data now and from time to time in the future if you make changes… —Jeffrey

— comment by Jean-Claude on October 30th, 2013 at 4:55am JST (11 months, 23 days ago) comment permalink

I have a lot of photos which I took using a pair of bodies, which I used alternately (one had a long lens on it, the other short). Only one of the bodies was adding GPS coordinates to the raw files. But the cameras had more or less synchronised clocks. Is there any way to use the location data from the GPS-enabled pictures in order to estimate locations for the pictures taken with the other body?

For example, extract a tracklog from one set of photos and then use that tracklog to assign estimated locations to the other set of photos? I can see that the plugin already supports the second thing, but not the first thing.

You could export the geoencoded photos as a kml file (File > Plugin Extras > View selected locations as KML in Google Earth), then use some other utility (such as GPSBabel) to convert it to a tracklog file, then apply that with the plugin. —Jeffrey

— comment by James Youngman on November 27th, 2013 at 11:25pm JST (10 months, 24 days ago) comment permalink

Hi Jeffrey! I have a question and a suggestion:

Question: In your reply to Jacques on 8 October, you indicated that the sublocation is taken as the first from among a bunch of items. I prefer to use neighbourhood or colloquial area for sublocation, but I have been getting a lot of sublocations with street addresses or other extraneous information, which I then have to manually edit. Based on your answer, I am assuming that if any of these other items is available, including street address, it is filled in rather than neighbourhood or colloquial area. Is there any way (or could this feature be added) to give neighbourhood and colloquial area priority over other items?

Suggestion: Is there any possibility of adding a “View location in Apple Maps” option that would open the image location in the Maps app on OS X 10.9?

I’ve addressed both issues as of version 20140123.214. —Jeffrey

— comment by Richard Drdul on December 26th, 2013 at 11:20am JST (9 months, 26 days ago) comment permalink

Hi,
I recently switched from Geosetter and Xnview to Lightroom, and this plugin seems to add several missing functions to LR for geocoding.
But I don’t understand how you can use it for reverse geocoding in Japan, Google data are useless.
I just tested with one photo of Sanzen-in, Kyoto and your plugin just put Kyoto everywhere, but Geosetter and LR Map put a more close Oohararaikouinchou. I think that both use geonames.org services, but with different way of handling the data.
Therefore, I must still use LR Map for reverse geoencoding (when I will figure out how to save the auto tags).
It would be so much better if your plugin could use geonames.org.
Especially, the Wikipedia webservice would be awesome (http://www.geonames.org/export/wikipedia-webservice.html#findNearbyWikipedia) because the Wikipedia title will be in most case the best location for well know places (with the photo I tested, it gives me “Sanzen-in”, which is perfect).
I hope that such advanced features would be available soon in your plugin.

Unfortunately, that won’t work because the searches must be polygon based, with the source data defining an area represented by a given name. The Wikipedia search merely identifies nearby points, and the the location you’re actually in may well be described by a point that’s not the nearest, such as if you’re near the border between locations.

I’ve yet to document it, but you can use the online KML support of the plugin’s “Reverse Geo” tab to refer to a map of locations you keep for yourself (or share with others, such as this map of Kyoto locations I’ve been keeping; to use in the plugin, refer to its KML via this link). —Jeffrey

— comment by PBY on December 31st, 2013 at 7:47pm JST (9 months, 21 days ago) comment permalink

Better info on above request – found info on what photosphere specific metadata needs to be added. halfway down on this page lists some of the specific data needed-
http://exsight360.com/blog/how-to-upload-non-android-360-panoramas-to-google-maps/

Thanks!

— comment by dang on January 29th, 2014 at 10:01am JST (8 months, 24 days ago) comment permalink

Hi, Jeffrey,
I would like to view my pictures on the TV screen. Because the LR slide show produces .mp4, 1080 p, only, I prefer to export 100% .jpegs to an external HDD. (The TV can do a slide show, but doesn’t handle .exe). Is there any way to export the title of the picture with the .jpeg and view both on TV? The LR slide show does show picture and title, but in lower resolution. And it would need a connection PC – TV (15 m hdmi cable…..)
It’s for private use, so I don’t need any publishing service…
We appreciate your work and your help,
Robert, Vienna, Austria

Perhaps consider using this plugin to imprint the title on the image as a watermark? —Jeffrey

— comment by Robert on February 4th, 2014 at 7:22pm JST (8 months, 17 days ago) comment permalink

Hi,

I don’t understand the requirement for area search, because in most cases, the nearest Wikipedia point would be the real subject. I prefer to have a function giving me the real name (temple, church, museum…) in 95% of cases than to always have just at best a street address which don’t add any information for touristic photos.

Anyway, as I didn’t use Lua since years, I quickly made a standalone C# program which fills my needs.

— comment by PBY on February 9th, 2014 at 7:35pm JST (8 months, 12 days ago) comment permalink

Hello Jeffrey,

It appears that the iso country code is no longer populated when using the reverse geo option in your geoencoding support plugin. Everything else works as before. Could this be a side effect of you rewriting the code for this tab?

Regards
Jos van der Woude

Yeah, sorry about that. Fixed as of version 20140324.218. —Jeffrey

— comment by Jos on March 2nd, 2014 at 11:12pm JST (7 months, 19 days ago) comment permalink

Dear Jeffrey,

first of all: Thanks for your brilliant plug-in. As far as it concern me, it solves nearly all of my requirements.
The only thing I realize so far is that the ISO country code is not filled when I use the reverse geoencoding dialog. Is there any way to get this working?
Thank you in advance,
kind regards,

Connor

Fixed as of version 20140324.218. —Jeffrey

— comment by Connor on March 23rd, 2014 at 10:08pm JST (6 months, 29 days ago) comment permalink

Hi Jeffrey,

I found two bugs in version 20140324.218:
1. Results from the local KML file are not applied to the picture after geoencoding unless the “Enable enhanced debug logging” is checked. When it was unchecked I could see from the log that a result was found in the KML file, but that result was not used and the picture ended up with data from Google Places.
2. Not sure this is a bug or whether Google changed their addressing: Configuring network KML from a Google map, eg. the map of Kyoto you posted a link to earlier (http://mapsengine.google.com/map/u/0/kml?mid=zxFAcZswpgLk.k7_5khe4xt6U) fails. The plugin states that: “That’s a web page, not a network KML url” when trying to fetch data.

Thank’s for your dedicated work!

Kind regards,
Øystein

About #1: Good find! I’ve just pushed a fix, thanks. About #2, pasting the link cited in this comment into the plugin’s “Network KML URL” field is working for me, so if it’s not working for you, please send a log. —Jeffrey

— comment by Øystein on March 27th, 2014 at 8:07pm JST (6 months, 25 days ago) comment permalink

Hi there Jeffrey,

First of all, big thanks for creating this awesome plugin – I’ve been using it since 2011 with LR3 and it’s met all of my location needs.

I’m now using LR5 and haven’t had to use this plugin for a while now. (Due to the intro of location in LR4 and having inbuilt GPS in my cameras)

I’ve recently tried to export some of my old holiday photos which were tagged using the plugin in LR3, but even selecting the injector in the export, no GPS data is exported. I checked the geoencoding metadata and there is nothing there except for the Map field which has a google maps URL and the Speed and Bearing fields. The Map Location field is empty.

Any idea where the GPS coordinates have gone to? Or has this been data lost forever?

Thanks,
Steve

Check the “Metadata” section of the export dialog… I’m guessing that you have the location stuff excluded. I’m also guessing that you’re still using the plugin’s “GPS injector” post-process action, which you no longer need in Lr5. —Jeffrey

— comment by Steve on April 13th, 2014 at 7:22pm JST (6 months, 8 days ago) comment permalink

Jeffrey,
Having a problem with LR 5.4 windows 64bit, and Geoencode version 20140418.221
I select multiple images in LR, and then go geoencode, and it says that only one image is selected.
Thanks for any help :-)
Patrick

Perhaps you’re not in Library when you do it? Outside of Library, the selection is often reduced to the one currently-visible image. —Jeffrey

— comment by Patrick Lynch on April 19th, 2014 at 12:13pm JST (6 months, 2 days ago) comment permalink

Jeffrey, – Enhancement Request…
Right now, it takes multiple passes for a directory to do all of the geo work
-One pass to merge track log to photos (or I have used LR maps if all at the same location)
-One pass to reverse geo encode
-One pass to add elevation info to everything
Is there a way that I can have elevation info added at the same time I do the reverse geo and not need a separate pass?

Thanks,
Patrick

That’s a good idea… I’ve added it to the todo list. —Jeffrey

— comment by Anonymous on July 29th, 2014 at 5:01pm JST (2 months, 23 days ago) comment permalink

Hi Jeffrey
I was wondering if you have any instructions on how to use the tracklog from a Canon GP-E2 GPS?
Thanks
Steve

It has a bug and produces incorrect logs, but modern versions of GPS Babel can read them. Using that alone (or with my plugin) should do it. —Jeffrey

— comment by Stephen Dyer on August 22nd, 2014 at 9:25am JST (2 months ago) comment permalink

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 (1 month 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 (3 weeks 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 (2 weeks, 4 days 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 (2 weeks, 2 days 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.

More or less plain text — see below for allowed markup

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

Subscribe without commenting