· Photographer's Toolbox
· alloy photo
· John Beardsworth
· Capture Monkey
· lightroom-plugins.com
· Adobe Addons
gps-20231011.357.zip
· FAQ
· Version History
· Update Log via RSS
· Installation instructions
· “Donationware” Registration Info
· More Lightroom Goodies
· All-Plugin Update Log via RSS
· My Photo-Tech Posts
· My Blog
This plugin for Adobe Lightroom Classic adds many new location-based features to Lightroom, and enhances or replaces some features Lightroom already has, including:
|
This plugin works in Lightroom Classic, and older versions as far back as Lightroom 3, though some features depend on the version of Lightroom.
The same download works for both Windows and Mac. See the box to the upper right for the download link (in orange) and installation instructions.
Table of Contents
This long page of documentation gives an overview of many of the plugin's features:
Introduction
Once installed, most of the plugin's features are available via the “File > Plugin Extras” menu:
The plugin's menu items are highlighted in red.... you can do quite a bit. (If the number of items is a bit overwhelming, you can configure the plugin to omit the menu items you don't need.)
The yellow arrow in the screenshot highlights the plugin's main menu item, “Geoencode...”, which brings up the Geoencoding dialog shown below. With it you can geoencode and reverse-geoencode your photos in various ways.
Personally, I use this geoencoding dialog so much that I assigned a keyboard shortcut to it. You can assign your own keyboard shortcuts, as described here.
The Main Geoencoding Dialog
This plugins's geoencoding dialog looks like this:
It has tabs for distinct tasks, with the dialog first opening up to the “Tracklog” tab, as shown above. Several tabs provide different methods to geoencoding photos (to assign latitude and longitude to photos), while other tabs provide for reverse geoencoding photos (filling in the city/state/country/location based upon the latitude and longitude).
The Tracklog Tab
Lightroom has tracklog support built in, but this plugin's tracklog support is far superior:
- In addition to the latitude and longitude, this plugin actually fills in the altitude from the tracklog, which Lightroom's built-in support inexplicably ignores.
- The plugin adds “speed” and “bearing” metadata to each image.
- The plugin can automatically add map links (to a variety of online mapping services) to the metadata for each image, easily accessible via Library's “Metadata” panel (especially if you use my metadata-viewer preset builder to include the map link in the default metadata view Lightroom shows for each photo).
- This plugin can handle multiple tracklogs at once.
- This plugin has no built-in limit on the size of the tracklogs.
- The plugin can handle almost any kind of tracklog format (not just GPX like Lightroom's built-in support) via automatic conversion with gpsbabel. The plugin also has built-in support for the incorrectly-formatted tracklog files produced by some popular phone location-tracking apps.
- The handling of timezone offset is clear and actually works.
- You can easily compensate for a camera clock that was off a bit.
- You control the “fuzziness” for how close in time a photo can be affected by a tracklog data point.
- You can easily view the tracklog in Google Earth.
- You can automatically apply custom reverse-geoencode data as you apply the tracklog, so (for example) a photo taken at a park you frequent automatically gets the name of the park filled in to the “location” metadata item, as well as the city/state/country metadata items.
As of version 20161016.270, you can have the plugin try to fill in for certain kinds of gaps in a tracklog.
The idea is that if you (for example) enter a restaurant for an hour, you might end up with an hour's gap in the tracklog, bookmarked by datapoints near the front door. In this case, a photo of your dessert taken half way in wouldn't normally get processed by the plugin, but using this “fill in pauses” feature set to (say) two hours and 100 meters, photos taken inside will at least get geoencoded to the entrance location. It's not ideal, but perhaps better than nothing.
On the other hand, if you (for example) entered a subway and rode a long distance to where you had desert, then returned to emerge out from the same subway entrance, you'd not want to use this feature because the where you took the photo would be a great distance from the gap locations (the entrance and exit of the subway), even though those two locations are themselves close to each other.
This plugin supported tracklog geoencoding for years before Lightroom supported any kind of geoencoding. (I've geoencoded all my photos with it since 2008; Lightroom didn't get built-in geoencoding until 2012.) The passion and care I have for geoencoding comes out in the many features this plugin has.
The Static-Location Tab
The second tab of the Geoencoding Dialog is “Static Location”:
Here you can type in a latitude/longitude, cut-n-paste the URL from an online mapping service to grab the location currently shown there, import the current location from Google Earth, or import the location from the already-geoencoded most-selected image (which is useful for copying a location from one image to another or others).
This method of geoencoding was particularly useful before Lightroom added the Map Module in Lr4, but it can still be useful when you need to cut-n-paste a location from outside of Lightroom. The “Help” tab gives examples of some of the many ways you can indicate a location.
Note: the ability to import the current view location of Google Earth is spotty, and for mysterious reasons it simply doesn't work for some folks. I've spent considerable time trying to figure it out, but have been unable to.
The Between-Points Tab
The next tab of the Geoencoding Dialog, which you'll likely never need, is “Between Points”:
This tab allows you to apply locations two photos between two points as if you were moving at a constant speed between them. It's useful only in fairly specific cases.
Reverse-Geoencoding Tab
The next tab of the Geoencoding Dialog is the powerful “Reverse Geoencoding” tab:
(this is an old view of the dialog; the plugin now has a tab to swap between Google and OpenStreetMap)
This is far superior to the reverse-geoencoding support built into Lightroom, so I always leave Lightroom's reverse-geoencoding support turned off (via the checkbox in the “Metadata” tab of Lightroom's “Catalog Settings” preferences dialog).
The plugin can reverse-geoencode via both Google and OpenStreetMap, though in order to use Google, you must create a developer's API key, and enter that into the plugin in the Plugin Manager. (The egregiously-complex steps needed to create the Google API key are beyond my ability to explain as of yet, sorry.)
The plugin's reverse geocoding is much smarter than Lightroom's built in reverse geocoding, about how it interprets and formats the results. Some of the “smarts” are exposed via options in the left half of the reverse-geoencoding tab.
In particular, the plugin can be configured to set the “location” metadata for each photo based upon the kind of data that Google returns, with priorities for each kind of name set to your liking.
The right half of the tab shows my personal settings for a powerful feature that Lightroom lacks completely: the ability to specify your own personal reverse-geoencoding locations. For example, on a private Google Maps map that you maintain in your browser, you might draw the outline around your kid's school and mark it with the name of the school. Then, when geoencoding with the plugin (or explicitly reverse-geoencoding with this tab), the name of the school will be inserted into the “Location” metadata for images located within the outline you drew.
The One-by-One Tab
The next tab of the Geoencoding Dialog is the sort-of-odd “One by One” tab:
This tab allows you to bring up a dialog where you can scroll through images one by one, geoencoding and reverse-geoencoding in various ways. It can be a bit kludgy because of the limits Lightroom places on a plugin's ability to create a dialog, but the plugin goes to great lengths to make it useful.
It's not a tab one needs for most workflows, but it can be convenient at times.
The Etc. Tab
The “Etc” tab has a few odd and ends:
This tab lets you do a few random extra things, including configure the kind of mapping URL gets associated with images geoencoded by the plugin (so that from Library you can just click on the link and see the location in your preferred mapping service).
The same mapping-site URL configuration applies to the “View Location At Google” and “View Location At Yahoo!” items in the “File > Plugin Extras” menu.
Extra Configuration and Keyboard Shortcuts
Besides the many configuration options in the tabs shown above, two overall configuration items are in the plugin manager, as highlighted by the arrows in this screenshot:
The yellow arrow highlights an option to use a smaller, terse geoencoding dialog. This may be required on systems with very small screens, as the default dialog may be too big to fully fit such systems.
The red arrow highlights the button that brings up a dialog allowing you to configure the items that appear in the “Plugin Extras” menu (as illustrated by the first screenshot on this page). The many “View location at...” items can be a distraction if you'll never use all of them, so this dialog allows you to omit ones you don't need from the menu. Here's what the dialog looks like on Windows:
The items at the bottom allow you to configure the plugin to work with any KML-handling app. The most notable KML-handling app is Google Earth, support for which is built in various way via items toward the top of the list.
The box at the left of each item appears only in the Windows version of the dialog, and allow you to set the keyboard shortcut letter for that item. See this link for more on how to set keyboard shortcuts under Windows.
It's much easier to set keyboard shortcuts on a Mac, and you don't need anything in this dialog to do it; scroll down half way on the same link for instructions.
Note: in order for changes to take effect after updating settings in this dialog, you have to reload the plugin (via the button in the plugin manager), or restart Lightroom. Also, in order to update settings in this dialog to begin with, the plugin must be able to write to its own code, which may not actually be possible depending on the folder permissions for wherever you've saved the plugin.
Inspecting Your Location Metadata
Lightroom's built-in Map Module is great for viewing your photos on a map. Adding to that, this plugin provides ways to view a photo's location in Google Earth and at 20+ online services. But the plugin provides more than just a location on a map... if you geoencode via the plugin's Tracklog tab, you also get altitude, speed, and bearing.
The plugin includes a convenient “Geoencoding” preset for the “Metadata” panel in Library and Map, as illustrated here:
It can be inconvenient to toggle between your normal metadata view (“Default”) and the Geoencoding view, so you may want to use my Metadata-Viewer Preset Editor plugin to select the metadata items you personally find useful, in the order you find them useful, with the names you find useful.
As an example, here's the view that I personally use in my day-to-day Lightroom work:
It includes plugin-specific items from this Geoencoding-support plugin, and from my Creative Commons plugin. It also renames many fields to match how I use them in my workflow, and orders and groups things to my liking.
Fast Whole-Catalog Proximity Search
If you photograph in the same areas over the years, it can be very nice to quickly find other photos in your catalog from earlier visits to the same general area. The plugin's “File > Plugin Extras > Geoencoding Support > Fast Full-Catalog Proximity Search” menu item brings up the dialog:
which then creates a collection for you and fills it in as appropriate:
On a Mac this is extremely fast (100,000 images can be searched in a few seconds). On Windows it takes a couple of minutes, but that's still much faster than trying to do it with Lightroom's native support.
For more info, see “The Joy of a Fast Photo Proximity Search in Lightroom”.
Viewing Photos in Google Earth
Via the “File > Plugin Extras > Geoencoding Support > View selected locations as KML in Google Earth” menu item you get this dialog:
You can include photos and/or tracklogs (or neither, to just one location marker per photo). It creates a KML or KMZ file that you can share with others. The tracklog and some of the photos from “My Mt. Hiei Climb Challenge 2014” outing appear in Google Earth like this:
You can see the tracklog in red, with thumbnails appearing where I took photos along the route. I'd clicked on one photo to open it up and show a larger version, along with some data about the photo.
The specific data about the photo to be shown is configured in the dialog's “Custom photo description” boxes, where you can specify each photo's title and caption be created using its own metadata (via the template tokens that my plugins support).
Other Google Earth Interaction
The “File > Plugin Extras > Geoencoding Support” menu contains two other Google Earth features:
Pinpoint location in Google Earth
Sends the location of the currently-selected image to Google Earth.
Geoencode selected photos from Google Earth
A self-explanatory item, this takes the current location at the center of your Google Earth view and applies it to the currently-selected image(s) in Lightroom. This is less valuable now that Lightroom supports drag-n-drop in the Map Module, but it may be useful if you prefer Google Earth to the Google Maps view that Lightroom uses. (Unfortunately, this feature doesn't seem to work for some Windows users.)
See “A Better Center-Crosshair Target for Google Earth” for something that makes interacting with specific locations in Google Earth much easier.
View Location At....
The “File > Plugin Extras > Geoencoding Support” menu contains many “view location at” items that send the location of the currently-selected image to an online mapping service, including:
- View location at Google Maps
- View location at Yahoo! Maps
- View location at Yahoo! Japan Maps
- View location at Apple Maps
- View location at Flickr
- View location at Panoramio
- View location at 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 Lr10 to Lr11 de-registers the plugin in the upgraded version, so if you want to maintain registration, a new ($0.01 if you like) registration code is needed in the upgraded version. It makes for a hassle every couple of years, I know. Sorry. See this note for details.
For details on plugin registration and on how I came into this hobby of Lightroom plugin development, see my Plugin Registration page.
Old Support Under Lightroom 2 and Lightroom 3
This section does not apply for Lightroom 4 and later
As described on the initial-release announcement in 2008, the plugin maintains “Shadow” GPS data, separate from any GPS data that may or may not be held in Lightroom's library database. The plugin has to do this because Adobe didn't add the ability for a plugin to update a photo's latitude and longitude until Lightroom 4, so for prior versions the plugin must maintain its own mapping.
The shadow data is recognized and used in a variety of situations, but not in others, so it's important to understand which is which.
These do understand the shadow GPS data:
- Any image export in which the “Shadow GPS Injector” is enabled.
- My GPS Proximity Search plugin.
- Tim Armes' LR/Transporter plugin.
- My “Export to..” plugins (for Zenfolio, SmugMug, Flickr, Picasa Web, and Facebook).
- The “Geoencoding...” metadata-viewer preset.
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
)
| 20231011.357 |
CachedImagePreviewsFile token. Upgraded to the embedded copy of ExifTool to version 12.67. |
| 20220627.356 | Update the embedded version of sqlite3 for Windows. |
| 20220619.355 |
Updated a bunch of the "View location at..." URLs to use HTTPS, where supported. Added "View at Apple Maps (via DuckDuckGo)". |
| 20220606.354 |
Removed a bunch of debug logging that was slowing down the LUA token.Newline Upgraded to the embedded copy of ExifTool to version 12.42. |
| 20220210.353 | Maybe work around a Windows XML-parsing bug. |
| 20220120.352 |
Added the WEEKNUM token, along with DAYNUM, weeknum, and daynum. Whack-a-mole with PayPal's random changes. |
| 20211219.351 |
Warn when PayPal seems to have given a bogus code in the web-confirmation page. |
| 20211018.350 | Handle "between two endpoints" geoencoding when the two endpoints are almost exactly the same point. |
| 20210802.349 |
Fixed a problem with the KML output. Fixed that the Province template token did not respect the plugin-specific geo-privacy settings. Upgraded to the embedded copy of ExifTool to version 12.25. Fixed an issue with the {Newline} token, and added {Comma}, {Hyphen}, and {Space} for good measure. Fixed a problem with filters on the {Keyword} token. |
| 20210415.348 |
Added 'separated by' to the People token. Added the ImageViewDirection and ImageViewBearing tokens. Reworked the Keywords token to better accept filters. working around 'constant table overflow' error |
| 20201103.347 |
Added the PF filter to turn typographic fractions into plain-ASCII fractions. |
| 20201028.346 |
Rebuilt zip. |
| 20201018.345 |
Updates for Lr10. |
| 20200928.344 |
Added the ability to write the "Speed" field in mph and knots. Added the SpeedKnots token. |
| 20200809.343 |
Worked around an "unknown key captureTime" error. |
| 20200731.342 |
Added the {PlusCode} and {GeoHash} tokens. |
| 20200330.341 |
Removed some of the "view at..." services that no longer seem to exist. Added some of the "view at..." services to the "set map urls..." configuration. |
| 20200313.340 |
Added "View Location at OpenTopoMap" Added the ability to save one's Google API key in other than the system vault, to try to get around these inexplicable "CryptUnprotectData" errors some folks on Windows encounter. |
| 20200308.339 |
Setting elevation from Google services sometimes didn't work the second time. |
| 20200225.338 |
Fix a crash with reverse Geocoding. Work around a Windows bug related to canceling out of the registration dialog. |
| 20191204.337 |
A blind change that might help get around a mysterious Lightroom "CryptUnprotectData" error that some Windows users see. I'm not sure what part of the plugin might be related to that error, but taking an educated guess, and if correct, trying to at least mitigate the effects of the bug. Make the tracklog-loading status updates a bit more verbose. Added some extra debug logging to note whether the plugin is enabled. |
| 20191118.336 |
Added some extra debug logging to try to track down a problem. |
| 20191029.335 |
Upgraded to the embedded copy of ExifTool to version 11.70. |
| 20190925.334 |
Added "View at peakfinder.com". Updated the OpenStreetMap reverse geocoding to get around a bug they have that renders the "state" incorrectly./p> Added the {RelativeFolder} token. |
| 20190903.333 |
About the custom Google API key, try to notice when it's invalid because billing hasn't been set up, and report that to the user. Added the LensInfo template token. Updated the Exposure token to allow customization. More token work: added {Urls}, and updated {ISO} and {Copyright} to allow customization. |
| 20190817.332 |
Updated links to geoportail.gouv.fr |
| 20190815.331 |
Updated the OpenStreetMap reverse search to provide more detail. |
| 20190810.330 |
Fixed the SST1 and SST2 tokens. |
| 20190731.329 |
Updated the PublishCollectionName token (and CollectionNames and CollectionFullNames) to remove the MIRROR: prefix from the name that mirrored collections within my Collection Publisher plugin automatically get. |
| 20190708.328 |
Added functions uc(), ucFirst(), lc(), and lcFirst() to the LUA token. |
| 20190622.327 |
Fixed a problem related to template tokens and photos without capture times. Upgraded to the embedded copy of ExifTool to version 11.50. |
| 20190402.326 |
Updated What3Words functionality. |
| 20190402.325 |
Fix a typo. |
| 20190331.324 |
The "Fill in location name from OpenStreetMap data" option was not being honored. Added the GPSCoords token. Report on the number of remote calls to Google/OpenStreetMap done during bulk reverse geocoding. Added the ability to set a metadata field with the What3Words location of a photo. |
| 20190323.323 |
Fix an "Unknown key: captureTime" crash. |
| 20190317.322 |
Upgraded to the embedded copy of ExifTool to version 11.30. Updated the keyword-related tokens to accept standard filters. Work around a bug that sometimes causes plugins to be disabled when starting Lightroom via clicking on a catalog file. |
| 20190219.321 |
Better handling of errors from OpenStreetMap. |
| 20190131.320 |
Added the ability to use your own Google API key. See the plugin manager. No documentation yet. |
| 20190124.319 | Fixed the "ReverseOpenStreetMap:342" error. |
| 20190106.318 |
Added "Direction" (the direction the camera is pointing) to the plugin's built-in field display set. |
| 20181226.317 |
Added the TempC and TempF tokens. Well, an era has come to an end. Google has started to charge for services that used to be, very kindly of them, free. Now, the charges for the reverse-lookup feature are hundreds of dollars a month, and I just can't sustain that. They do give a certain amount of free credit per month, so I'll try to turn on the reverse-lookup feature at the start of each month, but it'll get turned off once the free credit has been used. Hopefully in the near future I'll be able to add a way for individual users to use their own billing account at Google with the plugin. |
| 20181212.315 |
Fixed the "Fill Elevation from Google Mapping Services" function. It turns out that I have to pay for this now, so I'll have to disable it if it becomes onerous. |
| 20181126.314 |
Updated catalog database-access routines to work better in older versions of Lightroom. --Added the PEOPLE variable to the LUA token. --Fixed a problem with the SpeedKPH token. |
| 20181025.313 |
Updated the "View at Bing" stuff to work with Bing's current maps. |
| 20181015.312 |
Updates for Lr8 (Lightroom Classic CC Version 8). Added the special PP() function to the {LUA} token. Added hierarchical options to the Keywords token. Re-enabled the "Guess Timezone" feature (in the "Etc" tab) after Google shut it down for free accounts. I'll now be charged for it, so if it gets too much use, I'll have to shut it down, sorry. Fixed an "attempt to index a nil value" error that I introduced in the previous version (sorry). |
| 20181012.311 |
During reverse geocoding, the plugin had been filling in location names from Google even when not requested. Highlight the "Bulk Reverse-Geocode Selected Images With Settings Below" button, which might otherwise feel visually hidden at the top of the dialog. |
| 20181011.310 |
Try to work around a Lightroom bug related to photo timezones and how Lightroom handles accessing plugin data. Added some extra debug logging. |
| 20181004.309 |
Upgraded to the embedded copy of ExifTool to version 11.01. Added the 'nicknames' modifier to the {People} token. Added the SST1, SST2, and SS3 tokens to the template tokens that the plugin understands. |
| 20180906.308 |
Input fields that accept a location can now handle a What3Words code and a Plus Code. |
| 20180902.307 |
Fixed a problem with the input box for the fast full-catalog proximity search. |
| 20180804.306 |
Try to avoid having unexpectedly-long error messages create too-big a dialog. |
| 20180731.305 |
Fixed the "CAN'T YIELD IN LOCATION GROKER" crash. |
| 20180718.304 |
Added support for displaying and accepting What3Words codes. Upgraded to the embedded copy of ExifTool to version 11.01. Updates to handle new Google usage-quoata rules. Clicking on the version number in the Plugin Manager now copies version info to the clipboard Updated the PublishCollectionName token to allow numeric arguments along the lines of the CollectionName token. Added the folowing template tokens: {home}, {desktop}, {temp}, {pictures}, {documents}, {IptcDateTaken} Added the 'PCH' variable to the {LUA} tag. |
| 20180426.303 |
Fixed a bug when 'Token Examples' invoked in certain situations. Moved the actually-do-it button from the bottom of the reverse-geocode tab to the top. |
| 20180409.302 |
Try to make the plugin-extras-config dialog fit on smaller screens. |
| 20180322.301 |
Added Plus Codes to the list of location formats the plugin understands. |
| 20180309.300 |
Fixed an issue with KML files and ampersands. Upgraded to the embedded copy of ExifTool to version 10.82. Added a bunch of token filters: F2D F2S F2X B2D B2S B2X S2X A2D A2S A2X |
| 20180218.299 |
The values for 'bearing' that the plugin writes had been in the range of -180° to +180°; now it's properly in the range of 0° to 360°. |
| 20171113.298 |
More bullet-proof parsing if user KML file. |
| 20171105.297 |
Handle temperature interpolation better. |
| 20171019.296 |
Oops, more Lr7 stuff. |
| 20171019.295 |
Updates for Lightroom 7 |
| 20171012.294 |
The "photo between lines" feature of the KML-output stuff didn't respect all configuration options. Better handle some character-encoding issues related to template tokens. Allow the "If Exists" feature of Templat Tokens to work with the PluginProperty token. Update registration support to handle a stupid bug at PayPal that PayPal refuses to fix )-: |
| 20170912.293 |
Removed the "view at" for Skogoglandskap.no, and added norgeskart.no and nibio.no |
| 20170904.292 |
Try to make database access (for fast full proximity search) more robust. |
| 20170710.291 |
Fixed a bug introuded the other day in template tokens, related to Windows filenames. |
| 20170621.290 |
Added the Newline template token. Enhanced the FolderName token Upgraded to the embedded copy of ExifTool to version 10.55. Added the "only if it has a value" feature to template tokens. |
| 20170520.289 |
Perhaps fixed a complex bug with the "Between Points" feature related to timezones differing between the photos and the local computer. |
| 20170513.288 |
Fixed the KML output when a filename had an ampersand in it.
|
| 20170507.287 |
Previous update broke the plugin in older versions of Lightroom, so fixed that. Added bezel after fast full proximity search, and automatically switch to grid mode. |
| 20170429.286 |
Added a momentary "Location copied to clipboard" bezel feedback when that function is invoked. Upgraded to the embedded copy of ExifTool to version 10.50. |
| 20170328.285 |
Woo-hoo, found a way to make the "Fast Full-Catalog Proximity Search" work again on OSX, *and* figured out how to make it work for Windows. |
| 20170309.284 |
Upgraded to the embedded copy of ExifTool to version 10.40. Added the following tokens to the template tokens that my plugins understand: Artworks, ArtworkTitle, ArtworkCopyright, ArtworkSource, ArtworkCreator, ArtworkDateCreated, ArtworkInventoryNum |
| 20170307.283 |
Fix name-nesting issue with the KML preset dropdown. |
| 20170226.282 |
Try to handle French lat/lon |
| 20170220.281 |
Fixed a geoencoding bug WRT sparce tracklogs. |
| 20170209.280 |
Updated links to geoportail.gouv.fr |
| 20170208.279 |
Added "ISO8601Date" to the template tokens that my plugins understand. Now read/saves temperature from tracklogs, if present. Google reverse geo seems to now be returning the state/province as a "point of interest" and as an "establishment", which seems incorrect (I've logged a bug here), so now these are ignored. Added the ability to also set the IPTC-extension fields "Location Created" and "Location Shown". |
| 20170122.277 |
Removed "View at Yahoo! Maps", 'cause it no longer exists. |
| 20170113.276 |
Added the “Copy location to clipboard” plugin-extras menu item. Removed the Panoramio one. Switch the log-sending mechanism to https. |
| 20161206.275 |
Add some debug logging to "dismiss dialog when finished". |
| 20161129.274 |
Be less aggressive about trying to avoid having to use a scrolling region. They're ugly, but allow stuff to fit on the screen. The "Help" tab had gotten dorked on Windows. |
| 20161126.273 |
Tidy up some reverse-geo results within the UK. Added the ablity to use OpenStreetMap for reverse geocoding. I likely broke things splicing this in. Added Weekday, Wday, weekday, and wday to the list of template tokens that my plugins understand. Upgraded to the embedded copy of ExifTool to version 10.36. Removed the old "Shadow Injector" post-process filter from Lr6 and beyond. It's used in Lr2/Lr3 to geoencode exported photos. Lightroom finally caught up with me in Lr4 and supported a native way for the plugin to do this, so it's not needed from Lr4. But in Lr4/Lr5 keep a spot for it to give folks time to gracefully upgrade their export presets and publish services. Finally get rid of it in Lr6 to reduce the accumulation of clutter. |
| 20161020.272 |
Fixed a bug with the keyword tables in the LUA token. |
| 20161017.271 |
Fix a bug in the new tracklog stuff. |
| 20161016.270 |
Added automatic gap-filling to tracklog geoencoding. Added the following tokens to the templates that my plugins understand: FileModYYYY, FileModYY, FileModMM, FileModDD, FileModHH, FileModMIN, FileModSS, FileYYYY, FileYY, FileMM, FileDD, FileHH, FileMIN, FileSS. Upgraded to the embedded copy of ExifTool to version 10.26. |
| 20160624.269 |
Added the {FilenameNumber} token to the templates that my plugins understand. Upgraded to the embedded copy of ExifTool to version 10.20. |
| 20160511.268 |
Extra debug logging to figure out a screen-size issue. |
| 20160507.267 |
Fixed a font issue. |
| 20160415.266 |
Brought the list of languages supported by the reverse-geocoding stuff in line with what Google now supports. |
| 20160320.265 |
Updated the fast full-catalog proximity search dialog to allow a location to be pasted in, even if a geoencoded photo is selected. Upgraded to the embedded copy of ExifTool to version 10.10. |
| 20160118.264 |
Support the lat/lon format now given by Google Earth's "Copy View Location" (e.g. "35.024151° 135.762123°"). Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time. |
| 20151224.263 |
When attempting the fast full-catalog proximity search, try to detect when it fails due to the database being locked. Fixed an issue in the reverse geoencoding whereby an error could pop up if the network was down. Added ChildOf and DescendantOf filters to the {Keywords} and {KeywordsAll} template tokens that my plugins understand. Fixed how custom {People} formatting works with people keywords that have no birthday associated with them. |
| 20151103.262 |
Special handling for reverse geocoding in the United Kingdom to have the second-level name (England, Scotland, etc.) fill in the "country" field. This seems to be more practially useful than having the "country" field be "United Kingdom" for all the various far-flung areas of The Realm. The "country code" remains "GB" for all. For the same reason, for Greator London, have the "State" be London and the City be the Borough. |
| 20151028.261 |
Special handling for reverse geocoding in Japan: for some reason Google has started to return bus stops with high-level tags like "point of interest". These are now removed because bus stops are not really points of interest. Upgraded to the embedded copy of ExifTool to version 10.00. Added {SpeedKPH} and {SpeedMPH} to the list of template tokens supported by my plugins. The {People} token wasn't working properly for some keywords without a registered birthday. |
| 20150815.260 | Some combinations of tracklogs and photo times would cause error messages. |
| 20150703.259 | Photo times are such a rat's nest in Lightroom. If a photo's time has been updated in Lightroom, sometimes you see the corrected time, sometimes the original uncorrected time. It turns out that the "Geoencoding" metadata-viewer tagset was showing the original uncorrected time, so this fixes that. |
| 20150607.258 |
Added an option to export (as KML) the data currently stored in your "Personal Mapping Locations" in the "Reverse Geo" tab. It turns out that Google Maps now stores references to your custom maps in Google Drive, and if you unwittingly delete these references not knowing that doing so also deletes your custom maps, your data is gone. I have first-hand knowledge of the surprise thise causes. Anyway, this new option allows you to recover the data that the plugin had cached. |
| 20150522.257 | Added Japanese-government elevation maps to the View At menu. |
| 20150408.256 |
Updated the reading of personal-location-mappings KML URLs to also handle KMZ data, which Google has started unilaterally returning. When loading a tracklog, display the location/city where it starts. |
| 20150205.255 |
Reworked the "Geoencode from Google Earth" to also work with Earth Pro. In the POODLE-vunerability dialog, display a raw URL of a page on my site that discusses the issue, so that folks can be independently sure that the dialog is indeed from me and not malware. |
| 20150131.254 |
Fix to the date_diff() function supported by the LUA template token. Updated the camera-name code to try to guess the actual camera model of Hasselblad H5D files, since in their infinite wisdom Hasselblad decided to encode three distinct models with the same internal code, making it impossible to know for sure what camera produced a given image file. |
| 20141219.253 | Google started adding "-ken", "-shi", and "-fu" suffixes to some Japanese state/city names, so they've been added to the list of suffixes to ignore when that option is selected. |
| 20141210.252 | Registration was broken on Lr2 |
| 20141203.250 |
The raw result went missing from the one-by-one reverse geoencoding dialog in the last update. Now back. Added a way to search/filter as well. Added some debug logging to track down a reverse-geocoding issue. |
| 20141129.249 |
Try harder to glean the "Location" from Google reverse-geocoding data. |
| 20141127.248 |
Adds a new per-image bit of metadata: the timezone in which to interpret the photo-taken time. You can inspect (and set/update) this metadata in the Library metadata panel when selecting the "All Plugin Metadata" or "Geoencoding" views, or by adding it to your custom view built with my Metadata-Viewer Preset Editor plugin. Geoencoding via a tracklog sets the timezone, preserving the information we needed anyway for the tracklog read. Added some new items to the list of world timezones. Added the ability (in the "Etc." tab) to guess timezones based upon the time and location of a photo. Upgraded to the embedded copy of ExifTool to version 9.76. |
| 20141019.247 | Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists. |
| 20140923.246 | Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token. |
| 20140917.245 | Don't croak if given a KML file without polygons. |
| 20140902.244 | New build system |
| 20140808.243 | Added "Adjust Bearing" operation to the "Etc." tab. |
| 20140802.242 |
Made the {GPSAltitude}, {Altitude}, and {GPSCoordinates} tokens subject to the geo-privacy settings like the other geo-related tokens. |
| 20140731.241 | Registration fix for Lr5.6 |
| 20140729.240 | Previous updates broke support on Lightroom 2 |
| 20140722.239 | Update to recognize "new" Google Maps urls |
| 20140715.238 |
Fixed an issue with Creative-Cloud revalidation. |
| 20140712.237 |
Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed. |
| 20140710.236 | Sigh, had a bug in the Creative-Cloud support. |
| 20140708.235 |
Now supports Lr5.5+ Creative-Cloud Installs. |
| 20140704.234 | Sigh, introduced an error for some folks with the rebuild the other day. |
| 20140630.233 | added some extra debug logging to track down an issue with reverse geocoding. |
| 20140630.232 | Build-system update |
| 20140628.231 |
Added "Subway Station" to list of possible sources of location data that Google can return. Fixed a problem that showed up when canceling out of a bulk-reverse operation. |
| 20140619.230 |
Added some notes to the "Help" tab of the Geoencoding Dialog, to coincide with having actually documented this plugin on my web site (finally, after almost six years!). |
| 20140613.229 |
Added date_diff() and raw_time_diff() functions to the special {LUA} token understood by the plugin. |
| 20140605.228 |
Upgraded to the embedded copy of ExifTool to version 9.60. |
| 20140531.227 | When combining a street name and street number while reverse-geocoding a location, try to follow the various conventions used around the world. |
| 20140530.226 |
Added the ability to flush plugin data for selected photos. Upgraded to the embedded copy of ExifTool to version 9.53. |
| 20140509.225 |
Added new tokens to the template language the plugin understands: LrVersion, LrVersionMajor, LrVersionMinor, LrVersionRevision, LrVersionBuild, Location, CatalogName, CatalogPath, OperatingSystem, OS Added new token filters: NS and LO |
| 20140505.224 | Fixed "Pinpoint Location in Google Earth" |
| 20140423.223 | Fix a location-related template-token bug introduced in a recent build. |
| 20140422.222 |
Fixed a bug in the "smoother revalidation" stuff recently added. |
| 20140418.221 |
Google's "New" maps don't understand the URL format its Classic maps has used for years, but I've figured out a kludge that allows the plugin go generate Google Maps urls that work with both Classic and New. If you want to apply those URLs to the plugin's Map Url metadata for all your previously-geoencoded photos, select them then visit the "Etc" tab of the Geoencoding dialog and "Set Map URLs". |
| 20140417.220 |
The geoencoding dialog wasn't fitting on the smallest screens, so I tightened things up a bit. Discovered that some of the fonts I used in the geoencoding dialog don't work on Windows. The {Empty} template token wasn't working properly. Make the revalidation process smoother, especially for folks using Lr5.4 and later. |
| 20140329.219 |
Reverse-geocoding with a local KML file worked only when plugin debug logging was turned on; now works all the time. Upgraded to the embedded copy of ExifTool to version 9.53. |
| 20140324.218 |
Return support for filling in the country code. With the local KML data, the first line of the location description can now be in the form “country code / country / state / city” as well as the old “country / state / city”. Where the country code is not supplied, it'll be derived from a table built in to the plugin, or, failing that, via the reverse-geoencoding results from Google. |
| 20140301.217 | A local KML file's location was not being applied in some cases. |
| 20140204.216 |
The new location stuff in the Geoencoding dialog caused the dialog to be too big for some small screens, so now on very small screens the whole tab is put into a scrollable window. Lightroom gives little option but for this to be really ugly, but it's better than not being able to see part of the dialog. Fixed a "street address" bug. |
| 20140204.215 |
Added "Street address range" and "Street name" to the list of "location" items one can use when reverse geoencoding, and fixed "Street address", which had been broken. So now a location might return "1234 Main St." for the "Street Address", or failing that, someting like "1234-1255 Main St." for the "Street address range". In either case (or when no address or range is known beyond the street name) "Street name" gets "Main St." |
| 20140123.214 |
Completely redid the bulk reverse geoencoding code from scratch... prior code could in some cases not apply the local KML file properly. Everything's now much cleaner and more efficient internally. Upgraded to the embedded copy of ExifTool to version 9.46. Added support for Apple Maps (the OSX App if you have it, the web site if not). When geoencoding from a tracklog, round the bearing to the nearest degree, so we get -90° instead of -89.999999778064°, for example. |
| 20131203.213 |
Fix a reverse-geo KML file-reading bug introduced yesterday. |
| 20131202.212 |
Added the ability to import/export reverse-geo settings. Overlapping regions wouldn't always properly prefer the smallest matching region when applying via tracklog. Fixed some bugs with network KML files, and enhanced how the plugins works with Google network KML files. |
| 20131102.211 |
Update for OS X Mavricks. |
| 20131031.210 | The new fast proximity search added in 20130929.206 would finish silently (wouldn't report "no images found") if there were none in range, but some were sort of close. |
| 20131022.209 |
Added the ability to reference personal reverse-geo data via Network KML. Google maps now allows you to maintain personal maps with your locations of interest marked with your own labels, so the plugin can now take advantage of that. See this page for more details. Updated the Image::ExifTool library to version 9.39. Stopped setting location to "?" when it couldn't be determined from Google; now just leave it blank. Enhanced the quality of the reverse geocoding "location" data gleaned from Google. Added ability to link to Google.ru maps. Removed Wikipedia and YouTube options from Map-link layers (because Google removed support for them). Made the conversion to the British Ordnance Survey National Grid internal to the plugin, thanks to the kind work published by Chris Veness here. Fixed a bug that showed up in Lr2. |
| 20131003.208 | Added the ability for Windows users to set the keyboard-accelerator for plugin-extra items. |
| 20131002.207 | The "location" field wasn't being updated properly in reverse-geocoding. |
| 20130929.206 |
Added a new "File > Plugin Extras" menu item: "Fast Full-Catalog Proximity Search", to isolate all photos in your catalog that are geoencoded within X distance of the current photo. In Lightroom 5 on OSX it's ridiculously fast (a second or two). On Windows or older versions of Lightroom, it takes longer... two and a half minutes to search 130,000 photos on my circa 2010 laptop. |
| 20130927.205 | My new "ellipsoidal geometry" code didn't work for some tracklogs. |
| 20130926.204 | Oops, fix a bug introduced in the previous update |
| 20130925.203 |
The token-examples dialog had been broken. Also deprecated 'Folder' and 'Path' tokens in preference to 'FolderName' and 'FolderPath' tokens. A fix for the previous update. |
| 20130920.202 |
Google has turned off the old "Version 2" reverse geo-lookup, so I've removed it as an option. All reverse lookups now use the current Version 3 engine. Changed all distance calculations from spherical geometry to ellipsoidal geometry, raising the level of accuracy from "way more than good enough" to "ridiculously overprecise". 🙂 |
| 20130829.201 |
Added ability to view locations in Catalonia at the Institut Cartogràfic de Catalunya. Added the ability to display a location's UTM coordinates. Better handle dates on some non-photo images. Fixed the KW/KWE tables in template tokens; they had been broken when using load for the script. Updated the Image::ExifTool library to version 9.35. Google killed Latitude, so removed support for it. |
| 20130613.200 | Better support for plugin revalidation. |
| 20130611.199 | Yet another Lr5 update |
| 20130524.198 | Apparently, a recent change broke things on Lr2, which some folks apparently still use. |
| 20130501.197 | Update for Lr5 |
| 20130412.196 | Build system update. |
| 20130328.195 | Fix for the registration system. |
| 20130220.194 |
Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType. |
| 20130209.193 | More build-system maintenance |
| 20130206.192 | Tweak for my registration system |
| 20130201.191 |
Upgraded to the embedded copy of ExifTool to version 9.15. |
| 20130120.190 |
Added support for Yahoo Japan maps (which are very good in Japan) Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters. Upgraded to the embedded copy of ExifTool to version 9.09. |
| 20121009.189 | Work around a Lightroom 4.2 bug that resulted in an error when first upgrading a Lr3 catalog with Lr4.2. |
| 20120923.188 |
Fixed a problem that showed up in the error-report reporting of tracklog start/end times when multiple tracklogs were loaded in the wrong order. Added a JPEG-quality setting to the “Export as KML” dialog, and actually made the image-size setting work. Added a progress dialog to the KML-file generation even when not generating inline images, if the number of files to process is large. |
| 20120821.187 |
Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link. |
| 20120818.186 | Updated map-url format for geoportail.gouv.fr |
| 20120723.184 | Removed an artificial limit I had on the number of tracklogs that can be loaded at any one time. |
| 20120703.183 | Added OpenStreetMap and OpenCycleMap to the kinds of urls you can assign to geoencoded photos. |
| 20120628.182 | De-encoding was broken in Lr2/Lr3. |
| 20120614.181 | Added a bunch of extra logging to try to track down some slowness in the Lr3 writeback process. |
| 20120610.180 | Apparently I need to sort the results from Google Latitude myself. |
| 20120608.179 |
Added the ability to download a GPX tracklog from the web, and to create a GPX tracklog from Google Latitude data. The Google Latitude data is pretty bad (low frequency and low accuracy), but it's better than nothing if you have it and nothing else. |
| 20120526.179 |
Update to handle the Mac App Store version of Lightroom. |
| 20120512.178 |
Show a nicer error message if the network appears to be down when reverse geocoding. Yikes, Lr2 registrations were broken again. |
| 20120507.177 |
In Lr4+, added the ability to fill in elevation data from Google for geoencoded images. See the “Etc” tab of the plugin's geoencoding dialog. |
| 20120430.176 |
Added support for Google's “v3” mapping API, which offers different reverse-geoencode results. Whether “different” is better or worse depends on the location and one's taste. You can switch to it in the “Reverse Geo” tab. Tweak for Lr4.1RC2. |
| 20120413.175 |
Enhanced the send-log dialog to hopefully make reports more meaningful to me, yielding, I hope, the ability to respond more sensibly to more reports. Added some extra debug logging. |
| 20120330.174 | Update to handle 4.1RC |
| 20120314.173 | Tidy up a few bugs introduced recently. |
| 20120313.172 | Reworked the date/timezone handling to better handle complex situations where the camera's clock, the photo location, and the processing in Lightroom are all in different timezones. Also be more explicit in the Tracklog tab about what timezone is being used for the display of photo and tracklog times. |
| 20120309.171 | Update to the debug logging to better track down timing issues that might arise. |
| 20120307.170 | In the GPSBabel config area, added some suggestions for known devices, and on OSX, made it possible to configure the use of GPSBabel by pointing the plugin at the GPSBabel app. |
| 20120304.169 | Fixed a problem with Lr2 that I introduced in the previous build. |
| 20120228.168 | More Lr4 work |
| 20120225.167 |
The "Between Endpoints" geoencoding could produce widely wrong results with certain timezone settings. |
| 20120224.166 |
Massive Update Note: upgrading to this version causes Lightroom to throw up the silly “Your catalog must be updated before it can be used with the following plug-in” dialog because I've changed how some of the underlying data is arranged. Additionally, when first using in Lr4, the plugin now migrates the old "Shadow Data" to native Lightroom location data, and all traces of "shadow data" and the even kludgier "writeback" are gone (in Lr4). Made “speed” and “bearing” user updatable, and “speed” searchable. (This is the guilty party for the silly catalog-must-be-updated message.) Added the ability to search for locations via name/address/description, just like the search box in Google Maps. More on the march toward Lr4, including upheaval in the code to handle Lightroom APIs being discontinued in Lr4. I also made the “Shadow Injector” do nothing in Lr4... I didn't remove it completely because doing so would disable publish services and export presets that had used it, so now it's just a no-op. Remove it at your leasure. Added the {AspectRatio} token to the token templates understood by the plugin, and added the Length=num filter. Moved the “Tracklog” tab to the front. Fixed a bug in recognizing cut-n-pasted locations that I introduced into the previous build. "View as KML" would fail if some images had no timestamps. When building a KML with a tracklog, you can now opt to preserve the tracklog altitude (rather than blindly clamp to terrain), which is useful for flights. In the one-by-one window, "copy from above" changes didn't stick. "View Error Report" button could appear even if there were no errors. Better handling when cut-n-pasting location values into the dialog input fields. |
| 20120123.165 |
More tweaks for behind-the-scenes catalog access in Lr4. --Better handle cut-n-pasted static locations, and recognize additional location types. |
| 20120114.164 |
More tweaks for Lr4b. Updated Image::ExifTool to version 8.75. |
| 20120112.163 |
Added some Lr4-specific debugging. Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta |
| 20111207.162 | Had issues with the registration button sometimes not showing |
| 20111207.161 | Writing back the shadow data to the master image files could fail in edge cases. |
| 20111206.160 |
“View Photos as Tracklog in Google Earth” didn't work if titles had an ampersand. Added the ability to fill in shadow data from real Exif data, on the “Etc.” tab. |
| 20111130.159 |
Notice changes to the tracklog “fuzziness” even if it's still the active data field. Previously, the old value was being used if the field was not committed when geoencoding started. When doing a plugin upgrade, offer the ability to flush all the old copies of the plugin. Updated Image::ExifTool to version 8.68. Added a system-clock check and reports to the user if the system clock is more than a minute out of date. An incorrect system clock can cause problems with various kinds of communication and authentication with some of my plugins, so I've just gone ahead and added this to every plugin. |
| 20111018.158 |
Allow the shadow injector to go ahead and inject data even if other metadata is being omitted. In this case, it injects normal GPS data as well, if there's normal data but not shadow data. |
| 20111012.157 | When geoencoding from Google Earth, try to detect when Google Earth has just started and returned a default location, and give the user a chance to abort using that default location (since the user likely wanted to use something else, or didn't intend to launch Google Earth in the first place). |
| 20110928.156 | Plugin would lock up if the same location was used for both ends of the “between endpoints” geoencoding method. |
| 20110813.155 | The Error Report could crash when used with tracklogs that spanned a long period of time, but with gaps of no data greater than a week or more. |
| 20110719.154 |
Trying to bulk reverse-encode a photo that wasn't geoencoded in the first place caused an error. Fix a race condition that sometimes caused an error while updating the catalog. |
| 20110615.153 | Disabling the new KML support neglected to flush the cache of already geoencoded locations, so it appeared that the KML stuff was still enabled. |
| 20110613.152 | Somewhere along the line the filter for which images to process (with/without real/shadow data) got removed from the Write Back tab. This update adds it back. |
| 20110613.151 | Don't need a placemark description for it to be recognized. |
| 20110527.149 | Fixed some boo-boos introduced in the previous update. |
| 20110526.148 | Big update for reverse geocoding. Please see “Enhanced Reverse Geocoding With a Custom Map of Locations of Personal Interest” on my blog for details. |
| 20110520.147 |
Added Australian territory postal-codes to the “expand to full names” support during reverse geocoding. |
| 20110513.146 | Still trying to fix crashes due to bad static presets... |
| 20110430.144 | The bulk-reverse-geoencoding dialog didn't offer the “apply to all” when only “location” was selected. |
| 20110422.143 | Still trying to fix crashes due to bad static presets... |
| 20110421.142 | The XMP-writeback process was not respecting the lettercase of pre-existing XMP files on case-insensitive file systems. |
| 20110411.141 | Trying to fix crashes due to bad static presets... |
| 20110411.140 |
Added support for automatic filling in of the “location” during reverse geoencoding. It's rarely useful in my tests, but maybe it's just unuseful for the locations I happen to work with... Upgraded to the embedded copy of ExifTool to version 8.50 |
| 20110311.139 | Added OpenCycleMap.org support. |
| 20110215.138 |
Upgraded to the embedded copy of ExifTool to version 8.40. In the reverse geocoding dialog, am now more aggressive about filling in the “location” box with an address or the like. Handle tracklogs with negative altitude, and display negative altitudes to the nearest decimeter rather than nearest meter (because they're likely accurate depth readings taken during a scuba dive). For Lr3+, changed the “small dialog for small screen” stuff to allow automatic screen-size detection, and defaulted to that. If the main screen seems small, the terse version of the dialog is shown. As with Lr2, the option is shown in the plugin manager. |
| 20110113.137 | Added {CroppedWidth} and {CroppedHeight} to the template tokens used by my plugins. |
| 20101107.136 | Added Skog og landskap (Norway only) to the list of “View at..” menu items. |
| 20100829.135 |
The “Geoencode selected photos from Google Earth” feature I added a month ago wasn't undoable, which created a danger if you made a keyboard shortcut for it and bumped it by accident. If you do that now, you can simply undo it. Made the revalidation process much simpler, doing away with the silly need for a revalidation file. |
| 20100820.134 | Discovered a bug in my plugin build system that caused horribly difficult-to-track-down errors in one plugin, so am pushing out rebuilt versions of all plugins just in case. |
| 20100818.133 | Added support for Géoportail. |
| 20100814.132 |
Re-enabled image thumbs in the one-by-one dialog for Lr3.2 (currently available as a release candidate). Added code to allow plugin revalidation after having been locked due to a bad Lightroom serial number. |
| 20100803.131 |
Added a new Plugin Extras item “Geoencode selected photos from Google Earth”, which is a dialog-less method to immediately encode the selected photos with the location currently pinpointed in Google Earth. It doesn't do any writeback or reverse-location lookup to set the city/state/country, but you can do those in one shot with the normal geoencoding dialog, after having set the location for the individual photos. On Windows ALT-F S R invokes it. On a Mac, you can set your own keyboard shortcut as you like: see the comments for version 20100620.128 below, but the command is three spaces followed by “Geoencode selected photos from Google Earth”. |
| 20100625.130 | Yikes, shaking out some more build issues. |
| 20100624.129 | Discovered a nasty build bug; pushing a new version in case it affects this plugin. |
| 20100620.128 |
(Windows Only) Made it so that ALT-F S E; works as a keyboard shortcut for “Pinpoint in Google Earth” (along with ALT-F S G for “Geoencode”). Lr2 users will need to do some background setup, but thanks to the efforts of the author of that post, Adobe built it in to Lr3. (Mac Only) It's a breeze to enable keyboard shortcuts of your choosing; just visit System Preferences > Keyboard > Application Shortcuts and add one for Lightroom. For Lr3, prepend three spaces to the menu item you want to shortcut to, so to make a shortcut for geoencoding, enter “ Geoencode...” (that's three spaces followed by “Geoencode” followed by three periods). |
| 20100612.127 | Oops, reverse-geoencoding dialog had broken. |
| 20100611.126 | Fixed a bug that several people had reported recently, but that I just let slip through the cracks while overwhelmed with preparations for Lr3: that automatic writeback didn't work the first time through on an image. Fixed. Also made it so that the progress bar will work again on Mac. |
| 20100609.125 |
This version can be registered in Lightroom 3. It can run in Lightroom 2 or Lightroom 3; it does not work in the Lr3 betas. It uses my new registration system when run on Lightroom 3, which avoids some of the silly issues of the old one. Please take care to note the details on the registration page: use of this version (or later) of the plugin in Lightroom 3 requires a new registration code, even if you had registered some older version of the plugin. |
| 20100518.124 |
No longer try to have the writeback operation done by one process on Windows; there seems to be a memory leak somewhere that causes it to abort after a few very large images. Updated the “View in Google Earth” to read “View selected locations as KML in Google Earth”, and added a new “Pinpoint Location in Google Earth” for quick jump-to-this-location use. LR3: if exactly one image is selected when “View as KML...” is invoked, the plugin now asks whether to process one image or all filmstrip images. Fix an error-reporting problem for when Google throttles one's reverse-geoencoding. Attempt to self-throttle to avoid Google having to wag its finger at us. More tweaks in how the reverse-Geoencoding data from Google is parsed, to try to extract more information from the data. |
| 20100423.123 | Fixing an “attempt to compare number with nil” bug that I introduced in the previous version. |
| 20100420.121 |
Don't attempt to write-back shadow data to video files, and quietly don't try to inject gps data into video files during export. |
| 20100419.120 |
Updated the static geoencoing stuff to recognize additional latitude/longitude formats. Added the ability to use a custom per-photo description when creating KML/KMZ files. It uses the template tokens that my other plugins use (including some things that are not yet documented... nb can be used in a conditional to check for non-blank items). There's no preset/preview mechanism yet; I know it's needed. Updated the static-location preset mechanism to allow replacing presets (instead of adding) when loading from a file. |
| 20100418.119 | For reasons I don't understand, Google Earth doesn't seem to like non-ASCII image filenames, so the plugin now works around that. |
| 20100411.118 | Added the ability to view locations at Daum (Korea). Note: you must restart LR after installing this version for the new “view at Daum” functionality to work. |
| 20100402.117 | Should fix KMZ-creation on 64-bit Win7, I hope. |
| 20100329.116 | Added extra logging to try to track down a problem with between-endpoint geoencoding. |
| 20100317.115 |
Lots of cleanup from v112's big updates, such that the new KML stuff might actually work now. The “view KML in app” option had issues on OSX... fixed them. Added the ability to set up two extra axillary “view KML in app” applications (making a total of three) and tied them into the new KML dialog, and added the ability to set the title of each's menu entry. Note: you must restart Lightroom once after upgrading to or past this version for the new menu items to work. Removed the “View location at MS Live Maps” item, since that now just redirects to Bing. |
| 20100316.114 | Yikes, a typo broke some operations for some Windows users. Fixed. |
| 20100316.113 | Had neglected to enable KMZ zipping on Windows. |
| 20100315.112 |
First crack at real KML output, with embedded photos and an overlaid tracklog. Select some geoencoded photos then “File > Plugin Extras > View Locations in Google Earth” and a dialog will pop up offering all kinds of options. It's still a work in progress, but I wanted to kick it out. Wholesale changes that attempt to honor the user's locale settings for numeric display (e.g. Europeans writing 3,14156 for pi). I've probably missed some spots, so let me know if you find some. |
| 20100306.111 |
Be a bit smarter about reading the altitude from Google Earth, and pop up a warning dialog if the terrain layer seems to be turned off. Fixed the “invalid function for sorting” error that had been reported a few times. |
| 20100306.110 | Added “import location from Google Earth” for the between-endpoints start and end locations. |
| 20100213.109 |
Added a cancel button to the GPSBabel config dialog, and disabled the “OK” button if an error is detected in the input. Fixed the spelling of “Great Britain”. Sorry 'bout that. Spelling has never been my 4-tay. |
| 20100124.108 | Reverted some changes in the logging code that seems to be causing “attempt to index upvalue ‘?’ (a boolean value)” errors for some. As far as I can tell from looking at the code, it's one of those “can't be happening” types of things, so I'm sorta' stumped as to why it's happening. |
| 20100123.107 |
Added a checkbox to indicate whether files updated via the “write back” operation should have their modification times updated, or preserved. The default is to preserve the modification time (that is, to leave it as it was before), which is what the plugin used to do. Those with backup software that looks at file-modification dates may want to uncheck this option. Added a “View as OSGB” option that shows the British Grid reference for the photo's location, using one of the online tools provided by Dale Abbey. Made the “copy from above” and “copy from below” items in the interactive one-by-one page copy everything int the row, not just the latitude and longitude. A few fixes in the one-by-one page for LR3. Allow three-letter and three-digit country codes, in addition to the two-letter codes that were allowed before. |
| 20100121.106 |
Added the ability to select what version of Google Earth the plugin should use. Added the new Microsoft Bing Maps (requires Silverlight) as one of the “View at...” options. Completely changed how the one-click upgrade applies the newly-downloaded zip file, in the hopes that it'll work for more people. Rather than unzipping over the old copy, it now unzips to a temporary folder, then moves the old folder out of the way and the new folder into place. Prior versions' folders are now maintained (with the version number in the folder) in case you want to revert a version; you may want to clear them out from time to time. Of course, it won't take affect until you try to upgrade after having upgraded to or beyond this version. |
| 20100102.105 | Added Bing to the list of urls that can be configured to be automatically associated to each image. |
| 20100101.104 | Added Microsoft Bing to the “View at...” list. |
| 20091216.103 | Fixed a bug that gave the tracklog-filename-input box the attention span of a toddler, making any attempt to type a tracklog filename by hand a frustrating experience. |
| 20091205.102 | Minor internal debugging tweaks. |
| 20091121.101 | The various “View at...” items in the Plugin Extras menu didn't work in the LR3 beta. They do now. |
| 20091108.100 | More heuristics to try to coax better city/state/country results from the reverse-geoencoding data that Google (kindly) provides. |
| 20091106.99 | Fixed a second boo-boo with reverse geoencoding. Still not sure what the problem actually was (which is a bit unsettling), but I've worked around it for the moment. This is also the first build from my new build environment, so hopefully things go smoothly.... |
| 20091103.98 | Oops, had a boo-boo in the previous push that sort of stopped the plugin from working. Fixed that, and a few other issues with the new things I added yesterday. |
| 20091102.97 | Reverse-geoencoding tweaks, including options to strip “City”, “Province of”, etc. from non-US names, and to strip macrons from Japanese names. |
| 20091027.96 | Lots more updates in the “Interactive” tab for LR3b. I haven't figured out how to get thumbnails in LR3b yet, so I've removed them from the UI in LR3b. |
| 20091027.95 | More LR3b updates. In LR3b, if you get an error in LR3b, “Attempt to access property “data” that's not declared in Info.lua”, when opening the Geoencoding dialog, just try again. There seems to be a race condition of some kind in LR3b that sometimes causes this problem. It seems to pop up only when “Reload plug-in on each export” is turned on in the plugin manager, and there's no benefit to normal users to having that enabled (it's a developer tool), so leave it unchecked. |
| 20091022.94 | Added a first draft of some rudimentary support for Lightroom 3 Beta. See this important note about plugin support in Lightroom 3 Beta and Lightroom 3, including future plans for features and my registration system. |
| 20091019.93 | Fixed a bug that caused a crash when trying to write back GPS data to master images whose full path contained “$” or “@”. |
| 20091018.92 |
Implemented a few kind suggestions from Peter Krogh. The “dismiss dialog when finished” checkbox is now sticky on a per-tab basis. I added location/city/state/country to the “Geoencoding” metadata-viewer preset, and renamed the geoencoding dialog's “Cancel” button to “Dismiss”. |
| 20090927.91 | The plugin didn't do well launching Google Earth if its location on disk changed. |
| 20090915.90 |
Fixed what I consider a bug in Google Maps, whereby they focus on nearby (and sometimes not so near by) “points of interest” when directed to a specific location, instead of focusing on the specific location. In one case they were focusing on a point 50 miles away! Finally figured out a way around it (by prefixing the latitude and longitude with “loc:”). Made the UI for importing from Google Earth a bit better, disabling the button while it's working to let you know that it's working. Now handles locations of the form “12°34′56.78″N, 23°45′67.89″W” in the static input location. (It mostly already did, but didn't recognize some of the many quote-like Unicode characters, so missed some forms that one might cut-n-paste from some websites.) In the reverse-geoencoding dialog, the full address text (as returned form Google) is now selectable. On a Mac, it's the same text as before, but selectable. On Windows, I had to put it into a text input edit field to make it selectable. Adjusted the mouse interaction with the thumbnails in the one-by-one dialog, having a simple click bring up a larger version. On Windows, control-click rotates the thumbnail. (Can't seem to get thumbnail rotation working on a Mac.) Be more clear in the UI about when a tracklog is in the process of being inspected. (Sorry to everyone who couldn't contact my server for the last few days... it had “issues”, that are now fixed.) |
| 20090808.89 | The release contains a change in the heuristics for reverse geocoding, favoring the “LocalityName” over the “SubAdministrativeAreaName” when two otherwise equal records contain them. Reverse geocoding is a messy, vague business because the data is messy and vague. (But at least it's there... I appreciate Google collecting the data so I don't have to.) |
| 20090807.88 | Fixed an error that popped up during reverse geoencoding. Also fixed some text-input-field wrapping issues on OSX. |
| 20090729.87 | Fixed a few misspellings in the dialogs. |
| 20090717.86 |
Added a simple Tracklog Error Report so that you can see why images weren't geoencoded with a tracklog. |
| 20090707.85 |
For Windows, added a keyboard accelerator for the “Geoencoding” Plugin-Extras menu item, which will become usable after you follow the instructions on the Accelerate Access to Lightroom Plugin Extras post at ThePhotoGeek.com. There's also info there for Mac users on how to set up your own arbitrary keyboard shortcuts. Fixed that the “add map url to shadow metadata” item in the geoencoding screen would sometimes become disabled when it shouldn't. Made the small-screen option (selectable from the Plugin Manager) reasonable again. I had forgot about it when I added all the instructions in the interactive geoencoding / reverse geocoding tab. Some general tidying up of the dialog, thanks to suggestions from Tim Armes (author himself of half a dozen plugins for Lightroom). |
| 20090701.84 | Added some extra logging to the Google Earth interaction, to help debug when it's not working. Fixed a bug that caused the country code not to stick during reverse geoencoding if the country itself didn't change. |
| 20090701.83 |
Upgrading the built-in version of ExifTool to include support for DNG 1.3, required to work with for DNGs made with Lightroom 1.4. Enhanced the one-click upgrade stuff quite a bit, now detecting ahead of time when it will fail because the plugin is installed where Lightroom can't write (if Lightroom can't write to it, it can't update itself). I also added a progress bar, and now download in smaller chunks to avoid 'out of memory' errors on the larger plugins. Do remember that this new functionality becomes available after you upgrade to or past this version, when you then upgrade with it. |
| 20090630.82 | Put in checks to see whether the plugin is installed in a place that Lightroom can write. If it is, the “Configure Plugin-Extras Menu Items” button is enabled in the Plugin Manager. If not, a note is place there instead. |
| 20090608.81 |
Added NDT (Newfoundland Daylight Time) to the list of timezones. |
| 20090607.80 |
Well, with my boy spending the weekend on a trip with his grandparents, what I thought might be a short bit of tinkering this morning turned into a full day of tinkering....
|
| 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:
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:
|
| 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:
|
| 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:
|
| 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 |
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
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
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
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
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”,
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?
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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.
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.
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?
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
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
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
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
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!
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
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
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
writing back worked perfectly, thank you Jeffrey!
This is exactly what I looking for…
I like automatic write back option. Thank you very much.
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
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?
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
Hi Jeffrey,
in my case the write back does not work. Any Ideas?
Frank
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
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
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
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
GPS and “ÖÄÜ” is fixed! THANX!
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
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
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
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
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
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
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
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.
Hi Jeffrey,
Thanks for the small dialog box – thats really great – works well on the MSI Wind.
Hi Jeffrey
Looks good on the Asus EeePc901 as well
Thanks
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
… 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
… 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!
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
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
Jeffrey,
Thank you so much for the additional feature. It works perfectly.
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
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
… Jeffrey… I actually tried with just *one* picture selected! ;-/
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
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
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
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
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
… 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 😉
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…
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
… 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
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
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
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.
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
… HAPPY BIRTHDAY, JEFFREY!!! 🙂 🙂 🙂
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
Reverse geocode is perhaps the most useful plugin feature I’ve come across – thanks for this!
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
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…. 🙂
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
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.
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
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
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
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
Thanks Jeffrey–worked a charm.
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
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?
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.
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
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
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
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
Thanks for .84/Country code fix, appreciate the work you put in to this.
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
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
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
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
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
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
Thanks for all the help, the upgrade worked. Program works great. Sure makes geoencoding a lot more convenient Thanks.
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
Thanks for the answer, clear and to the point!
Given your example, I agree with you.
Giulio from Italy
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! 😀
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
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
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
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
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,
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
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
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
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
Wow! 100 updates. Thanks so much Jeffrey, for your talent and perseverance in making this the best geocoding app ever!!
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
Hi and congrats on the plugin. I was wondering if your plugin works on Mac OS X?
Thanks,
Juan Dent
Yes. —Jeffrey
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
Duh, they were right there in front of me!
Thanks Jeffrey!
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
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
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
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
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
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.
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
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
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
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!
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
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
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
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
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
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
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
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
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.
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. —JeffreyGood 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.
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!
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
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
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.
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
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
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
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
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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
… 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 🙂
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
Thanks for the quick reply. This is obviously a good plce to learn about Lightroom 🙂
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
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
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
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
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
> 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? 🙂
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
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
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
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
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
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
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
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
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
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
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!
Is there a keyboard shortcut to invoke Geocoding with LR3/Windows 7? (E brings up the loupe view)
ALT-F S G —Jeffrey
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
🙂 Thanks for decoding my question!
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.
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
Jeffrey-
Replaced the LR preferences file with a backup copy. All seems normal now. Many thanks for the help!
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
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
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
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
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
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
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!
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
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
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.
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.
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
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).
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.
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
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.
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
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
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
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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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.
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
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?
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.
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
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*
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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
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
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
“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
“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. 🙂
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
Does your plugin support LR4?
Yes. I’ve added a note to the top of the page about it. —Jeffrey
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
172 works fine, thanks
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
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
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
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
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
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
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!!!
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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,
🙂
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
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
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
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)
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
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
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
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!)
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
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
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
A big thank you for the “Added the ability for Windows users to set the keyboard-accelerator for plugin-extra items.”!
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
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
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
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
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
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
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
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!
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
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.
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
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
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
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
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
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
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
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
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
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
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
A friend sent me a .log file of our recent photography trip. I was able to view it using Google Earth. I can’t seem to upload this file into Lightroom. I think Lightroom wants a GPX file. Can this .log file be uploaded into Lightroom with your plug in? Thanks.
You can likely convert it to a GPX file with GPSBabel. If it’s something you’d need to do often you could configure the plugin to run gpsbabel automatically, but in this case you just need it the one time, so it’s probably easiest to just do yourself outside of the plugin. Perhaps try this web interface… —Jeffrey
Hi Jeffrey,
I have a problem with Neighborhoods in Spain: it seems that the plugin does not recognize them.
For example, for location 40°23’30” N 3°41’22” W Lightroom retrieve Legazpi (the neighborhood) while the plugin retrieve Calle del Plomo (The street name). Of course, I have set the field Neighborhood to a higher priority than Street Name, but all the fields are empty except Street Name and Street Address.
Do you know why I cannot retrieve the neighborhood with the plugin while I am able to do so with Lightroom ?
Thanks for your job !
The organization of the data that Google returns is an absolute mess that varies wildly at different places around the globe. The difference between what Lightroom does and what my plugin does is a reflection of different approaches to try to make sense out of that mess. It’s a fairly fragile process, and making a tweak that helps get better results in one area of the globe can often destroy the results in another. With that in mind, I’ve used your example to make some tweaks that I hope has a net-positive result. Upgrade the plugin to give it a try… —Jeffrey
I experienced problems similar to Itomi where the data returned was not consistent. After corresponding with Jeffrey, I discovered that the preferences set in the “reverse geoencoding” dialog was corrupted.
I did reset my preferences in the menu and now the data returned is reliable.
May be this can help others.
Thank you to Jeffrey who was very quick to answer and gave me the “hint” where the trouble might hide!
Check your preferences settings 😉
Hi. I moved to Google Earth Pro a view days ago. Since then, I can’t retrieve a location from Google Earth. I can display the Crosshair, I can view a location on Google Earth from LR but when I try to retrieve a location from the Crosshair position through the direct access, I get a message “Can’t get location from Google Earth”. From the Geoencode windows, nothing happens. Any idea ? Thanks.
It works for me in both OSX (10.9) and Windows (7), but I’ve had one other report of it simply not working for another user. We couldn’t figure out why. He opted to move back to Google Earth from the Pro version. If you’re on Windows, you can visit the “Win” subfolder inside the plugin and try running “GetCurrentGEView.exe” in a command window. If you see a bunch of numbers (latitude/longitude/altitude), it’s working, but I suspect for whatever reason it’s returning an error of some kind… —Jeffrey
I ran into this problem on Windows. What I had to do was uninstall both Google Earth and Pro, the reinstall Pro. The plugin then asked me for the location of Google Earth. I pointed it to the executable for Pro and all was well.
Thanks for the tip. Indeed it works after unstalling (reboot to be safe) and reinstalling. LR did not ask (it did the first time) to point the Exe but it works so that’s enough for me. Again, thanks.
Hi guys, for any conversion needed to get routes or waypoints, I suggest to consider this free tool which can easily make Google Earth kml format to gpx and vice versa, when in need. Check out here: http://kml2gpx.com/ Thanks!
Hi,
Since the last update (not sure from which version I updated though), the plugin opens multiple instances of GE, whilst making it impossible to geotag photos from GE.
Hope you had a nice trip, thank you 🙂
Lightroom 64 and plugin updated to the last version as of today, GE 7.1.2.2041
It should open up only one instance of Google Earth, the specific one you’ve pointed to via the [Configure Google Earth Location] button in the plugin manager. If you’re not seeing that, please send a log. Thanks. —Jeffrey
Jeffrey
I have created the ‘place’ in Google Earth. This works well to update the sub location in LR6 R23 – have you made any progress on being able to edit other fields, such as city, street etc?
Make the description look like “country/state/city” (e.g. “USA/California/San Francisco”). —Jeffrey
Hey, Jeffrey;
For the ‘Geocode from Tracklog’ tab, any thoughts on making the “Tracklog file(s)” point to a directory, instead of a specific tracklog? or maybe that plus a parameter that loads the last “n” files?
When I get back from a shoot, I dump my tracklog(s) into a directory, and periodically move them off to my server every few months. It would be nice to simply do a Library/Plugins/Geocode, select the tab, and then ‘Go’ instead of the extra step of browsing the directory to select the last few tracklogs.
Thank you!
–David
I, too, almost always geoencode with “the most recent few files”, but I just keep the list sorted by modification date and so it’s not too arduous to select the appropriate file(s) at the top of the list. Trying to configure some kind of automatic “use most recent…” seems fraught with “doesn’t work quite how I want” peril… —Jeffrey
Hi Jeffrey,
thank you for the plugin, it is very useful!
One question/suggestion – in the Reverse Geo mode it is possible to select either “Fill in only fields that are blank” or “Overwrite all fields with new lookup data”. Would it be possible to add a third option that fills the empty fields and autocommits information that is present in others?
Thank you!
No, sorry, because Lightroom doesn’t give plugins any access to data that has not been committed. —Jeffrey
Hello,
This is to answer the comment left by Thomas on March 22nd.
When, sometime in February, I updated to the latest release of the plug-in, I had the same kind of problem. It persisted in wanting to open several instances of Google Earth. I noticed that the parameters of this Google Earth were not the ones I had set in the preferences of the Google Earth I use.
After much head scratching, and Jeffrey on holiday at the time, I noticed that the plug-in had lost all the settings. After reconfiguration:
– pointing the Google Earth,
– resetting the location preferences,
it all worked again.
(if it is any use, I am on Mac)
I’m using a Foolography Unleashed Dx000 and a Holux RCV-3000 to geotag my photo’s in my Nikon D610. Your plugin works wonderfully in Lightroom, except for the times that the GPS took awhile to acquire GPS lock, or temporarily lost it in the middle of a shoot. Could you extend the features of your plugin to use GPS data when available, but to use previously geotagged photos as a pseudo-tracklog for those that are missing GPS data?
For now, when I notice that I’m missing GPS data on a few shots, I’ll download the tracklog data from the device, load it into Lightroom, add that location data to the missing pictures, then reverse geocode with your plugin. It would certainly speed up the workflow if you could add this functionality.
Thanks in advance.
In this situation I just open up the Map Module with the filmstrip showing, and drag unlocated images to the map. I’m not quite sure how I’d automate it, nor how generally-useful it’d be if I did…. —Jeffrey
Robert, in this case I use the “Between points” feature of the plugin which interpolates between previously geotagged photos.
I’m one of those that can’t get coordinates from Google Earth. Clean install of Windows 8.1 a couple weeks ago. Lightroom 6. I uninstalled Google Earth Pro and installed regular Google Earth. I can see the cross hair, but it never gets coordinates. It remains a mystery to me, sorry, but I heard from one person with this problem that when they visited the plugin manager and re-told the plugin where Google Earth was installed, it started working for them. —Jeffrey
Jeffrey,
I was probably the one affected by this issue.
Yes, going into the plug-in manager and resetting everything did the trick.
I have not uploaded the latest version of the plug-in; I am getting shy 😉
Yeah, I read that, it’s the first thing I did, and it asked me again where the .exe was. What’s odd is that the first time I used it, it worked, until I turned on the cross hair to be more accurate, and since then nothing has worked for me. Strange…
Hi, I am not in any way technical so please be kind!! I take many photographs either when out walking or cycling and would like to geotag them in LR6 (CC). My camera does not have the facility. I have used an app on my iPhone in the past however I am about to purchase a Garmin Edge 200 cycle computer which I understand can export a .FIT file. My question is can your plugin read this type of file and sync it with my photographs within the MAP sector of LR?
The plugin natively handles only .GPX files, so if you can get the Edge to export one of those, you’ll be fine. Otherwise, you can configure the plugin to convert the .FIT file to a .GPX file for your automatically, via the “config…” button under the trackfile “Browse” button. You’d install gpsbabel on your system and point the plugin at it, then set it up so that when a “fit” file extension is selected, “-i fit” is used. —Jeffrey
Thank you for that. I have now discovered that I can export a .GPX file through Garmin. For the record I live in Scotland.
I’ve just upgraded to Lightroom 6 and the latest version of the plugin, but for some reason the “Import location from Google Earth” option doesn’t seem to work anymore (it did a few days ago, when I was just running the plugin in LR6 as trial). I’ve explicitly re-set the path to Google Earth, closed/reopened both apps, but to no avail (on Win8.1, if that makes any difference). Any ideas?
Sorry, no ideas on this )-:. Google doesn’t officially support what the plugin is using to try to get the current view (they used to years ago, then dropped support), so it remains a mystery. I’ve spent many hours trying to figure out why it doesn’t work for some folks, and I’m stumped. Sorry. )-: —Jeffrey
Hi Jeffrey,
The plugin Geoencode Selected photos does not work on my PC. It has always worked for me correctly, until today, I have registered.
I’m using the Google Earth Pro with Lightroom CC. Windows 7 Pro x64.
The error message is: Can’t get location from Google Earth
Best regards,
Pep Ferrer
Please see my response in the comment immediately previous to yours. —Jeffrey
I’ve just upgraded to LR6, while at the same time migrating to a new computer… and I seem to have lost all of my static location presets within the geoencoding plugin. I’ve grepped around a bit in the Application Support/Adobe/Lightroom folders on the old and new machines, and I can’t seem to find them… is there an easy way to bring them over to the new machine/LR install?
The plugin stores them in your Lr preferences file. If you can invoke Lightroom still on the old system (or on the new one with your old preferences), you can export them via the plugin to an external text file that you can then import into the new system. —Jeffrey
I use the Qstarz BT-Q1000 XT which seems to log fine but I notice in the GPX, there are points with names such as:
Stop for 1hr10mins
As a result, the lat/long is not being repeated every 5 seconds (the default logging interval)
So now when I try to match the photos to GPX, there isn’t (always) a matching timestamp since it might have been 10+ mins earlier with a pause.
At least, this is what I THINK is happening… Any way to handle this situation?
It’s not ideal, but you can set the “fuzziness” in the tracklog dialog to something large. —Jeffrey
I traveled to a different timezone but left my camera as-is. Upon loading into lightroom i selected all and edited the capture time – everything worked fine. When I view the default view, I see the updated “Capture Time”. When I go to the “Geocoding” view, the “Date Time” field still has the old value – shouldn’t this also reflect the date?
When I do the geocoding, how do I now know which timezone to pick since I am seeing two dates?
Many thanks!
Ah, good catch. Photos times are a complete rat’s nest in Lightroom, and the way they’re exposed to plugins is often simply wrong. But I figured out how to get the proper date in most situations (videos are still a separate issue) and just pushed a new version of the plugin that has the better date in the metadata view. Hopefully you’ll see only the one (fixed) date from now on…. —Jeffrey
Using v 20150703.259 on LRCC. I tried to use the “Import Location from Google Earth” (GE 7.1.5.1557) option which I’ve used many times before. I lined the crosshairs up just where I wanted them. On the plugin dialog it says Valid location not yet specified. The plugin dialog blinks “fetching”, but no coordinates appear. What’s going on here?
Sadly, this feature is not supported by Google and for mysterious reasons has stopped working for many folks at various upgrades. It sounds as if perhaps you didn’t upgrade and that there’s no obvious trigger here, but then we’re back to the “mysterious” aspect of it. The plugin uses a feature that Google added long ago, but then abandoned, so I never know whether it will actually work. It seems to work for me, but many hours debugging (with other users for which it no longer works) has not been fruitful. In other words, I’m at a loss. )-: —Jeffrey
Hi Jeff, thanks so much for your very useful plugins! I have used GeoSetter in the past to geotag my photos. I use a GPS tracklog that generates GPX or KML files. Usually, I take a picture of my GPS device while hitting the waypoint button so that I have a picture at the exact time of the waypoint. GeoSetter then allows you to set a specific picture to the time of the waypoint, adjust all the other pictures with the same offset, and then automatically assigns the GPS coordinates of the tracklog to the photos. I was trying to incorporate as many steps of that process into LR6 as possible. Does your geotag plugin allow assigning a waypoint to a photo to fix the time, then assign the coordinates based on that offset? I see that your plugin does allow for the offset, but was wondering if there was a way to incorporate the waypoint aspect (helps me not have to worry too much about getting my camera time exactly aligned with the GPS unit!). Thanks! I’m in Dallas.
I didn’t quite follow the whole waypoint thing, but what I suggest here is to just take a photo of the GPS unit’s clock some time during the day, then after loading all the photos in Lightroom, select all photos and most-select the clock-display photo. Then in the Metadata Panel click on the list icon next to where the time would be shown if only one photo was selected, and that’ll allow you to update the times for all photos by entering the correct time for the clock-display photo. Now all your photos have an accurate time, and you can delete the clock-display photo and geoencode the rest via the tracklog (using the Map module or my plugin). —Jeffrey
I’m writing from Orlando, Florida. Just tried an “economical” geo-encoding process that has a few bugs and I’m wondering if you can make the plugin even yet more smarter :-). The problem is this. I visited 6 different locations pretty close to one another. I spent anywhere from 10 minutes to several hours taking pictures at each location. So there was no need to keep on tracking at each location. I simply started making a geo-log in my iPhone and a few seconds later stopped it. So there are several logs, each one lasting only a few seconds, but representing a long time at each location.
So I loaded up all the logs in the plugin. This is a great feature, each log is separated by a comma. Thank you for thinking of that. However, the first time I tried to bulk geo-encode all 741 photos with all 5 logs, there were 739 errors and only 2 photos identifed correctly. This I eventually figured out was because the fuzziness parameter of 30 seconds was much too short. So now I have Fuzziness raised to 2400 seconds and it has successfully geo-encoded about 500 out of the 741 photos. That’s an improvement!
But what will happen if I over estimate the fuzziness parameter and now location 2 effectively overlaps location 1? Will the plugin pick the location whose time most closely matches the photo? Maybe there’s a better solution for this problem, which I bet is pretty common. Maybe there is a different tab I should pick in the plugin, but I can’t figure out which one. Or maybe you can invent an algorithm that would take care of this issue. I hope you can, because this is a great plugin and geocoding is such fun! Thanks for thinking of it, Jeffrey.
In this case I wouldn’t bother much with the gps log beyond using it to remind you where you were. So from a geoencoding point of view, it becomes a “static location” scenario. If you can get one photo in each location properly located (perhaps via the log with a relatively small fuzziness factor, or from viewing the log in Google Earth or Google Maps and copying the location in) you can then share that location with all other photos that you know you took there. Using a large fuzziness like 2400 seconds seem fraught with danger.. with such a big range, the closest timestamp may well be at the next location. Also, turning the log on for only a short time at each location perhaps doesn’t give the unit enough time to settle on a good location, so perhaps best to leave it long enough so that you can visually confirm a good location, then make a waypoint. Then later geoencode via the waypoint. —Jeffrey
Hi Jeff, I had great success using your plugin to geotag all of my photos with 8 years of Location History for upload to Google Photos. The only thing that’s missing is videos — GPS location shows up in video metadata in Lightroom, but when I export them, GPS tags are missing in new file. I tried both “original” and “H.264” setting, and tips?
Lightroom’s handling of metadata for videos is nothing short of pathetic, so it doesn’t surprise me if they ignore or screw up the location data. I’m not an expert in video formats, so it’s possible that some video formats don’t allow for location metadata, but this is unlikely for the common formats that Lightroom supports. —Jeffrey
Hello!
Thank you for very useful plugin!
On my previous install of plugin and lightroom (6.01, plugin – april or may 2015) location was gathered as “street name, house”. Today i had to reinstall everything and i gather location only as “street name”. How can i change behaviuour to the old one to have fields filled similar to old photoes?
Thank you for your answer!
It’s configurable on the left side of the “Reverse Geo” pane of the plugin’s main dialog. —Jeffrey
I wasn’t really sure if your plug in will do this but I am hoping that it will and I happily donate generously if it will. I am a Real Estate appraiser. I take lots of pictures of lots of houses of which i only use 15% for the appraisal. I would like to be able to take the other photos and convert their stock name to their geographic address. So if I took a picture on 25 Main Street and didn’t use it, I would like to be able to see at a later time if I need a picture of 25 main street. I hope I am making sense.
I’m not sure what you mean by “stock name”, but if you’ve got your photos geoencoded well, you should be able to pull up the Map Module (after selecting “All Photographs” in Library) and navigate to the target property, and you’ll see icons on the map representing photos you’ve taken at or near that location. If you really do need the address, you can have my plugin invoke Google’s reverse geocoding for you, filling in the “Location” field, but the street address is an approximation (25 Main Street might become “30 Main Street” or “15-25 Main Street”, etc.) so I’d be wary to trust it. Of course you can manually type in the address to the Location field (or title or caption or wherever you want to save it), and you don’t need any plugin for that…. —Jeffrey
Jeffrey,
What I suspect he wants is a file rename capability where he builds a new file name based on the address field.
🙂
Hi Jeff – I’ve been enjoying your Google (PicasaWeb) and Facebook plug-ins and thought I would check out this one. I took a trip a couple weeks ago and decided to try geocoding the pictures after the fact using Google’s location tracking data (my DSLR camera doesn’t have GPS and I wasn’t using a tracking app). This comment is more to help anyone else who endeavors to do the same, though your thoughts would be most welcome.
I found I could download kml files a day at a time from Google (https://www.google.com/maps/timeline) and then found that you can even download a kml for a date range using this URL:
"https://maps.google.com/locationhistory/b/0/kml?startTime=starttime&endTime=endtime. The start and end times need to be in milliseconds since 1/1/1970, which can easily be obtained for any date/time using http://www.epochconverter.com.All of Google’s timestamps are explicitly relative to UTC-07 (e.g. 2015-08-07T21:00:03.347-07:00). I attempted to use this file with your plug-in with GPSBabel doing the conversion from kml to gpx, but unfortunately it appears that GPSBabel has a bug when converting dates between these formats in that the date doesn’t not get adjusted when converting to UTC (the above would become 2015-08-07T04:00:03.347Z – with the date still being the 07 rather than adjusting to 08). However, I found a workaround for this problem by using http://kml2gpx.com which allows you to upload a kml file and then download the (correctly) converted gpx file.
I was able to then load the resulting gpx file with your plug-in. The results are definitely mixed. I don’t know how this compares to a dedicated smart phone tracker app, but the accuracy varies substantially (accuracy can be seen on Google’s timeline page by showing the raw data and then selecting a point) – I suspect Google falls back to less accurate location techniques than GPS at times. Overall though, I would say about 80% of the geocodes were good. Since it is fairly easy to see/select locations that are clearly off on the Lightroom Map page, most of the errors are easy to correct.
Thanks for the great plugins – writing from just outside Washington, D.C.
A dedicated tracklog app would likely make everything much easier and more accurate, but perhaps kill your battery more quickly. It also requires that you remember to turn it on before you start, which the method you outline doesn’t require, so this could make a good backup strategy. —Jeffrey
Jeffrey, Thanks for the super awesome useful plugin. Soon as I get a bit of money in my PP account I’ll send you something.
Is there a way to extract the Map URL that I see in the Geoencoding preset into the real world? Especially as a batch command. Thanks.
Clicking on it should open the url in your browser. You can export it via the LR/Transporter plugin, via “info.regex.lightroom.gps.map“. —Jeffrey
Jeffrey, Hello again. Is there a way to clear the Map field so that I can regenerate a new map URL using a different mapping site? i.e. Openstreet instead of Google. Thank you.
Peter
See the “Etc” tab of the Geoencoding Dialog. —Jeffrey
Jeffrey,
I’m almost there. I’ve gotten my Map URLs written in LR into the tab called Map. I’ve loaded
L/RTransporter as you have suggested, but I can’t seem to get it to recognize the Map field for extraction. It works fine on standard EXIF to IPTC data. When I ask for {Map} I just get some ??? retuned. Is {Map} the correct request?
Many thanks,
Pete
No, not {Map}. See my previous answer for the proper token for Lr/Transporter. —Jeffrey
Please explain in detail how this can be done? And which field is best to use for the storage of these data?
Clicking on it should open the url in your browser. You can export it via the LR/Transporter plugin, via “info.regex.lightroom.gps.map“.
I don’t know what you mean by “these data”. With LR/Transporter you can export image metadata, including plugin-specific metadata like the Geoencoding-support Maps link. That link is referenced internally by Lightroom as “info.regex.lightroom.gps.map”, and I believe that you can tell Lr/Transporter that. See that plugin’s docs for specifics. —Jeffrey
I understood. Peter was to export data “Geoencoding-support Maps link” to an external file. But i wanted to keep the “Geoencoding-support Maps link” inside the photo, in metadata photos (IPTC, XMP, etc) 🙂 In any case, now I know how to do both. Thank you, Jeffrey!
https://yadi.sk/i/d2l5Sv4Njm77K
Sorry for my english. I use Google translator.
How does the location name in Reverse Geo work? I haven’t been able to get the Airport, Point of Interest, Park etc. to work reliably. Most photos are being located to the nearest street address, but not the nearest place. As a result photos located inside buildings or at places are given a street address for the Sublocation. Is it possible to have the Sublocation be set to the nearest place (airport, POI etc.).
The left side of the Reverse Geo tab lets you choose and prioritize what kind of fields you want considered. —Jeffrey
I too can’t get this to work like I would like, which is to have the neighbourhood or some other point of interest returned rather than a road or street address. I have played with hierarchy of the various settings but it mostly gives just a road or street address.
Google’s data can be spotty. For example, in one part of Kyoto Station it gives an extremely detailed hierarchy, down to being within the train station. But another spot 100m away doesn’t even get as specific as “Kyoto City”. You can see the raw data returned by Google in the “One-by-One” tab… it may just not have anything more specific than a road address range for your location. —Jeffrey
Hi Jeffrey,
great plugin, great as the others I also own :).
I have a question/suggestion.
Recently I was in Scotland (UK) and took some pictures.
If I use the Lightroom CC suggestions the State/Province is filled with Scotland, If I use your plugin the State/Province is filled with the Province, let say Highlands. I would prefer something like”Highlands, Scotland” this is show in Google Lightroom map view as the location. Do you think this could be implemented.
One coordination of a photo is:
57°58’52” N 3°56’33” W
The name Scotland is in the administrative_area_level_1 returned from Google.
Maybe you could make a option where the user could decide which fields should be used for State/Province?
Thanks for the great plugin
Markus
I’ve come up with something that makes sense, I hope… I get rid of “Great Briton” altogether and promote “Scotland” to the country spot. I also hopscotch over “Greater London” so that you might get a tuple like “England / London / Westminister”. London is not a state or province, of course, but that tuple seems to be the most practical. I’ve just pushed this new version out. —Jeffrey
Hi Jeff and thanks for your great work !
I’m discovering the geoencode plugin and I ‘m looking for the possibility to copy all the location information in the keyword field. Is it possible ?
Thanks for you help 😉
If you’re talking about getting the location data into the keyword field of exported copies, you can use my Metadata Wrangler plugin to insert catalog data into keywords. My exporter plugins generally have that feature built in as well. I don’t know of an easy way to get the data into Lightroom’s catalog itself, though. —Jeffrey
Lightroom is a great program for fine tuning images but it’s keyboarding and general metadata methods are less than ideal. Thanks to people like Jeffrey for making LR that much more functional. The best overall keywording and metadata program I have found is Expressions Media. They seem to be the only ones who get it when it comes to keyboarding and handling all aspects of metadata. It’s quite easy to copy location data to the keywords or almost any EXIF or other metadata for that matter. It’s also better at catalogues than LR but its not LR. I shoot stock and we live and die by our metadata. I end up going back and forth. I process images and output metadata to them. I import the same image with EM, then do all my keyboarding etc (its about 50x faster) and write the new data to the images, then re-import the data into LR. Both LR and EM are pretty good and drag and drop large clusters of media into ftp folders etc. I wish there was one program but there isn’t. EM is easy to script in so lots of ways to handle things.
For keyboarding, LR is like having a crayon and construction paper where EM is more like a computer.
I absolutely love this plugin and use it regularly, especially to update GPS coordinates in case I had the tagging switched off on camera.
However, I lately run into the problem that the plugin seemingly can’t access the coordinates marked by the crosshairs in google earth. In the plugins “Geoencode Static Location” Tab the “Import Locatoin from Google Earth” button shows “Fetching…” for a short time, but no coordinates are imported. The “Geoencode selected Photos from Google Earth” command from the file-plugins Menu yields the error statement “Can’t get location from Google Earth”. Do you know this problem?
I reinstalled the plugin as well as google earth, but the problem persists. I am running plugin version 20151103.262 on a LR 5.7.1 on Win7.
Thanks for any hint, Peter
Unfortunately, it just doesn’t seem to work for some folks. You might try Google Earth Pro (or if using Pro, revert to the non-Pro version) and keep your fingers crossed. Google no longer supports the kind of access that the plugin needs to get the location from Earth, so either it works or it doesn’t, and I’ve not found any kind of pattern. —Jeffrey
Hello Jeffrey from Roanoke VA.
I have been using this plug-in for years and love it. I have all my photos geoencoded with your plug-in. Unfortunately the loss of Google Earth support has caused me lots of problems. I know you have been struggling with this for some time now. But I am struggling with the best way to load preset locations without Google Earth. I have found a way but it is very convoluted. I had many presets saved but recently upgraded to Windows 10 reinstalled Lightroom and lost all my presets. I have been trying to re-create them with my convoluted approach. I still have a saved copy of the Windows 7 image. Where would the presets be saved for your plugin? I have search but have been unable to find them. I am now saving the presets as a text file so this doesn’t happen again.
I hope you can find another way to semi-automatically load coordinates within the plug-in by searching for the address or location.
Thanks for your help.
Chuck
The plugin saves its data in Lightroom’s preferences file, so that’s where they’d be. I initially created the Google-Earth integration because Lightroom didn’t have its own mapping stuff, but now it has the Map module. When geoencoding from a tracklog my plugin is better than Lightroom, but for drag-n-drop on a map, I just use the Map Module with all the images open in the filmstrip. Have you tried this approach? The Map Module also has its own preset mechanism. —Jeffrey
Would it be possible to reverse geoencode locations from WikiMapia? There are tons of well annotated outlines there.
Maybe. When I first looked a couple of years ago, their API was no appropriate to do this. Looking again now I see it’s
a bit different with extra information returned that the plugin could use to differentiate appropriate results from irrelevant ones. I’ll add further investigation to the todo list… —Jeffrey
Is it possible to prevent this plugin from showing up in the lower-left of the export dialog? It displays a no longer needed ‘old shadow injector’ which unnecessarily shrinks the Preset list in the upper left (I have no other post-process actions installed).
Thank you very much for your great plugins.
Good point… I’ve removed it for Lr6 and later. —Jeffrey
Love your Geoencoding plug-in, however, the Fast Full-Catalogue Proximity search no longer works under CC/6 on a Mac. Whenever I run it it gives me zero hits. If I highlight a particular image made in a museum together with hundreds of others (all having GPS coordinates) and perform the search I get no hits. I have used this facility in the past and it worked fine then.
I’ve gotten one other report like this… for some reason, the database is locked so the plugin gets no results. I’ve pushed out a new version of the plugin that reports better what is happening, but I don’t know whether the lockage is something here to stay or transient. It still works fine for me, though I am still on 10.9, so maybe that has something to do with it. —Jeffrey
Jeffrey
There are times when I neglect to capture the GPX file on my iPhone and in those cases, I want to be able to at least enter a static location. Sometimes I take a single picture with my iPhone and reference nearby pictures to that. Sometimes, I only have a verbal description of the location which I can search in Google Earth, and I used to transfer coordinates from Google Earth with your plug-in, but that doesn’t work any more. So I tried to copy over the coordinates from Google Earth manually, but didn’t remember which (of many) formats to use. I tried the help entry on the screen, but it did not show a complete lat or lon entry. I am totally out of luck. Plug in ver -263, Lightroom CC 2015. Please help me.
It seems that Google changed the location format that Google Earth’s “Copy View Location” function fills in the clipboard with; I’ve just pushed out a new version of the plugin that understands it, so you should now be able to put the mouse over the proper spot in Earth and Shift-Command-C, then paste into the plugin’s static-location field. —Jeffrey
Hello occasionally i would like to use KML output produced by my android phone (and recorded by google location data) however I am unsure what arguetns I need to provide to correctly translate the data…
I’m not sure either, sorry. Some KML don’t even have enough data (timestamp + location). —Jeffrey
I am detailed oriented enough to be geeked-out over the detail of your Geoencoding Plug-In. Thanks. Some topics that I don’t seem to find an answer to on your posts about your product.
a) Configure to use multiple KML files – I have 200+ locations in a KML file and it is not easy to manage such with GE. I would like to have sub-folders in GE such as “homes” “Parks and nature areas” “Museums & Monuments” etc. and export them all to your plug in. But it appears your plug-in supports one local KML.
b) Configure network KML – How does this work? Can I used this to configure multiple KML files in a directory on my home network? Does this resolve “a” above?
c) Fill Elevation – When elevation is not provided by Google in the KML file, would it be possible to have this to default to a null value instead of “0.0 ft”? I now have hundreds of files with “0.0 ft” as the altitude and have found no way to sort by this metadata field or to find/delete this elevation value.
You should be able to create folders within your one local KML file. You can even use Earth’s default “myplaces.kml” file, at least if you have no other named polygons that you don’t want to be considered by the plugin. The “network KML” thing is a link to a KML (or KMZ) file on the internet, such as from your Google Maps “My Maps” share screen. I don’t think the plugin fills in with 0.0 ft (the plugin uses only meters anyway), so I’m not sure where that might be coming from. —Jeffrey
Hi
I love this plugin
I am trying to automate this workflow as much as I can without adding more apps to my phone – I have location history for google enabled
I tried adding the https://www.google.com/maps/timeline/kml to the url on the first tab
This does not work as its a kml file – whereas if I point the same dialog at the downloaded kml from the same url the gpsbabel support translates and uses it just fine
I am just setting up an apps script to collect kml files to my pc synced drive account, so I can point to them. Supporting multiple files is a great feature – seems typical of Jeffrey’s comprehensive approach
However I wondered if it would be feasible to allow the url to work directly and pass the kml to the gpsbabel program
The google url only downloads the current day.
It is possible to pass a date to it and what would be amazing, making it totally automated would be a days back dialog to download multiple kmls and gpsbabel them
for example date (2015-09-01) the URL needs to be
https://www.google.com/maps/timeline/kml?authuser=0&pb=!1m8!1m3!1i2015!2i8!3i1!2m3!1i2015!2i8!3i1
of course this relies on your auth cookie on your browser
More details of folks using the url are here
https://stackoverflow.com/questions/32335114/extfiltrating-google-location-history-from-timeline
I’m reticent to work on this, both because Google has a history of suddenly shutting off this kind of service, and because the data is such a low resolution as to not really be worth it. —Jeffrey
Follow up to 2/20 post….
a) Meters vs. Feet – I took a file with altitude metadata value listed in feet. Deleted that value and re-ran the “Fill Elevation” from the plug-in. The plug in loaded an altitude value with “ft” as the reference, not meters.
b) I deleted an altitude metadata field that had “0.0 ft” and applied the “Fill Elevation” and the plug in filled the box with a value greater than zero. Presumably the “0.0 ft” entry come from another plug in the I evaluated, or something was corrected when the router went off line the other day while I was running “fill elevation” on about 20,000 files….
c) To run a sort on all files with “0.0 ft” altitude, I attempted to run John Beardsworth “List View” plug in, but am having some technical difficulties
George
I’m a bit confused as to what we’re talking about… Lightroom displays altitude only in meters, and the Exif metadata standard allows for encoding only in meters, so any display in feet would be something out of Lightroom making its own interpretation (which may include interpreting “no information” as “zero”… I dunno). You can use my “Data Explorer” plugin to isolate photos with specific altitude values. —Jeffrey
John.. Re using KML from Android
I use it and it works really well for me. Android collected location data is pretty good to be honest.
I am trying to automate my workflow so I have used linux scripts to collect the files, which I am happy to share with people…
However you don’t need to go to that level of sophistication from the start…
The simplest method is..
Ensure GPSBabel is installed
Ensure GPSBabel integration is set up as follows
Geocode plugin Tab 1 “Geocode from TrackLog”
Ensure tracklog file is selected
In the config button under the browse tracklog file button add the following
row 1 KML -i “kml”
Now you want a KML file…
I did all my images first time – 60k of them…. So I got the KML file downloaded from google takeout https://takeout.google.com/settings/takeout
This takes a while if you have years of history – my file was 200mb
However for most imports I only want the last 24 hours of location history….
Just visit this url https://www.google.com/maps/timeline/kml or https://www.google.co.uk/maps/timeline/kml for the uk
Assuming you are logged you just get a KML file with the last 24 hours or so data
You can pass extra parameters to request a few days at a time (see previous post)
You can then point the plugin page at the KML file or Files (very handy multiple files Jeffrey!)
The plugin deals with the conversion and uses the GPX output from gpsbabel
I have created a linux script to collect my location file once a day and store it on my nas with the same file name. Point the plugin at that fixed file name and its automated to import photos you took in the last 24 hours. I am working on a script to collect a rolling few days worth
If anyone is interested in how to do this – just ask
Thanks to Jeffrey for such an great plugin
Regarding the feet vs. meters display in LightRoom……
I Googled that, and came across a post on one of Adobe’s blogs that says that LightRoom honors the operating system region setting. I couldn’t find a setting specific to distance or elevation, but if I changed the Format setting in Region from English (United States) to English (Canada), Lightroom displayed the elevations in meters.
This is on Windows. Don’t know how Macs handle this.
Oh, okay, I guess they added this since I had access to the source code, because there was no mention of “feet” then. Looking in the current Lightroom binary, I do see “ft”. Learn something new every day. Thanks. —Jeffrey
Last follow-up – I promise….
I resolved the 0.0ft issue by re-running the Fill Elevation with the box checked for “Even when there’s already an elevation associated with the image”. Numerous verified examples switched from 0.0ft to a reasonable elevation for the region……
I really enjoy this plug in. I’m using sub locations, elevation, and time zone features. I plan to use the track log feature in conjunction with the Babble app to translate phone app data for FitBit and MapMyWalk/Run.
I’m also in process of configuring Metadata per your other cool Metadata Presets plug-in.
Hi! Is it possible to use the plugin in order to refresh all the reverse geocoding information and (and possibly altitude as well) based on the existing GPS coordinates?
Also, I have a significant amount of photos in JPEG format along with an XMP sidecar file containing the location data for those photos. Lightroom ignores the XMP sidecar files for JPEG images, so I haven’t been able to import that data into Lightroom yet. Does this plugin have a way for me to do that without having to handle each image individually?
Thank you!
Yes, the plugin can refresh location/city/state/country data via the Reverse Geocoding tab. I’ve never heard of XMP with JPEG (JPEG can hold the data directly inside), but you might be able to find some incantation of ExifTool to move the data from the XMP to the JPEG, which you can then import back into Lightroom. But take care… importing data from an image into Lightroom replaces all data that Lightroom had, including develop data. So be sure to save the metadata from Lightroom to the images just before moving the location data from the XMP to the JPEG…. —Jeffrey
Thank you for the reply. About the XMP for JPEG, you’re totally right. It’s not very common since the data is usually embedded into the JPEG file itself, but there are some situations where it might be used. I have all of these from when I exported my old Aperture library in order to migrate everything over to Lightroom.
I considered using ExifTool in the past, but I would prefer to leave the original JPEG files untouched.
Thanks!
You can import XMP sidecar data into JPEGs in Lightroom without losing your edits by right clicking on a JPEG in Lightroom and choosing Metadata, and Read Metadata from File. Usually this does not change your develop settings unless you also had edit data in the sidecar files (not common unless you are using an app like LRTimelapse).
Really, it reads XMP sidecars associated with a JPEG? I thought I explicitly tested this (many years ago) and that it did not work, but perhaps it’s changed or my memory is mistaken… —Jeffrey
I just tested that again on the latest version of Lightroom CC (2015.5) and it didn’t seem to work for JPEGs :/
I could be mistaken and I’m thinking of another format, but I was pretty sure I’d done it for GPS data before (not edits). I can’t find the files now though to try again.
Hi, great plugin, but I’m missing the option for Swedish as a result from the Google Reverse-Geoencoding options. I beleive it was there in earlier versions? As an example, I would like to get “Göteborg” and not “Gothenburg” for 57° 42′ 25″ N, 11° 57′ 59″ E
Link below says Swedish results are supported, right?
https://developers.google.com/maps/faq#languagesupport
Swedish wasn’t supported the last time I’d checked that list. It looks like they’ve added it and a lot more since. I’ve just updated them all. —Jeffrey
Yes, I was able to do this with JPEGs with LR 2015.5 with images from my Theta S last week after creating .XMP files with LRTimelapse. The trick is to sync the folder the JPEGs are in and check the box to also look for metadata changes. Then you can right click on the JPEGs and import the .XMP data.
Hello, I’m in the north-east of England, UK. I’ve been a big fan of geocoding for many years – digital photos are stamped with WHEN they were taken, so why not WHERE they were taken.
Anyway, just a simple question to see if there has been/is likely to be, any progress on the “Jeffrey’s Proximity Search: couldn’t access Lightroom database: Error: database is locked” problem with the “Fast Full-Catalogue Proximity Search”. I get the locked message each and every time I try to use it.
I’m on OSX 10.11.5 and LR CC 2015.5.1/9.5.1 (i.e. the latest version of each).
Thanks.
I think the answer to the “why not WHERE?” question relates to the cost difference between a run-of-the-mill clock and a constellation of cutting-edge satellites. Even today, a satellite receiver built into a camera runs into plenty of issues that can make it wrong (which, let’s remember, is worse than absent). About the locking thing, no, sorry, I’ve no idea why it doesn’t work. I fear that it might be related to the OS version, and that I’d lose the feature when I’m forced to upgrade from 10.9. —Jeffrey
Hi, returning from a 3 week trip in China, I noticed that my camera date was not set correctly! It was set to June-2000. I took a picture now and saved the true time, so it is possible to calculate the exact amount needed to shift all photos date & time. The precise shift I need to perform is 21/07/2000-9:15 to 05/06/2016-21:55, i.e. 14 days 11 months and 15 years, 11 months, 14 days, 12 hours and 40 minutes.
However I see only a shift option in seconds in the plugin…
It would be much better to correct the dates… see this tutorial on how to do it. Once you’ve done that, you won’t need the shift option. —Jeffrey
In reply to John Ws question about database locking…
Back in 2013 when Jeffery introduced his “Fast Full-Catalogue Proximity Search” he encountered the same locking problem on Windows and asked if anyone knows about a work around
In this comment http://regex.info/blog/2013-10-11/2319#comment-50459 I described a way (on Windows) to open a sqlite database in “Write-Ahead Logging” mode, which allows concurrent access to the Lightroom catalog. Maybe that’s also helpful in your situation on OSX
I had forgotten about this, thanks Jacques. I can confirm that it works on OSX as well. I will have to revisit whether I can somehow integrate this into the plugin (with some kind of “please restart Lightroom…” flow). —Jeffrey
Thanks Jeffrey for the answer and tutorial, however this Lightroom operation changes the time & date of all the selected images to the SAME time & date for all of them. This is obviously not good because then GeoTagging according to GPS log would be meaningless…
Searching further I found few more tools, but most of them supported shifting the time by up to several hours. Finally I finally found a tool that supports SHIFTING the time & date of entire images folder by a specified amount, including years, months, days, etc. If anyone would need it, the tutorial uses ExifTool is here:
http://petapixel.com/2012/11/05/how-to-fix-your-timestamps-if-you-forgot-to-update-your-camera-for-daylight-savings/
Note that the Tutorial is not perfect, and in order to achieve the effect I had to use the ‘AllDates’ switch instead of the ‘DateTimeOriginal’ (see the manual page), and had to run the cmd window under Admin(!) privileges (for Windows users).
Thanks, Koby
I think you’re mistaken… when you select a group of photos and tell Lightroom to adjust their time by indicating the correct time for the most-selected photo, the times for the other photos are adjusted by the same amount, not to the same time. I used this feature today, as I do every time I use my cycling camera because its clock is crap and can’t hold the time. The correction via Lightroom worked correctly. —Jeffrey
Thanks Jeffrey, I didn’t actually try this feature in Lightroom, I just read the tutorial, and it wasn’t mentioned clearly there. However reading the smaller text on the Lightroom screenshot I see it now. And if you’ve tried it and use it occasionally, I believe you. Thanks for this method! It’s easier than the command line 🙂 –Koby
I have an idea/wish 🙂
in a Building there is no GPS-Fix, but when the point before and after are “close” together you optionally could take the center between them…
Thanks for this wonderful applikation.
When i do reverse geocode look up, it seams that i reach very fast my limit. When i read at google, i can switch it up to 150000 per day when identified with my account. Is this possible, or better what can i do that this is working?
Thanks to you
Hans
ps. i trie to reorganize my datas therefore i have mor then 1500 per day
The plugin uses its own private API key. On the dialog where you actually launch the lookup, there’s a slider where you can tell the plugin what “close enough” is for it to just use prior data. Maybe relax that a bit? —Jeffrey
Hi Jeffrey,
For the reverse geo-encoding is it possible to return results with both the native language as well as the language (American English) I’ve selected in the plugin? For example, the plugin gives me “Truck Saga Station” when I set the language to English but “トロッコ嵯峨駅” when I set the language to Japanese. Is there any way I can get both, like “Truck Saga Station – トロッコ嵯峨駅”
Thanks from Chicago,
Michael
Not easily. As best I can tell, there’s no way in Google’s API to ask for the language local to the place you’re checking, which perhaps makes sense because it’s not necessarily something easy to determine (and could open up a big can of political worms). But then, even if there were, we (I) face the problem of how to integrate it into the plugin, and the question of whether it’d be worth it from a general point of view… —Jeffrey
Hi Jeffrey,
I’m facing an issue when trying to geotag my most recent trip. I pulled the kml the same way (day-by-day) from Google Maps as I did for a trip in June, but I now get the error “Tracklog Error: unable to run GPSBabel”
When I follow the error log it comes with the output “kml: There were more gx:coord elements than the number of when elements”
I tested this further using the original June 13 kml I saved a few months ago and it still functions as expected, but if I download a new June 13 kml from Gmaps I get the error. Are you aware of something changing in Google’s kml files that is causing this to break?
Cheers,
Curtis
No, sorry, any running of GPSBabel is something you would have configured, so I’m not familiar with what it might have done in the first place, much less what might have changed with whatever input you were giving it. —Jeffrey
Hi Jeffrey,
I’ve noticed that the geotag info is not saved to the actual images when I geotag them with your plugin in LR. I can see the geotag (GPS) data in LR after I geotag the images, but cannot see it in windows explorer, exiftool, or any other tool, so I conclude that the data is stored only in LR… Am I right? I even duplicated an image that I’ve geotagged and re-imported the copy into LR, and the copy didn’t have GPS data (the original did have).
I’ve always thought your plugin writes the geotag data to the images themselves (so if I send a geotagged image to a friend or upload to some website, the GPS data will be available there)…
Am I right or am I missing something here…
If that’s the way it indeed works, is there a way to write the GPS data from LR to the images’ metadata?
Thanks,
Koby
Other than updates to the capture time, Lightroom doesn’t write any info back to the original file unless you invoke “Metadata > Save Metadata to File”. An important part of many workflows is that original images remain absolutely unchanged, but if that’s not your cup of tea, you can write many changes back this way. —Jeffrey
Have you considered adding support for any additional reverse geocoding API’s besides Google? It is apparently Google’s policy to not reverse geocode politically disputed areas. I am interested in the Jammu and Kashmir region, disputed by India and Pakistan. Apparently there are other tools that will reverse geocode such disputed areas.
This one even includes a ‘political view’ option:
https://developer.here.com/rest-apis/documentation/geocoder/topics/political-views.html
That’s a worthy reason, but even then in the face of my already-top-heavy todo list, probably not enough to justify the extra work (which is a lot… these things never go smoothly….what works for one part of the world tends to fail for other parts). —Jeffrey
Hi Jeffrey
Can you please comment on how you keep your time zone data in sync when you edit files. I am using non-exif data, and every time I export to Photoshop and then re-import that photo to Lightroom, I have to remember to synchronize the metadata fields. This is basically an easy way to lose information, because if I forget to synchronize on import, then it is difficult or impossible to synchronize the data later. Do you have any tricks that I can learn from?
FWIW, I have been using the Instructions field to hold a string with the time zone, but this has its own set of issues. Among them, it is basically impossible to search this string in Lightroom. But at least that field is kept when I export to Photoshop and reimport into Lightroom.
Timezone stuff is so screwed up with image metadata. Sigh. The people who created the initial metadata standard (a consortium in Japan) were total idiots, and Adobe has continued the tradition. Sigh. To answer your question, I don’t know. The plugin keeps the timezone as a bit of private per-photo metadata, and it’ll be replicated to the copy if you “Render in Lightroom” when going to Photoshop, but beyond that maintenance is all manual. —Jeffrey
Hey Jeff – thanks for this plugin! I’m trying to use my tracklog to geocode some files and it’s failing on roughly half of them. The error report has things like:
But the recorder has points every 5 seconds, and that shows up in the raw data viewed as well. How come it isn’t finding these other points? I’ve verified the times of the files and the timezone to use, so I’m not sure what’s going on here… Any help appreciated!
I wonder whether it’s an issue with how the GPX file is created. Would you mind mailing it to me? —Jeffrey
I’m getting the “Database locked” message too when I try to use the “Fast Full-Catalog Proximity Search.” I am using Lightroom CC 2015.6 and Mac OS X El Capitan 10.11.6. Let me know if I can help you track this down. This is the first time I have tried this command, so I wouldn’t know if it worked in the past.
It seems to have broken with OSX 10.10 or 10.11… not sure which. I’m digging around for a workaround….—Jeffrey
Hi Jeffrey,
Thanks for the great plugin!
Is there a way to embed the GPS data into the actual photos’ metadata?
A way that will not change the photos’ creation time?
Thanks from Israel!
Koby
I think if if you “Metadata > Save Metadata to File” it would do what you want, but I haven’t tested whether it leaves the file creation time alone. If not, you may need to then run an exiftool pass to reset the file date to the creation date. —Jeffrey
Thanks Jeffrey!
It worked! and the creating time hasn’t changed!
Thank you very much! -Koby
Hi Jeffrey,
I have a feature I think may be useful for your great geoencoding plugin:
When geoencoding the pictures from my last trip to Sicily I noticed some pictures didn’t get GPS data, due to lack of GPS data in some time intervals in the GPS log. I noticed that those pictures where mostly on occasions when I entered some shops or restaurants and the GPS signal was missing. But then the log resumes roughly from the point it left off when I left the shop (I saw a difference of about 3 meters on some occasions I’ve checked).
I wonder if you could add some mechanism that will identify cases where there’s no GPS data for some interval but the last location before this interval and the first location after this interval are very close to one another and in this case assume that the position stayed the same for the entire interval and therefore the plugin would give the entire interval the last known position (or interpolation between the points if you want to do the math :)). I would say 5 or 10 meters difference could be regarded as close enough, but this could be left as a parameter for the user to choose (because longer periods without GPS data could cause longer wakeup time for the GPS, so when you finally get out to clear sky during this time you walk longer distance from the shop/restaurant until the GPS has fix. I could try and measure some statistics from my last log to calculate distance for different periods of non GPS signal if you want me to).
If possible for you, and if you think this is useful (like I do), I would perhaps put this as an optional feature for the user to choose if he wants this or not (just in case some users won’t want this).
What do you think…?
Thanks,
Koby
The problem is that while you’re out of GPS range taking pictures, you could move very far from the last signal. For example, entering a subway system and moving to far-flung places underground, then returning back to the surface at the same station. The GPS pattern would look identical to the case you mention. It could be made as an option, but the effort doesn’t seem to justify the can of worms it’d open up, sorry. —Jeffrey
Thanks Jeffrey for your honest reply. I agree this can be confusing in some cases, but I think that in most cases this could be useful. I may try to write an offline tool that will receive a GPX file and will output a GPX file with GPS gaps filled. I would then be able to use this file as an input for your plugin.
Let me know if you find it useful and I will send you the tool if I succeed to do it.
Thanks,
Koby
You can co that easily with GPS Babel, if you like. —Jeffrey
Do you mean GpsBabel has tools for filling GPS gaps, or should I use it just for reading/writting the GPX files…?
Thanks -Koby
You can use it to fill in gaps prior to loading the GPX file into the plugin. —Jeffrey
Thanks Jeffrey! This looks great, but it implements a slightly different gap filling condition than the one I intended: It interpolates the points for any time gap that is more than the specified interval, regardless of the distance between the points…
This misses the point I intended.
I saw there’s an option to interpolate by distance, but saw only max distance and no min distance (i.e. interpolates if the distance is BIGGER than specified and not like I want it, if the distance is SMALLER than specified).
Do you know other operations in GPS Babel that can perform the condition the way I wanted it, which is much safer…?
Thanks! -Koby
Ah, good point. I’ve gone ahead and added it, though it defaults to being turned off. You’ll find it on the Tracklog tab. —Jeffrey
Thanks Jeffrey,
I’ve managed to write a small tool that does exactly what I wanted, using Python.
It can run as a command line and get the input and output GPX filenames, minimum time interval to fill, and maximum distance difference allowed to fill. I’ve checked it on my data and it worked fine.
Let me know if you want me to send it to you, in case you find it useful or can help other users.
I can compile it to EXE for users who don’t want to install Python on their machine.
-Koby
Is there any way to pull GPS data from Flickr or other sites that are linked with lightroom and your other plugins? It seems that I have somehow lost all my geotagged data from lightroom, but it still remains on the web.
I haven’t built that, sorry. The “somehow lost all my geotagged data” sounds very scary… I hope you can get to the bottom of what happened! —Jeffrey
Hi Jeffrey,
I’ve started using your LR plugin for reverse geocoding purposes. It does its job very well. Thank you for creating and sharing.
I’ve found out that openstreetmap data source performs better than google’s. Example:
Google: http://noc.to/geodecode#44.2930533,15.4603983
Openstreetmap: http://nominatim.openstreetmap.org/reverse?format=json&accept-language=en-US&lat=44.2930533&lon=15.4603983&zoom=18&addressdetails=1
You get a lot more detailed location with openstreetmap, than with google maps. From my example I get exact path and viewpoint with openstreetmap “viewpoint”:”Paklarić Fort”,”path”:”Paklarić Educational Trail”, while google returns only meaningless address. Is/Would it it be possible to change reverse geocoding provider in your plugin?
Kind regards from Slovenia,
Tadej
I just added this in, though probably broke things doing so. Give it a try. —Jeffrey
I’m in Spain and having a problem with UK reverse lookups. For example, with 53°54’12” N 1°42’20” W, the State/Province and Country both get filled with England. I was expecting the State/Province to be West Yorkshire. Many thanks and please keep up the good work.
Yeah, Google things the “country” is “United Kingdom” and “state” is “England”. I’ve special-cased a fix in the version I just released. Thanks for the report.—Jeffrey
UK Country and State/Province now working properly on latest release (20161126.273). Now, if only Google could be a little more accurate with the Sublocation.
Many thanks,
Mike in Spain.
After updating the buttons to do the geotagging seem to have disappeared. Any idea whats up?
Writing from va, usa.
Thanks!
Apparently the plugin thinks your screen is big enough… it’s probably an issue with how high-res screens are reported, which seems to be an issue in flux. I’ve just pushed a new version of the plugin that’s less aggressive here. —Jeffrey
Just updated to 20161129.274 and now the Reverse Geo tag doesn’t fill the frame anymore, so it needs a scroll to get to the action button, no matter which Terse setting used. Plus, the “dismiss dialog when finished” checkbox has never had any effect for me.
Regards,
Mike in Spain.
Unfortunately, Lightroom’s plugin infrastructure makes large dialogs problematic, and the best one can do design content that you hope will fit on every user’s screen (even though you have no information about their screen, how large their fonts are rendered, etc.). The end result is something that’s ugly for everyone, but also hopefully at least works for everyone. About “dismiss dialog when finished”, that’s a surprise. Could you give it a try with the new version I just pushed out (20161206.275 or later) and send a log if it doesn’t work? Thanks. —Jeffrey
the latest update presents a dialog box that is too big for my screen (4k screen with mgnification)
There’s an option in the Plugin Manager that should force smaller dialogs if the plugin couldn’t detect it properly. —Jeffrey
terse dialog screens is enabled… This worked before recent update…
Please send a plugin log along with a description (or perhaps a link to a screenshot). —Jeffrey
First of all – love the plugin! Makes my life a whole lot easier when I finally get around to geotagging my photo’s to be able to import more than one track!
Anyway, I was going to suggest using the OSM API, but see someone beat me to it – and it’s presence in the latest version is certainly welcome – it seems to provide a more reliable, sensible output here in my part of the UK (Plymouth).
I am however curious as to how the list of options for the “fill in location” option of reverse-geo are chosen? It seems to me that there’s a somewhat arbitrary list of not particularly useful things the plug-in is looking for, which in my case only results in one or two of them finding anything (normally road and suburb). As an example, a lot of my photos have been taken in a local national park (Dartmoor, specifically). Given the nature of National Parks, I would have thought they’d be a common option for “Location” tags, particularly among landscape/nature photographers.
Meanwhile the plug-in is looking for (among other things) “Electronics”, which from what I can tell from the OSM Wiki would only be looking for electronics shops; not generally somewhere I see a lot of photographers, except when parting with their money for a shiny new piece of glass!
Depending on how the list is chosen, I personally would be looking for; boundary=national_park, natural=peak, place=locality, place=town and maybe place=village.
From what I’ve seen of your blog, the natural=peak might be particularly useful for you, and I’m sure with a quick look through the OSM wiki you could find some more useful tags yourself (maybe temples/religious buildings in general?)
Thanks again for the excellent plug-in and I hope my feedback is helpful!
Not sure how Electronics got in there, so I’ve removed it. The plugin just asks OSM for info about a lat/lon pair, and OSM sends what it wants (including, apparently, info about electronics stores, but not mountain peaks). Not sure I can do much here. )-: —Jeffrey
Just installed latest version of plugin 20161206.275 under LR CC 2015.8 on Windows 10. Trying to Geoencode Static Location -> Import Location from Google Earth (Google Earth v.7.1.7.2606 is running and pointed at my desired locatin) and plugin doesn’t seem to pick up coordinates. I’m happy to send more information and logs if you need them. Thanks.
Google Earth stopped supporting what the plugin is trying to use. It still seems to work for many lucky folks, but equally mysteriously doesn’t work for many others. I’ve never been able to figure out why. —Jeffrey
My last request seems to have been lost : Geoportail has changed recently, breaking all previous links, an update is needed. Thanks.
Oops, yes, sorry, I missed it. I’ve update the plugin… it should work again. Thanks for the report.—Jeffrey
Thanks for the French “O” (Ouest/West). I can save time when manually copying/pasting locations. Not perfect as it used to be but that’s already something… Cheers
I’m using the latest version (20170309.284) and the Geoencode page won’t fit on my screen and has no scrollbars. It makes it a bit hard to click on the “Go ahead and do it” part of the form 🙁
I am running W10 home v1607 (Microsoft Windows [Version 10.0.14393]) fully patched and LR CC (2015.9) If you need more info, just let me know… I’d be happy to help get this working (obviously)
Hope to hear from you soon!
Cheers.
Would you mind sending a screenshot (jfriedl@yahoo.com) and a plugin log? The problem here is that Lightroom doesn’t make it easy to know how big something will appear on the screen, so the best I can do is come up with heuristics for what seems to work. Clearly it’s not working for your system. With high-res displays, sometimes the effective screen resolution is half that of the actual screen resolution, and that silently screws everything up. —Jeffrey
Self solved the above issue. (couldn’t figure out how to reply to a comment)
Windows 10 seems to think that I want things to be %150 of actual size on my 13″ laptop, so it at one point in the update cycle figured that was the setting it would apply (and tell me was recommended)
I reset the zoom to %100 for everything and lo and behold – things fit as they should. Perhaps this can serve as a word of warning for others that run across this.
Thanks again for an awesome plugin!
I just wanted to say that Between Points is my favourite feature! How on Earth do you think no-one would ever use it? It’s essential for owners of cameras with no GPS installed! Pick two photos you KNOW locations for, and – after geocoding Between Points – just adjust photos’ locations manually, now that they’re roughly in the right area. It’s just too bad we can’t draw a spline on the map to define the path ;P
(Polish traveler here, BTW.)
My cameras don’t have GPS installed… I just make sure that their clock is correct, and then link up photo times with times in a tracklog I record on my phone or with a standalone GPS receiver. —Jeffrey
As a matter of fact, it would be a very useful addition if the Between function could:
(1) add a keyword (“geotag-between”, for example) for when a geotag is added using the function,
(2) be set to overwrite only geotags in photos that have the “geotag-between” keyword,
(3) upon detection of multiple manual geotags (not keyworded by (1)) split the job into segments and process each segment separately.
This way one could geotag a beginning and end photo out of 100, see them mapped in a straight line, guess the locations of several more photos basing on the Between mapping and correct them manually (removing the “geotag-between” keyword), and then re-run the whole set, now being split into several straight lines.
Of course, it’s already possible to do this by manually running the process on each section. This would merely make it easier. 🙂
1. Pretty sure there’s a minor bug in the View selected as KML in Google Earth. When the filename contains an & the KMZ is created okay but you get an invalid token error on load into Google Earth.
2. An option to create a KMZ file that loads into Google Maps instead of Google Earth would be nice. The current KMZ loads into Google Maps fine but you only get icons, not photos. If the plug in allowed writing the photos to the web (Google Drive or Dropbox or …) instead of local storage it might work??
Bill from Sedona, AZ, USA
You’re right about the first point; thanks for the heads up. I’ve just pushed a new version out. I’ll add the second item to the todo list, but realistically it probably won’t get attention any time soon, sorry. —Jeffrey
Hi Jeffrey,
Thanks for your blog and your pictures of Japan, and other places. I love it.
I use your plugin but have a problem to solve, if possible.
When shooting in B&W, I use a Garmin etrex Vista HCX and for each picture I generate a waypoint.
How can I use the .gdb or .gpx file with all the waypoints to geoencode the scanned pictures.
At present I use the route file to geoencode the pictures (date and time updated with jb CaptureTime to Exif)
Thanks again for your great job.
I don’t think waypoints have timestamps associated with them, so I don’t see an easy solution. You might manually view the waypoints in Google Earth, and copy/paste the location from there to the plugin. I don’t see a more-automated way without a tracklog. —Jeffrey
Hi Jeffrey,
I am looking for a solution to take the location fields that I have entered, street number, street, city and have a program find those addresses and add gps coordinates added to the metadata. I have, over the years, diligently added addresses to photos for a client, but not geotagged them. I use the primary address for the job even if I shoot the surrounding area. I could search each address in lightroom map module and drag the images on to the map, but I was hoping to automate this process somehow. Am I correct that I CANNOT do this with your plugin and if so, do you know if this is possible? Many thanks,
Oliver.
Yeah, sorry, I don’t see a way to automate it. )-: —Jeffrey
Maybe a bit of an outside case, can’t think of any of your plugins that would handle it, but:
I have thousands of photos all taken in UTC+13 (NZ). I then traveled across multiple timezones, DST kicked in, and some regions didn’t observe DST… so they are all left in NZ time, when they should actually be adjusted. I applied geotagging given they were all a consistent timezone, but now I’m wondering if there is a way to dynamically correct all their capture times?
They have GPS data, EXIF data, and an input timezone of UTC+13. Any way they could be adjusted knowing this information through some online date tool or something?
It may be possible, but it’s not likely. Timezones change all the time (their areas and the rules that govern their time), so for a location-to-timezone service to be accurate, it’d have to have a complex geopolitical history database. In any case, this conjecture doesn’t help you now. For that, it might make sense to view your photos via the Map Module, where you can visually pick out photos that are in such-and-such a timezone, saving them to a collection and updating their time in bulk… —Jeffrey
Hi Jeffrey,
I finaly found a solution to use a waypoints file to geoencode my pictures.
It is not straightforward but just a few “Search and Replace” jobs within the file and it looks like a tracklog file. And it works.
I tried to install your plugin, but my Norton anti virus objected to a couple of the dlls and would not install therm. Do you know what the problem might be? I am trying the free version (no donation yet).
I’ve heard occasional reports like this over the decade I’ve been doing this. There’s nothing bad in my zip files, so please report them to Norton and ask for clarification. I’d hope they’d investigate, discover that they are in fact fine, and update their software. BTW, there’s no “versions”. The same download is good for Windows and OSX, and is free. &madsh;Jeffrey
Hi Jeffrey
I would like to use 3 digit country codes and not 2 digit codes. Any chance to get a choice in your plugin for this?
Thanks, Michael
Google returns two-letter codes. I could try to map them, but then that muddies the UI. Since you’re the first to ask for this in the decade the plugin has been around, I’m not sure it’s worth it to the wider audience. How important is it to you? —Jeffrey
Hi Jeffrey
Your plugin works great most of the time.
I’m currently in Kazakhstan. Do you have any idea why the reverse lookup of addresses doesn’t work here?
Thanks
Massimo
I don’t know, but I suppose it’s related to what data sources Google has/uses. —Jeffrey
Hi Jeffrey,
I just ran your reverse geoencoding plugin on a bunch of images taken at Glasgow and they are all given the same street name in sublocation eventhough none of the images is actually taken on that street. I also seem to remember that we could specify the range in meters and km that Google would use to locate the data or am I now confusing it with something else?
You can specify the range of meters within which other photos being processed take on the same data. This helps avoid blasting Google’s servers and using up your daily quota. The quality of Google’s data, especially the many things that can go into the sublocation field, is wildly unpredictable as you move around the globe, or even within the same area of the same city. —Jeffrey
Hello
in the past when my standalone GPS logger failed to record a gpx track I would go to google and extract the info from my phones location data as recorded by google. Unfortuantely when i tried to this lately, in a number of different ways it says “datapoints in that tracklog dont have timestamps” is this a google issue? (i notice the interface is upgraded etc) is it the way i converted the resulting KML to GPX — Am i dont something wrong? Is there a workaround? hoping someone can advise me how to do this or help me get around the issue i am having.
eg do i have to convert to GPX? can a “json”? file be used?
or maybe i need to be trying a different plugin optins in my effrort to use the google info to geo-encode my images…
many thanks for tips you can suggest.
john
Google used to keep track of your location and make that available, but last I heard several years ago they had shut that down, so I’m not sure what feature you might be using. Whatever it is, it’s possible that it’s not exporting timestamps along with the locations, which means the plugin can’t do anything automatic with it. (KML/GPX/json/XML, etc…. the format doesn’t matter if the data’s not there to begin with.) FWIW, I record tracklogs on my phone with Galileo Offline Maps. —Jeffrey
SOLVED further to my gpx troubles. This is how i solved it. I use android app called location history viewer in this app i was able to select the whole month and export as GPX file, whinch the plugin rejected (data points dont have times tamps error) however i was able to get them all ge-encded in maps module., and they seem to have been coded correctly as far as i can tell. It was my first time using maps. It saved the day. Just thought i’d mention that in case it was useful to anyone.
I would be ecstatic if i were to resume using your plugin, as it has many more benefits and features .. please tell me if I can help test any fixes, or send you a sample GPX file from google location timeline to see if ther eis anything obvious as to why maps can read file but plugin thinks its invalid.
To show a GPX file on a map, the file doesn’t need to include timestamps on each location point… to show on a map, each location point merely needs the location. But geoencoding with a tracklog involves matching up each photo time with the same-time location in the tracklog, and that’s simply not possible if the tracklog locations don’t each have timestamps. It’s not that the GPX file without timestamps is “invalid”, but it doesn’t have enough information to be useful in automatic geoencoding. —Jeffrey
Hello Jeffrey,
I use your great plugins for a long time on my Windows 10 PC. Since a few days also the “Geoencoding Support” Plugin.
So far everything works well. However, I have a small “problem”: In the “Reverse Geo” tab, I usually have to click “Start Bulk Reverse Geocode” twice to start the function (mostly if “Overwrite” is selected).
And then I have another wish:
Could you please implement a function, which allows to copy the “reverse geo identified” places, countries, etc., directly into the keywords? With the ability to choose which fields are copied.
Thanks for the great plugins!
Best regards
Ulrich
That seems strange, about having to click twice. I’ve never seen that. Weird. About the keyword thing, it’s on my two-do list. The way Lightroom handles keywords makes it much less straight-forward than one might think, so it’ll be some work. —Jeffrey
How do I get your Geo plugin to stop bugging me about “Capture Time”? Such as when it encounters a saved .png file of a particular version of the original file like a Black & White.
Great plugin, thanks so much for this especially since Lightroom’s MAP doesn’t seem to work these days.
Richard Haas
I’m not sure what you man by “bugging”, but if you’re trying to geoencode photos via a method that requires the photo time in order to work, the plugin properly lets you know that it’s not able to perform the task with photos that have no time associated with it. If the plugin is doing something more intrusive or annoying, perhaps email a screenshot or something?—Jeffrey
Hi from Ireland ,
Fairly recently Google changed it’s api for getting map tiles is there anyway that the request could be modified to use the new API or possibly a different Map source? If anyone knows I would think it would be you.
The only other work around I could think of would be a proxy that rewrites the request fetches the data and then returns it to lightroom.
Or, just upgrade to the latest version of Lightroom. —Jeffrey
Hi, from Sweden.
After having re-registered the Geocoding Support plug-in a few minutes ago, I find that the Plug-in Manager’s left pane tells me that the plug-in is disabled, while the right one tells me that the plug-in is unrestricted.
I have found no way to enable the plug-in.
What to do?
Check inside the “Status” section of the Plugin Manager… there’s an “Enable” button there. —Jeffrey
Hi Jeffrey,
Just upgraded to the latest Lightroom CC, now called Classic. It seems that the “load static location from kml” option from the Static Locations tab is gone since the upgrade. I have added the kml file on the reverse goe encode tab as before.
Nothing about the Lr upgrade should have affected this, unless the upgrade didn’t bring your preferences over. And even then, the option should still be there…. a button on the left of the Static text-input field “Load from One-by-One…”. (Now that I look at this, I realize that the label should be “Load from Reverse Geo KMLs”, so that’ll be fixed in the next release.) If you’re not seeing it, perhaps send a screenshot? —Jeffrey
I was wondering if the following is supported in metadata tags
{Title|Caption?Title|Caption “,”}
I’m not exactly sure what you’re trying to express there, but the final arbitrator of what works is the plugin… just give it a try. The language I developed to express this stuff is not very sophisticated, so combining lots of different options is likely to not work quite right. —Jeffrey
This plug in is great, and Jeffrey has been extremely response to hiccups identified. I really appreciate the feature of creating “my places” on Google Earth and then populating the Sublocation field in LR using the KML file exported from Google Earth. The sublocation is a searchable metadata text field in LR, so searches are more meaningful.
I upgraded to Lightroom CC Classic earlier this year on my desktop and laptops (Windows 7 Pro). I haven’t been using my laptop this fall until today. When I downloaded the latest version of your gps plugin on my laptop it wouldn’t install within plugin manager (typical), so I downloaded it and copied plugin files manually into folder over-writing many files. When I looked at the the PI manager it says the latest version number gps-20171113.298 installed, but still said there is a new version (same #s), and the dot below the name in plugin list was yellow and a note that it may not work properly. I restarted LR; the dot is now green, but it still lists the latest version as installed AND still “now available”. When I tried to use the plugin to geoencode some photos (BTW which I think had been encoded years ago and proximity appears to have data associated) the window where you select the data file or input coordinates also shows both the latest version as installed AND still “now available”, AND a message in RED: “Tracking error: Please reconfigure the location of the GPSBabel program”. I don’t recall ever having to do this before and I have no idea where to find it or where it should be put if I do find it. It won’t function. What should I do? Thanks.
I wonder whether your Lightroom preferences file, where the plugin keeps some configuration data, is going corrupt. But the way you installed looks a bit iffy. Better to delete all copies of the plugin on your system, then download the latest and install that… that way you know you’re getting that and only that. You can tell the plugin where your copy of GPSBable is via the “config” button under the tracklog “Browse” button. That brings up a dialog with a “Reconfigure GPSBabel Location” button at its bottom. —Jeffrey
While publishing a collection (20171229.87), I received an error message “./PhotoGpsData.lua:86: attempt to call global ‘ZSTR’ (a nil value)” on a small set of photos…LR/Mogrify 2 was complaining and just to make things interesting, jf Collection Publisher was trapping and reporting the error. After many cups of coffee, I discovered that the culprit photos had values in the Map value of the Geoencoding plugin metadata. I used your “Flushing” button on the Extra tab to clear the Geoencoding plugin metadata and the error went away (I was able to publish the culprits). I’m sure photographers-toolbox will be very helpful in fixing this problem, but I am puzzled as to when the Map values are set and why they would upset LR/Mogrify 2 (btw, I do know what the Map value can be used for). I discovered values in Map for only a handful of photos and I’ve used Geoencoding many a time and would expect that the value would be populated more frequently. I would appreciate any ideas from you as to why this “interference” is happening.
Ah, this dates way back to before Lightroom had the Map Module and allowed users to geoencode photos. I created this Geoencoding plugin to allow it, saving the location in the plugin’s private data. The location could be accessed with special routines that I shared with other plugin developers, including Tim Armes and his plugins like Lr/Mogrify. Once Lightroom added the Map Module, I updated the routines to bridge the gap, allowing plugins to access locations with both the old and new ways. Anyway, that routine apparently had a typo that I fixed long ago, but his users had not run into it until now. I’ll let him know. —Jeffrey
Hi!
I’ve been using your Flickr Plugin for years now and am about to install this GPS plugin.
I consier replacing my Canon camera with a Sony. My GP-E2 GPS unit will unfortunately not work directly with the new camera.
Will your GPS plugin be able to read GPS data from the unit when it is connected to USB or will I first have to go through the Canon Map Utility?
I don’t know what format data it might present to the computer when connected via USB. If it presents a GPX file, or something that you can configure GPS Babel to convert to a GPX file, then you can use the plugin directly. The plugin reads only GPX files, but you can have it invoke GPS Babel for you. —Jeffrey
Google Earth prompted me to upgrade to Google Earth Pro (which is now free).
When I did so, it broke the “Geoencode from Google Earth” function of your plugin.
I found the plugin setting which allows me to specify the location of the Google Earth app but, presumably, I also need to be able to update the name of the Google Earth app.
Have I missed something obvious?
For the time being I removed Google Earth Pro and reinstalled Google Earth.
I’m using MacOS High Sierra and Lightroom 6.
Google removed, a decade ago, the official support for the feature that the plugin uses to communicate with it, so it’s always been hit and miss whether it works. When it doesn’t work, it just silently doesn’t work. If reverting back caused it to work for you, that’s lucky. —Jeffrey
Thanks Jeffrey.
As a backup, I can use “Copy View Location” in Google Earth and then paste the location into the Static Location input box in the plugin.
I’ve just tested that and it seems to work fine.
That’s a small extra step for me but it doesn’t need the interface to Google Earth to be working.
Hi, great plugin and I’m so happy that I registered it and paid for it. One problem I am finding a pain though is I do a lot of reverse geocoding and notice I always have to scroll to the bottom of the “Reverse Geo” screen to find the “Bulk Reverse-Geocode Selected Images” button. Any chance this could be put somewhere so you don’t have to scroll every time to find it ?
Yeah, that’s been a super-minor pain for a long time…. the pain adds up. 😉 Fixed it. —Jeffrey
Is it possible to Export State, City and so on to keywords? Would be Great so it will be exportet with the picture.
You can do this with my Metadata Wrangler plugin. Under “Extra Keywords to Add”, you can put “{City},{State},{Country}“, for example. —Jeffrey
Bug report:
per 20180218.299
The values for ‘bearing’ that the plugin writes had been in the range of -180° to +180°; now it’s properly in the range of 0° to 360°.
I’m still getting some bearings set as negative numbers. I can email examples, but it happened with my last set geocoded on July 19th after updating to the latest version. There were 4 of the first 52 with negative bearings. Then no negatives for another 230 images.
Thanks
Mike Bessler
I don’t think I’ve touched that part of the code in years, so I’m surprised that anything changed recently. Perhaps send a plugin log after getting improper values? —Jeffrey
Hi! First: thank you so much for this and your blog! So much to learn!
I’m from Argentina and I’m trying the plug-in before donate, I found it VERY useful !
But I have an important request for my job:
Is it possible for you to make any option available to customize the pins that will appear on google earth?
For a project I’m working on I need this feature, if possible, with the chance to put my own custom icons on the map
What do you think? Can you make it happen?
Thank you so much Jeffrey!!
I can see the value in it, but it probably won’t be useful to enough people to make it worth the time to add (sorry!) —Jeffrey
“I can see the value in it, but it probably won’t be useful to enough people to make it worth the time to add (sorry!) —Jeffrey”
Well, thank you anyway. But I think most people agree that the default yellow big pins of G.earth are awful !! jajaja Cheers
(G.earth lets you choose from a bunch of icons but when it loads the .kmlz from your plug in doesn’t let you do that. It would be easy to solve that?)
Greetings Jeffrey – Been meaning to comment for awhile now. I work in Disaster Response with an international NGO and discovered your plugin a couple years ago while searching for a way to make the aerial survey images we can take in disaster situations more useful. Images are good, but LOCATIONS on a map with images is even better.
I use your plugin to create KMZ files that contain the geo tagged, aerial survey images taken shortly after natural disasters, which we then share with the wider humanitarian aid community. The KMZ’s we are able to generate and share have quickly become a relied upon and valuable tool for NGO’s, humanitarian groups and even local governments for determining where aid is needed in disaster situations.
So, THANK YOU for this tool, and know that your plugin is part of helping people around the world affected by natural disasters to get more rapid and essential aid: It allows us to quickly share where help is needed most.
I’ve used this nice plugin last seven years. Lately it has been impossible to get any “Fill Elevation” or “Guess Timezone” due to API quota limit. Before if I hit this situation normally it worked again next day. Then it became so that only 200 or 100 goes through per day. During this last week I’ve got nothing else but failure.
Google has started to charge for most of its services that had been free, and it seems that along with that initiative, it’s also putting new, unannounced and undocumented quotas on services, and then refusing to comment on them when developers ask. This smells like a similar situation. I don’t think there’s much we can do, but just in case, please send a plugin log the next time you encounter this, and I’ll take a look. —Jeffrey
Hello Jeffrey,
I just found, downloaded, and registered your Geoencoding plugin. But I only randomly found it by Googling. My suggestion is that you make a few YouTube videos for your most popular plugins, explaining what they are and how to use them. As you know, the Map Module doesn’t work anymore in Lightroom 4 & 5, and it won’t work in Lightroom 6 after Nov 2018. So you may soon have many new people looking for an alternative to Lightroom’s Map Module.
Best regards,
Eric
(from a suburb just south of Dallas)
Hi
I just upgraded to LR CC 8 and the latest and greatest Geoencoding plugin. When I quit LR I got the message “Plug-in ‘jf Geoencoding Support’ performing shutdown tasks’ followed by a banner ‘A shutdown task for the plug-in ‘$$$/xxx=jf Geoencoding Support’ became unresponsive and may not have run to completion.”
I relaunched LR, and got the first dialog, but the 2nd didn’t occur. Is this dialog now the new normal? If not, what can I do to give you some ideas of where it comes from?
The temporary popup is a new normal, but the error dialog (and it’s wonky text) is not. I’ve submitted the wonky text as a bug report. The temporary popup is part of a convoluted process I have to get around a bug, and if that bug is ever fixed (I do have hope), the workaround will also go away. —Jeffrey
I don’t seem to be able to get the View at Microsoft Bing – snazzy new interface tower. I get the Bing Maps but not with coordinates of my photo. The view on Bing Maps is my actual location. Here is an example of an URL generated by the plugin that doesn’t seem to work.
https://www.bing.com/maps?FORM=FLREDR#5003/o=&a=&s=w/5872/style=auto&lat=47.50228&lon=19.034583333333&z=11
I am running plugin Version 20181015.312, Lightroom Classic CC 8.0, on MacOS Mojave 10.14. Browser is Safari but URL doesn’t work in Chrome either. Any help much appreciated.
It had been five years since I’d added that, and it looks like they changed. I’ve updated things to reflect the current reality. —Jeffrey
Thanks Jeffrey – all works now. I appreciate the fast response.
Guess timezone feature has worked well after you re-enabled paid account. Could also consider doing the same for Fill Elevation? Could it possible to use my own developer key which allows 2500 daily queries? Advanced feature for those who has developer keys of their own.
Yeah, I’ll have to do that, because I’ll probably have to disable my keys. It’s pretty expensive. )-: —Jeffrey
Jeff,
I just started using your Geoencoding Support plugin and love it. I am also using LR Mogrify 2 and want to include the GPS altitude on the photo watermark. I do have it working, but it gives me the altitude in meters (which is what is in the GPX file). Is there a way to get the output in feet instead of meters?
Thanks,
Scott
Software can convert between meters and feet, but that would be up to the software to provide. You’d have to ask the author of LR Mogrify. —Jeffrey
Hi,
LR 6.14 PC Windows 10
Download this day and zip archive uncompressed.
Presence of the gps-jfriedl.lrplugin folder.
Message when adding from the “Lightroom Plug-in Manager” after selecting the gps-jfriedl.lrplugin folder:
an error occurred while reading the schema of the jf Geocoding Support plugin. the module will be disabled.
Any test is impossible.
Thank you for your help.
I’m not sure what to tell you… perhaps unzip with a different unzipper? I’ve heard of some automatic unzippers causing corruption (which seems far fetched, but I’ve heard about it enough over the years that it’s worth trying a different unzipper). —Jeffrey
I am a French user excuse the translation made via google ..
A big thank you for this extremely fast response. Using 7-Zip and everything is back in order. Operation without problem, discovering your plugin …
For LR Ver. 6.14 on Wndow PC, its Map view is not supported in the Map module after Nov 30, 2018 – (https://helpx.adobe.com/lightroom/kb/map-view-no-longer-supported.html) . So does this “Geoencoding Support” Plugin still work?
Thanks!
Cheers,
KC
The plugin still works fine (it predates the existence of the Map Module). The only thing in Lightroom that stopped working is that Google is not longer serving maps to Lightroom…. since the map is the backbone of the Map Module, that module is no longer useful, but all the underlying geodata for your photos is still fine, and can be updated/inspected with the various features of my plugin. (Unfortunately, none of those features, though, replicate the interactive markers-on-a-map functionality that the Map Module was most noted for.) —Jeffrey
As reported by KC I’m very disappointed in both Google (for making a change without backward compatibility) and Adobe (for not supporting Lr 6.14 which is still for s download and sale on their web site).
However I don’t feel strong enough to push either of these mountains.
I’ve enjoyed using your plug-in and feel that you are likely more reliable than those behemoths.
I’ve looked at more of your geoencoding plug-in than I have used to date and I thought I would ask if I’m right in finding that it doesn’t effectively do that “interactive markers-on-a-map” functionality for us but on another kind of map? Could it?
It’s a pity I keep forgetting that Google has a habit of discontinuing popular software and features, such as Dashboard and Picasa. I think there might have been others but can’t quite recall. I don’t want to pay a subscription and I was mollified by assurances and hearsay that the old purchased version would remain usable. Now I wonder what other 3rd party software Lr relies upon.
So now I’m looking for a way to replicate that “interactive markers-on-a-map” functionality in some other software that I can use alongside Lightroom – or even instead of Lightroom, though I don’t think anyone has managed to achieve Lr replacement status yet.
Kind regards
Mike
Hi Jeffrey,
I am on Windows10 1809, Lightroom 6.14 and Google Earth Pro 7.3.2.5491 (64-bit). Every software is installed in German Version.
Your fantastic “Lightroom Geoencoding support” for instance is able to show the “Crosshair Target” inside Google Earth Pro (so the communication should work).
But a click on “Import Location from Google Earth” shows “Fetching…” for about 1 second but without any result (and the Crosshair Target is located on the map).
I am still in the test-periode – so maybe this does not work on the test-users?
Kind regards,
Dietmar
The Google Earth interaction tries to use APIs that Google abandoned a decade ago, and they simply don’t work for some folks. I don’t know why. More accurately, I don’t know why they still work for some folks. /-: —Jeffrey
Hi Jeffrey,
Just downloaded and started to evaluate your plug-in to replace the now dysfunctional LR Map module.
I have successfully geotagged images by pasting google map url into static location tab. The geotag information shows up in LR metadata but when I look at the image in Irfanview the geotag information is not present. Am I missing something? If I can get this to work I will be quite happy to make a donation.
Regards, Frank
Geocoding within Lightroom normally updates only the Lightroom database (the *.lrcagt catalog file), and not the master images themselves. You can write updated info back to them via “Metadata > Save Metadata to File”. —Jeffrey
Thanks for the speedy reply Jeffrey
I am using canon raws, it seems the data is written to sidecar files, not the cr2 file.
Are you aware of any method to copy from the sidecar file to the image? are sidecar files a Lightroom thing?
Regards, Frank
P.S. I live in Aberdeen, Scotland
Hi Jeffrey,
I have found out how to write from the sidecar file into the canon raw image using the ExifTool and ExifToolGUI.
Regards, Frank
Hey Jeffrey,
the plugin does not connect to google earth anymore. It does until last week. The new version did’t help also.
Kladdi
Hi Jeffrey,
quick question: Is there any trick to have the temperature from a tracklog written to my photo metadata? I am using a Garmin Fenix 5 watch with an external temperature sensor (Garmin tempe). The GPX files (converted from FIT to GPX using GPSbabel) all show the field (i.e. “30.000000”), but that doesn’t appear in my metadata.
Many thanks,
Ben
It does get loaded into plugin-specific metadata, which you can see via the “All Plug-in Metadata” selection at the top of the Metadata panel in Library. (You can also have it included in a custom list of fields you always see by building it with my metadata-viewer preset editor plugin.) I’ve just pushed out a new version of my Metadata Wrangler plugin that writes this value to the image, and added the {TempC} and {TempF} tokens to the templates that my plugins recognize. —Jeffrey
Hello Jeffrey
Apologies if this has been answered before, but there are so many comments and I haven’t read through them all.
I have recently started geotagging my photos and installed this plug-in (for which, thank you, it has been a ‘life saver’) into my copy of Lightroom 6 as a result of the MAP module mapping no longer working due to changes made by Google.
During a typical day I may keep any number of images from a journey of 20-100 miles and after geotagging the individual images they may be moved into any of the 3 different folders in my Lightroom catalogue. (Personal, Commercial, Selected). For instance 5 may end up in the Personal folder, 10 in Commercial and 1 in Selected. Some months later I may need to view all the photos taken on that particular trip. Will loading the relevant tracklog in “View selected locations as KML in Google Earth” search and find all the photos from my 3 folders?
Thanks
No, that feature works only with the currently-selected photos. You could perhaps use Lightroom’s grid filter to find all photos in the catalog taken on the appropriate date, and then apply that feature. —Jeffrey
Good evening from Kampala, Uganda! I have a problem wit exporting pics that I have previously geotagged using your tool. Upon export, all “additional” fields (like temperature, the map link etc) get removed – so they are not in the exported image, although they are present in the original files. Any idea what I might be doing wrong is appreciated!
From Lightroom 4, the image location should be included in exported files by default, unless you’ve told Lightroom to remove that metadata (all metadata, or location metadata). See the “Metadata” section of the Export/Publish dialog. Lightroom does not handle temperature or speed or bearing, though, so to get those into exported copies, use my Metadata Wrangler plugin, which I just updated to handle temperature. —Jeffrey
When opening Geoencoding Support, before doing anything, I get this error message: “Error message fro Google during reverse-geocode lookup: You have exceeded your daily request quota for this API. If you did not set a custom daily request quota, verify your project has an active billing account: http://g.co/dev/maps-no-account“.
I did geoencode about 130 photos last night, but I have done many more in the past and not hit a limit.
Sorry about that… I had to turn it off for the rest of the month, because it’s become really expensive. Until recently, Google very kindly provided these services for free, but now they’re charging. They give a free allotment each month, so I’ll try to turn it on for that, but then I have to turn it off. (I’ve just pushed out a new version of the plugin that provides a better error message.) Hopefully soon I’ll be able to update the plugin to allow each user to use their own Google Billing account. By the way, you can still reverse geocode with the OpenStreetMap option… it’s a tab at the top of the left side of the Geoencoding Plugin. —Jeffrey
Hi Jeffrey.
I don’t know if you have seen the conversation at https://feedback.photoshop.com/photoshop_family/topics/lightroom-classic-8-does-not-display-exif-for-image-direction
I hadn’t realized it, but LR uses the GPSImgDirection field to specify the direction the camera was pointing, but clips it to ± 45° (N, NE, E, etc.) Would it be possible to show this number more accurately in the metadata panel supplied with your Georeferencing plugin?
And, while we are on the subject, I can imagine some people would like your Data Explorer plugin to also allow more refined bins (like ±10° vs ±45°).
Low priority, to be sure…
I’d not seen that conversation, so thanks for the pointer. You can already see the actual decimal-degrees direction by mouseovering the direction displayed… the actual value will show up in the tooltip. I’ve just pushed out a new version of the plugin that includes “Direction” in the plugin’s fieldlist; I’d not thought to add it when “Direction” was added to Lightroom. Data Explorer has two direction-related items, one that mimics Lightroom’s compass-point names (“North-West”, etc.), and one that shows the degree number. —Jeffrey
Hello Jeffrey
First of all I want to thank you for all your work. I’m currently using a couple of your LR plugins (I’m still using LR6). I just wanted to ask about the geocoding support after reading Marcs comment above. Are you using your own Google maps API key for the gps plugin? Which APIs are you using/calling? I’m asking because I’ve recently “hacked” the Location.lrmodule to use my own API key and I could probably do the same for your plugin. I have used a tool to extract the corresponding LUAs from the Location.lrmodule and replaced Adobes key with my own but I couldn’t find the right place in your plugin (just looking very briefly).
Greetings from Austria,
Bernhard
PS: tribute for the LR hacking goes to astuder (https://github.com/astuder/lightroom-map-fix)
It’s not in cleartext, so no way to patch it, sorry. I didn’t think you could patch the Lightroom modules… I thought that they were signed. Perhaps no longer? —Jeffrey
In response to http://regex.info/blog/lightroom-goodies/gps#comment-58745
Jeffrey, Stuart here again. Thanks for the info about the Metadata Wrangler plugin. I have used that one now and configured it correctly to preserve all metadata. However, in the exported images, the fields like the map link, speed, bearing or temperature are no longer present (they were in the original raw image). The timezone setting has also changed to “unknown”. I am fairly sure I configured it correctly, having read your documentation. Weird….
Ah, I see, those fields were not added by my plugin when geoencoding from a tracklog, but were in the original master image? Lightroom doesn’t deal with them (except “map link”, which I think doesn’t actually exist… the files merely have latitude and longitude, no?). Lightroom ignores them on input, so the data is simply not there during export. I suppose that I could add a feature to Geoencoding Support to suck that data from the raw master files and stuff into the plugin’s custom metadata, so then it’ll be written by Metadata Wrangler. Oh, and when you mention “timezone”, do you mean the plugin’s custom metadata? That’s set when you apply a tracklog, or you can set manually. I don’t think anything ever clears it automatically…. —Jeffrey
Hi Jeffrey,
Regarding the Google Billing problem.
Maybe you could add the opportunity to enter a Google API Key in the plugin options and then use it in the further calls to Google web services.
But maybe is that you mean when you write “Hopefully soon I’ll be able to update the plugin to allow each user to use their own Google Billing account” ?
Kind regards,
Bruno
Yes, that’s exactly what I hope to do. —Jeffrey
In response to http://regex.info/blog/lightroom-goodies/gps#comment-58780
Yes, those fields were present in the raw file before export – but are gone from the exported image, even if I use your metadata wrangler plugin. So the only way to get these into exported images again is to use the geoencoding plugin again (using the traclog function). No biggy, just would be easier if all the data the geoencoding plugin writes to the raw image would also be in the exported image.
As for time zone: I mean the metadata field that is shown in LR at the very bottom of your geoencoding section. It is correctly shown in the raw image, but in the exported image is then reset to “unknown”.
If by “write to the raw image” you mean to update the Lightroom database for an image you see in Library, the problem is that some fields are not maintained by Lightroom. Lightroom does know about latitude, longitude, and altitude, and so when the plugin updates those, they find their way into normal processing such as image exports. On the other hand, Lightroom knows nothing about speed, bearing, temperature, or timezone; those fields are maintained by the plugin, “off to the side”, so to speak.
I have my Metadata Wrangler plugin stuff what it can into exported images, but there’s no standard “timezone” field in the Exif standard (which is an incomprehensibly stupid decision by incomprehensibly stupid people; a decade ago I asked an Exif committee member why there was no timezone field, and he replied “Why would anyone want the timezone?”).
At the end of your comment, you note that “the exported image is reset to unknown” — how are you inspecting the timezone in the exported image? —Jeffrey
Hi Jeffrey,
Just installed your Geoencoding Support. Been having lots of fun with the tracklogs which work like a dream and are so fast, but I can not get either static or one-by-one to work with Google Earth Pro. I get the error message “Can’t get location from Google Earth” displayed. I can get the Cross Hairs displayed on Google Earth Pro and I can get locations of geo referenced photos to displayed in Google Earth Pro but it won’t export co ordinates into Lightroom. I am using Google Earth Pro. Is that the cause of this issue?
Google maps is fine……but without the cross hairs it is not very accurate. Also you have given Google Earth the ability for a shortcut which might suit my workflow when I don’t have tracklogs.
I have setup the google earth pro exe in the plugin settings.
Kind regards
Robert
Hi Jeffrey,
Sorry…….did not read all your instructions before posting earlier 😉
I’m from SW England.
Kind regards
Robert
Hi,
Just downloaded your geoencoding plugin for LR since the Google maps thing stopped working before Christmas. Google Earth import not working at all, I get that is the same issue as the Google Maps – they now want to charge for what they used to give away. But how do I get GPS coordinates (even manually one by one?) from Open Streets or Google maps or?? I used to use the drag and drop feature of LR to drag whole groups of photos taken within feet of each other onto the map. Is there some similar feature here, or can I only do reverse encoding now?
Thanks,
Oakland, California
The Google Earth thing has nothing to do with Google’s recent billing changes. For reasons I’ve never been able to figure out, the interface to Earth just doesn’t work for some people. It’s been this way for a decade. It’s a mystery. )-: —Jeffrey
@Jeffrey: Thanks for all your efforts here!
@Bernhard Heidegger: YOU MADE MY DAY with http://regex.info/blog/lightroom-goodies/gps#comment-58774 !!!
Best regards!
Dietmar
Hello again Jeffrey
I read all the posts on this page and noticed Adrian Walmsley comments.
Based on this I installed Google Earth as well as Google Earth Pro.
Yippeeeeee
The plugins static coding does work with Google Earth…….
It does not work with Google Earth Pro
I am using Windows 10 (64 bit version) OS
So for me I can use Google Earth Pro when using track logs (and everything else) and Google Earth for static and one-by-one Geocoding. That’s me sorted. 🙂
Kind regards
Robert
In theory it should work with Pro or non-Pro the same, but why it doesn’t work for some is a total mystery, so I’m glad you could figure it out. —Jeffrey
Hi Jeffrey,
I echo the comment above: https://github.com/astuder/lightroom-map-fix/ allowed me to continue using LR 6.14 with the Maps module, and I’d like to do the same with your plugins.
I believe the reverse encoding is done by your plugin using your own API key? If so, I understand you have to throttle the requests to avoid ending up with a huge bill.
However, so as to leave the feature (the whole plugin?) benefitting its users, you could leave the feature available, with an extra input field in the LR plug-in manager to one’s API key, and if you need to, a link to a guide on how to request one. As stated above, Google allows $200 of monthly credits (~ 40000 geoencoding API requests) per account (gmail address + credit card). This way, with a small effort from the user, could you keep distributing this plugin without incurring any cost from Google?
Thanks
Yes, I’m actively working on this. Figuring out how to tell users the procedure will be an issue, since I have such a difficult time understanding it myself. Google’s whole API/billing console is incomprehensible to me. )-: —Jeffrey
Hi Jeffrey,
I made a small routine to convert KML files to GPX in order to interpolate the initial and end time of a track and distribute the interval equally between the track’s points. The resulting file works with Lightroom’s Map Module but, when I try to use it with your plugin, I receive a message which says: “Datapoints in that tracklog don’t have timestamps”. What’s the time format that your plugin expect in order to recognize the timestamps in a track?
Thanks,
Max
Like the example given here in the GPX specification. It could be that I’m somehow too restrictive; feel free to send one of the GPX files and I’ll take a look. —Jeffrey
Hi Jeffrey,
I don’t know if it will help, but this web page I found by Googling is for developers who now need the API. Perhaps it could be a crib sheet?
https://churchthemes.com/page-didnt-load-google-maps-correctly/
Best Regards
Brian Williams
Before the Google changes resulting into situation, only usable desktop GE version being “Pro”, I was using both – Pro and non-pro vestions. On at least 2 computers (thats all I’ve tried) Jeff’s plugin wasn’t able to retrieve location from Pro version. That dates way back and is nothing new. Just most of the people didn’t use Pro version.
I’ve written AutoIt script which greatly helps GeoEncode pictures without available track logs manually – by positioning crosshairs in GEarth.
I use it since 2015.
Now I’ve extended functionality to read-out location from GE and fill it in Jeff’s plugin.
How to use:
Select picture in LR, switch to GoogleEarth, set desired location in center of the map and – press F10 which is registered as hotkey. The program will switch to LR automatically, invoke Jeff’s plugin and fill in the location, simulate button press to geoEncode the image and confirm ok dialog. It speeds up work tremendously.
Download script/source code here: https://ulozto.net/!s07gqRx1H2if/lr-geoencode-au3 and AutoIt interpreter from https://www.autoitscript.com
I am using the CalTopo service to create my map of zones that I want to be added to the IPTC location field. The service will export a network link to KML data in XML format. How can I add this to the reverse geocoding files?
Is there a solution for filling in Cities, States or other higher level IPTC location tags yet?
If the KML has polygons, the title of the polygon is used as the “Location”. In the description, put “Country/State/City”. —Jeffrey
I’m getting the error …you have exceeded your daily request quota for this API … when I do a reveres lookup. I get the error on the first try. I am on the current version. The google web site says this error occurs if your app does not have a valid key. Please help.
Modern versions of the plugin provide a better explanation, along the lines of my reply here. I’m working on something that allows folks to user their own API key. —Jeffrey
Hi Jeffrey,
good idea to implement the ability to enter my own Google API Key. I´m going to “order” my own, but for which API do I need it? I guess “Google Maps JavaScript API” and “Geocoding API”. I´m I right?
Google offers difeerent packages “Maps” “Routes” and “Places” containing different APIs.
Regards,
ulrich
The plugin uses three: Geocoding API, Time Zone API, and Maps Elevation API. The latter two are used only via items on the “Etc” tab, so not often used. —Jeffrey
Hi,
Thank you for adding use your own API key feature. It’s working! I just love this!
The reply to Ulrich about which APIs are needed on Google is very helpful.
I was looking at Google’s information on all of this, and they made some very strong recommendations about restricting use of your key. It looked pretty straightforward for use on a web site, but I am completely baffled as to how I should restrict it for your plugin. Thoughts?
Thanks,
Paul
I think they intend that for server-based applications (e.g. a company using it on their back end would restrict it to the company’s range of IP addresses). You could restrict it to your IP address, but for most folks, the IP addresses changes over time, so it’s impractical. —Jeffrey
Updated and appreciate the ability to use Google again. Got my Geocoding API, entered and the plugin works just as it always has. Many thanks!
Thank you very much for the changs to allow own API key. Restricted by API, and all is working just fine. Appreciated!
Whoa! Just relaunched LR and it is enabled! Finds location in Google Maps superfast, thanks. Reverse geoencoding from Google Earth is not quite so straight forward – must read your blog on how to do it!
Tom
Hi Jeffrey.
Recently donated to obtain your geotag plug in. It was a tremendous help now in LR6.14 the map module is much restricted by not being able to load Google maps. Research I believed showed I could get google maps loading within the map module by obtaining an API to access Google maps. With your very prompt and timely update to include reference to an individuals api I hoped Google maps would load in LR map module and thus regain the full use of it. Unfortunately i loaded your latest update and put my API in but Google maps still does not load within LR 6.14 map module. Running Windows 7 pro. So question is should it have worked or have I not picked up correctly what your plug in with an api can do from previous posts on this forum?
The “your personnel google-billing API Key” window says “This API KEY is valid for only (will FAIL for reverse geocodining, the elevation service, and the time zone service”). In Google map platform I only ticked maps as not interested in routes or places. As you say Google map platform is not designed for non developers. If your update does facilitate full map module use age and some one writes a simple guide to getting an api for amateur photographers the world will beat a path to your door.
Keith
The personal API key is for the plugin functions that use Google (reverse geocoding, etc.). The Map Module uses something else (one imagines Adobe’s API key). It’s apparently possible to patch the Lightroom binary to replace that key with your own, thereby re-enabling maps; there’s a link to the method in a recent comment. —Jeffrey
so recently i had to encode some images with rather large gpx files (google takeout) Thee process took a number of minutes for every encode. I was trying to compensate for the camera clock being slightly off. So I thought would it be possible to cache the tracklog for the duration of the session? Does the plugin really have to recheck the tracklog everytime I encode the same image while fiddling with the clock compensation?
many thanks for such an invaluable plugin
The tracklog is read whenever the dialog is opened, the tracklog filename is changed, or the timezone is changed. The memory is released after closing the dialog; I’d think that the common case would be using the tracklog once and then not returning to it. (The common case is also less-huge tracklogs, so you’re getting bit twice, sorry.) —Jeffrey
A (hopefully) small request regarding reverse geo-encoding….
Could you display the actual number of API call that are made when doing a bulk reverse geo-encode? For me, this would make it easier to see if I have the fuzziness set appropriately (I tend to err on the side of way too much precision). This is not anywhere close to a high-priority request, just something I think would be handy.
Thanks!
I’ve added this as of version 20190331.324 —Jeffrey
recently i made a comment that when i loaded google takeout gps files it would take a few minutes to load. Today i noticed that if i went to the static area .. say , to manually add a location to a photo it would still load the entire tracklog (it seems) as i have to wait once again a few minutes before i can enter coordinates. kinda would be good if it didnt do that if one is in another tab that doesnt require this
Hmmmm, I can’t reproduce this… I can enter into the static-field tab regardless of whether there’s a big tracklog specified in the tracklog tab. (Still, if it’s loading the tracklog needlessly, perhaps just delete the path from that tab.) —Jeffrey
Hi Jeffrey,
a question about What3Words: This seems to be getting really big – Mercedes is including it in all their new cars navigation system, DB Schenker and UPS are having trials for their worldwide delivery, Airbnb is using in in Mongolia, Nigeria is looking to adopt it as an official postal address system and so on.
Will you be looking into it further? I am currently manually tagging all my pics with the respective what3words, but a batch function through the geoencoding plugin would be amazing – both for new pictures and also to batch-add it to already geotagged photos.
Kind regards,
Ben from Berlin
For now, I’ve added a batch-add functionality in the “Etc” tab. —Jeffrey
Hi Jeffrey,
excellent, exactly what I was looking for, thanks! One quick remark: Could you include the leading /// with the three words? At the moment, the plugin writes the words as such, but the correct format would be ///smart.event.item
Thanks so much, and have a great Sunday,
Ben
Fair enough… I just added it. —Jeffrey
Hi, first I want to say to you thank you 10000 times for plugin.
Second is a question. Is there a way to rename picture name from geoencoding.
My files are usual named dsc_100111… and it would be great if there was a way to bulk edit names using geoencoding.
Thank you!
Not directly… Lightroom doesn’t allow plugins to rename files. However, you could use my Bag-o-Goodies plugin to fill in a standard field (such as “Title”) with the name you want, then use Lightroom’s renaming templates to rename the file from that field. —Jeffrey
Hi , I have a problem with KML files from Google Maps, and GPSBabel does not help to convert.
Using a KML download of my Google timeline gives an error: datapoints in that tracklog have no timestamps. GPSbabel does not help to solve the issue.
The KML file includes Iimespan as a marker but the plug-in wants timestamp descriptors appearantly.
I did not have this problem 6 months ago, but now I cannot find a way out.
I also remember there was a way to make a KML in Google for more than a day that worked fine as such, but that option I cannot find any more either
Without an example KML file it’s hard to say, but the plugin needs timestamps on each data point, or there’s no meaning for the track in the context of what the plugin does. —Jeffrey
Hi Jeffrey:
I’ve run into a problem a couple of times using the plugin to geocode photos from a GPX track log. It misses one photo of 500+ photos, and coughs up an error message that it “couldn’t process successfully” one image. It occurred again today, and the error log says:
Tracklog has 455 datapoints, running from Sat, Apr 20, 2019 10:05 am to 11:58 am UTC-7 (in UTC: 5:05 pm to 6:58 pm),
starting in Mount Pleasant going 2.8 km, ranging up to 790 m away
Timezone in which photo times are interpreted: UTC-7
Fuzziness (seconds on either side of photo to search for a tracklog datapoint): 120
Photo at 11:48 am (Sat, Apr 20, 2019 UTC-7): PENF_53494.ORF
Tracklog has datapoints 2 minutes (131 seconds) earlier, at: 49.262109, -123.101293
and 2 minutes (132 seconds) later, at: 49.262153, -123.101242
The two points are separated by 6 meters (7 yards).
The photo in question was taken in the exact same location as the photo before and the photo after, 19 seconds after the previous photo and 34 seconds before the next one. There’s no obvious reason for the plugin to stumble over that one photo.
Rerunning the plugin generates the same error. If I wipe out the GPS info from all 500+ photos and use Lightroom to geocode the photos, it processes all of them, including the problem image. Any idea why the plugin occasionally can’t geocode one image?
Thanks!
Wow, that’s really weird. Could you send the plugin log the next time you encounter this, being sure to include the exact details (the filename and time of the photo that didn’t match, and the same for the photos on either side). I’m wondering whether it’s an ordering issue(?) Thanks. —Jeffrey
Can you elaborate on getting our custom Google API billing key? I did get an API key from Google and pasted it into the plugin, however it said it will FAIL for reverse geoencoding (which is what I need). How can I get a API key that works for reverse geoencoding?
You need to enable your billing key for the Geocoding API. —Jeffrey
Hi:
I’ll end of ask for your help on this forum since I saw many good and accurate replies. Thanks a lot for your time in advanced.
Really, I spent a HUGE amount of hours trying to understand the way to go with my puzzle.. which is a REALLY common one. Let me elaborate:
1) I’m an amateur photographer (video+photo).
2) I travel often.
3) I have a set of devices without GPS (video, camera mainly), and only one with GPS (android Mobile).
4) I’m looking for convert my RAW images to DNG, set correctly GPS position + correct time over all my devices via scripting.
5) I’ll import all to Lightroom.
My goal: Have everything with more or less correctly geotagged and with a unified criteria about creation time, for having a true sequence of videos & Pictures of my travels.
Well.. after many tries.. reading ..etc.. This is my approach:
1) Put all my no GPS devices statically to UTC timing and NEVER change them.
2) I downloaded a great open source GPS tool on my android device GPSlogger. it creates a .gpx file 24h per day.
3) Put all media content together.
3a) If it’s a GPS device (my phone) leave the file untouched.
3b) if it’s a non GPS device (camera or video) run the script:
3b1) If it’s a RAW image, convert it to DNG (I need it since Lightroom doesn’t support ARW).
3b2) add geo info with exiftool -geotag “*.gpx” file.DNG or use your pluginn
3b3) Fix the timestamp.. and now is when everything crash!!!
In orded to follow I need to have clear some concepts:
1) Should I change creation time for files or should add offset that belongs to that time (based on the offset of my location respect UTC and daylight saving time changes.. therefore what my phone has on the picture moment froy phone has on the picture moment from the local GSM network / GPS gave to GPSlogger)?m the local GSM network / GPS gave to GPSlogger)?
2) I want to have coherence with Android. Seems like Lightroom is ignoring offset?. Any clue here?
3) Based on #1… it’s same if I add some offset than change the create date? I.E ¿ 2018:12:08 17:42:26+02:00 = 2018:12:08 19:42:26+00:00 = 2018:12:08 19:42:26?
The main idea is get close to the reality that I experience when I’m traveling (or not). Let’s suppose that I take a selfie everyday at 9:00 with my Android phone. All pictures will reflect the correct GPS and the 9:00 local time. So.. no differences if I’m at home, or in the other side of the planet. GPS is stamped correctly (it knows where is), and time is automatically switched based on the GMS network. Therefore.. there is a coherence.
I can leave your plug-inn do the job, but adds some extra step that cannot be done by script.. anyway this is a way that I can take.. but I want to understand the logics and the correct way to go.
Thanks
There’s no easy answer to this, but some thoughts:
Lightroom can be challenged with timestamps, especially for videos. To reduce the chance of problems, I would set the device clocks to local time, and when importing things, be sure that the computer running Lightroom has its timezone set to that same timezone. Also be sure to identify the timezone when geoencoding with my plugin.
But even if you do all this, Lightroom may screw up the times for videos. It’s maddening. —Jeffrey
I’m rather disappointed by this plugin: This help site mentions the far superiour reverse geo-encoding than the built-in Lightroom feature.
Running it, it refuses to work with a reference of Google no longer allowing access to the data.
Please don’t make promises on this page, if you’re not fulfilling them with your product!
You can use it with Google, but you must first register your own Google API key to the plugin. The plugin is free… it’s not a “product”. But you’re right… I neglected to update the 10-year-old documentation when this change happened. I’ll do so now. —Jeffrey
Hello, I am from Belgium.
I just installed your wonderful plugin that solves the problem for my MacBook Pro 2009 (too old to run new OS -> not suitable for new Lightroom).
I am still discovering the process, but it seem that when I ask for Reverse Geo with the “Fill location name from OpenStreetMap data?” checked ON, it works perfect for 1 picture at the time. But if I select a set of pictures, all of them will receive the same local data. I tried to change the high priority setting, but no result. Can you help me. Thank you.
If they’re all in the same location, they all get the same info, of course 😉 . There’s a slider on the dialog that indicates how far away a photos has to be from the previous photo to have the data looked up freshly for it… perhaps that’s set to a long distance? —Jeffrey
Thanks a million for implementing the “own Google API” feature. After just a couple of minutes use I’m convinced that it works well. I’ve been tearing my hair out trying to like using GeoSetter but failing. Now I’m happy again with your reverse geoencoding and tracks. Now I guess I’ll invest a bit of time learning about Google Earth, although I’m always reluctant to invest anything in Google as they have such a history of dropping users in the wotsit. — Mike
Hello Jeffrey,
a few months back I noticed that some of my images still have the geo-encoded information proposed by LR Map, even though I use your plugin as a fix part of my workflow.
Paying close attention, I found that the plugin seems to skip a few images when run on a selection. I need to run it twice, or even thrice on large sets of images to be geo-encoded. Eg for the most recent set of 770 images, 8 were skipped for which I needed to run the plugin once again (on the same selection).
Being aware of this fact it is not a really an issue. Anyway, I thought I would let you know. Is this known behaviour?
Karsten
It shouldn’t be skipping images like that. If I can impose on you to send a log the next time you encounter this, I’d appreciate it. Please be sure to mention the full filename of an image that was not geoencoded, but should have been. Thanks! —Jeffrey
If they’re all in the same location, they all get the same info, of course
🙂 No, no, there are quite seperated! 🙂 Sometimes a fiew miles… Well, I am on the road now, I will check again once I am back home and let you know… Thank you. -Yves.
When I tried to install your Geoencoding plugin in LR5.7 I received this error message:
Did I do something wrong? How can I fix this?
Whatever the error message is, it failed to make its way into the comment. Next time you encounter it, perhaps send a plugin log or email a screenshot… —Jeffrey
Jeffrey,
I just went through the incredibly arcane process of getting a Google API for use with this plug-in. I ** think** I’m set up right, and in any case, the pricing explanations make a grown man weep (figuratively, of course). Trying to change the API selection, worse.
I know you can’t really address these glaring issues. However, please tell me if I can safely ignore the text message in green that displayed after I input the Google key.
This API key us valid for only reverse geoencoding (will FAIL for the elevation service and the timezone service.)
Did your plug-in generate this message or did Google generate this message? Do I even care?
This message is from the plugin. Three different features of the plugin use three different API services at Google. You need to permission your API key for only the service or services that you intend to use, and that’s what the message was poorly communicating. I’ll have a better message in the next version. —Jeffrey
Great work on the plugin Jeffrey.
I have a unique situation, wondering if you can help or point me in the right direction. Recently took a bunch of photos with my Nikon Z6, using an attached GPS unit. I also had my phone generating a GPX track for the occasions where the camera may not have been able to get a GPS fix in time. Unfortunately, the GPS unit appears to have set the date incorrectly for roughly a third of the photos (a few hundred of them) – all come in as 1 June, 2080 at ~8am. The geolocation, however, is correct.
What I’d like to do is use the GPS file to find matching geotagged photos, and then pull the date-time from the GPX. Pretty much the opposite workflow you’d normally take for geotagging photos. Any ideas if this is possible?
First of all, are you sure that there’s actually a mistake? More likely is that you were moving in and out of the nexus of a wormhole, so the photos probably are from the future. Best to wait until 2080 to confirm, before you risk destroying data by setting the wrong dates on the photos. The reverse-matching thing would be difficult, especially since the track was created by a different device from the one that set the location of the photos. The results would be iffy at best, and though useful in this case, not useful in any other case. Sorry. But, perhaps the correct date was recorded elsewhere in the file? Try viewing a raw master image with my online viewer or my metadata-viewer plugin and maybe you’ll get lucky and find the proper time in there somewhere. If so, you could use ExifTool to copy that date to the incorrect field, then reimport into Lightroom…. —Jeffrey
I’m actually responding to the comment by Tim on June 24th, 2019 at 12:51pm JST . I know it’s somewhat out of scope for this plug-in, but I think it’s worth mentioning.
He mentioned that some of his photos were dated 1 June, 2080. I have a Nikon D3, and several times now I have had a problem with the backup battery, which keeps the camera’s clock set right.
When there is a problem, the camera resets the clock to either 2007 or 2080. Either way, it drives me crazy. In order to correct all the different Windows and EXIF dates to the same real date, I’ve become familiar with Phil Harvey’s excellent EXIFTool. I haven’t found a way to correct ALL of those dates in Lightroom, and to force Lightroom to update both a Nikon NEF file and the xmp sidecar file, so I have to do the date corrections on the NEF file outside of Lightroom, and then do the import.
This is also true whenever I need to correct the time by a few hours because I have forgotten to reset the camera’s time zone.
Phil
Hi Jeffrey, and thank you for making a Lightroomers life easier, er, ish!
My needs are simple, to be able to highlight the CR2 images in a LR directory, see the ones which weren’t photo tagged for some reason, drag em to the map and the rest is hopefully automatic.
All the problems I’ve had with the installation of the plug-in seem to be around the use of the google API . I have successfully generated an API key, but can’t for the life of me find how to ‘permission’ it (where does this English come from?). It would be wonderful to have a dummies step by step guide on how to do the Googly stuff which is a prerequeite to using your hard won softeware.
The LR Maps module was ideal for my needs, and I would ideally love to be able to breath life in to it by using a Google API key, however I can find no numbskull level instructions available on how to do that.
Any pointers for that?
Regards from England
Google’s pages in this area are so difficult for me to fathom, I just don’t have the intestinal fortitude to make the step-by-step guide that is certainly needed. I’m not sure which Google feature you want to use with the plugin, but if it’s the reverse-geocoding, go to this page at Google and “enable” your API key for that service. I think. —Jeffrey
Hi Jeffrey,
In metadata-viewer preset builder, is there any way to show the SpeedMPH token instead of SpeedKPH?
Thanks!
Not at the moment. To support MPH as well, I’d have to add a separate field to every photo, and populate it (calculating from KPH). Lightroom doesn’t allow, unfortunately, for such calculations to be done on the fly. —Jeffrey
It seems that a few months ago https://nominatim.openstreetmap.org changed the default ‘zoom’ so that a query will return the ‘place:quarter’ instead of the building. Zoom level ’18’ the default now, I get the result I want with level ’21’. So for my own scripts I now add ‘&zoom=21’ to the request URL.
Would it be possible to have the plugin automatically use 21 through 18 for the 10m – 100m range on the cache slider?
This query shows the size of a quarter nearby, it’s quite a bit larger than I expected it to be.
The zoom isn’t dependent on the slider. I’ve gone ahead and bumped it to 21. —Jeffrey
Geoportail opens with no map, could you please use “Carte topographique IGN”
It looks like they changed how their urls work…. I’ve updated the plugin. Thanks for the report. —Jeffrey
I just created a Google API Key, gave it the Geocoding, time zone, and elevation API’s, and entered into your plugin.. I got the message back that the API Key was permission only reverse geocoding; it would fail for the elevation and time zone services. So I canceled out and double checked to make sure all three services were enabled, and sure, enough, they were. So I entered the key again, and this time the message in red about the API Key not being provisioned for any service.
I decided to try again; I deleted the project at Google, started a new project, got the API Key, gave it permissions, and the same darn thing happened. First time I entered it, it gave me the green message about only geocoding being available. This time I clicked Save, cleared the key, and entered it again, and once again, got the red message about no APIs being configured.
Any ideas on how to proceed? (At least I can do the reverse lookup with a new key…)
Well, this is odd. I regenerated the key, waited 5 minutes, and this time it said in green that it was only configured for the elevation service. All 3 APIs are marked as enabled.
I just disabled the plugin in LR, re-enabled, and reloaded the plugin, and this time the message was that only the Time Zone API was enabled (no changes had been made at Google).
Quite odd!
(Sorry for the 3 posts…I should have done all the work before posting. Please combine them if you wish)
Even with the key being accepted for Geoencoding, the plugin wouldn’t work; returned a message saying that the key was no longer valid. I think I’d better give up for now. (This was once again with a completely new project, new API Key, etc.)
Would you mind sending a plugin log after one of the failures? Thanks. —Jeffrey
A question and suggestion about the “Fill in pauses…” feature.
In the example you give in the documentation, you talk about a gap in the track log occurring because of an extended stay in a restaurant. If an image is shot a time within the period set (say, a pic of the delicious dessert), will the plugin assign the location of the track log entry BEFORE the time the image was shot? I’m thinking of a situation where there is a gap in the track log, and the log entry right after the gap occurs, say 5 minutes after leaving the restaurant, or, say, 100m from the last before-gap track log entry. With what location will the delicious dessert pic be tagged?
The effective use of the “Fill in pauses…” feature requires one to have some idea of the largest time and distance gaps in the track log. Without laboriously searching the track log, that’s hard to determine (I’m thinking of processing trackless from a several week vacation after getting back). I wonder if your plugin could report the maximum time gap and the maximum distance gap in the currently specified track log?
If a photo’s time doesn’t match a tracklog datapoint directly, it interpolates the location between the surrounding datapoints, proportionally in distance as the photo’s time is relative to the datapoints (that is, if the photo’s time is ⅓ of the time between the enclosing datapoints, the location will be ⅓ of the distance from the first datapoint to the second.) If some photos can’t be geoencoded, the dialog offers an error log, which tells how far away in time the unencodeable photos are. —Jeffrey
Really useful plugin, however I have one gripe. I currently have the font size in Lr set to large on a 15.6″ laptop and this makes the ‘geoencode from tracklog’ window (and others) too big. I can just about see the ‘view tracklog in Google Earth’ button but not the all important buttons below it and there’s no way I can find to scroll the window up.
I have to change the font size, do my geo-encoding and then change the font size back again. Could you provide a scroll bar in the window if it’s too big for the screen? Thanks. I’m from the UK by the way.
Further to my last comment I have just discovered the ‘terse geo-encoding dialogue’ option in the plugin manager. Happy bunny now.
Hi,
Happily using your plugin in Germany. But photos are from around the world which leads to a little problem identifying what is on the photos. That is where peakfinder comes in handy: For example https://www.peakfinder.org/?lat=14.4045&lng=104.6882&azi=105&zoom=5&ele=4274&name=whatever points to the view from one of my pictures helping me to identify the content. Now I have been looking for a way of adding the link structure to the plugin, so I am asking: Will it be possible in the future to add linkstructures, or would you add peakfinder in one of your future releases. That would be fantastic
I’ve added it to the version that I just released. —Jeffrey
Haven’t used Geoencoding for a while. Just got msg telling me current version not compatible with LR8 and to upgrade to latest version of your product. I’m using LR Classic V 8.4.1. Is there a version compatible with my release and how do I acquire it?
Versions more than maybe two years old wouldn’t work with Lr8; all the versions since, including the one currently available via the download link above, do work with Lr8. —Jeffrey
What in the world is Google API Billing? I donated $10 to continue using the geoencoding plugin and the donation went through. When I try to run the plugin, I get error messages telling me there’s a problem with my “Google API Billing”.
What’s up with that?
Some aspects of the plugin let you query data from Google about locations (e.g. give a photo’s location, what’s the estimated land elevation there, or the name of the city the point is in). Google charges for these services, so if you want to use the plugin to access them, you need to create a billing account with Google and (via links in the plugin manager) let the plugin know. If you tried to use these services without having done that, the plugin should have give a message explaining things. —Jeffrey
I shoot high school sports (volunteer) and frequently find myself process more than 4K pictures on a crazy weekend.
I would LOVE to be able to geoencode my images when I import them…..
Is there a trick I’ve missed?
Thanks!
If you’re asking about the ability to somehow geoencode during the import process, Lightroom simply doesn’t allow for it, sorry. —Jeffrey
Hi Jeffrey,
I’ve been using your plugins for one year now and I would like to thank you for all the very big and great job you’ve done. I’ve got 2 questions :
1) Is there any way to sort images by altitude values from inside LR ?
2) I have recently discovered your “Fast Full-Catalog Proximity Search” which is very fast and so useful.
In addition to the “Selected image” and “Coordinates” check boxes, I was wondering if you could include a third one with a list of saved locations.
The user could select a recorded location through a scroll menu (menu that also includes the option “Save current location as a preset”).
I know that a lot of people are asking you special upgrades and modifications. I am sure your “to do list” is overfull and you don’t have any spare time left for special request.
But maybe, you will think about it at the time of the next released version.
Best Regards
Thierry
Grenoble (France)
I’ll indeed add presets to the to-do list. About sorting by altitude, the best I can think of is my Data-Explorer plugin with the “Altitude” item, which sorts images into buckets by altitude. —Jeffrey
Forgive my dimness, but did you create your Photo Map using this Geoencode Plug-in? If so could you point out which instruction I should follow to do the same with my entire catalogue?
Forgive my dimness, but did you create your Photo Map using this Geoencode Plug-in? If so could you point out which instruction I should follow to do the same with my entire catalogue?
No, sorry, my blog’s photo map is a separate creation. The photos were geoencoded within Lightroom using my plugin, then exported to my blog via Lightroom, but after that the photo map is its own thing. —Jeffrey
Jeffrey – many thanks for your excellent plugins.
Since Lightroom Classic recently upgraded itself to 9.0, and I reregistered my JF plugins, I’m getting an error message when I try to geoencode images using the “Static Location” option, either from a saved preset or by pasting in the coordinates.
The error message “?:0: attempt to perform arithmetic on a nil value” occurs twice followed by
“An internal error has occurred.
?:0: attempt to perform arithmetic on a nil value”
Is this a known problem?
It’s not a known problem. I’d appreciate it if you could send a plugin log just after encountering it. —Jeffrey
I had to reinstall all my plug-ins into LR 9. Now I’m getting thes error message in a log file. I’m using version 336, which I just downloaded:
Plug-in error log for plug-in at: C:\Users\phil\AppData\Roaming\Adobe\Lightroom\Plug-Ins\gps-jfriedl.lrplugin
**** Error 1
Could not create info sections for plug-in.
There is something wrong in CryptUnprotectData.
**** Error 2
Could not create info sections for plug-in.
There is something wrong in CryptUnprotectData.
I’ve not seen this before, but I’d guess it’s related to a bad copy of the plugin. Maybe try a different unzipper? —Jeffrey
Jeffrey – I sent the plugin log as requested.
For clarity, the problem occurs when I try to encode using the Static Location option, pasting in co-oordinates copied from Google Earth.
I have since discovered that although the geoencoding provokes an error message, the encoding is actually successful.
But if I have selected several and am trying to apply the same GPS co-ordinates to each, only the first image is successfully encoded.
When I geoencode from a gpx log (created by the ViewRanger iPhone app) it works successfully, as it always has.
I tracked this down to a bug in Lightroom, and have submitted a report to Adobe. The first image might seem to be successfully geoencoded despite the error, but in reality the catalog seems to be only partially updated. For example, with the Library Grid Filter set to “GPS data”, the image shows up under “No Coordinates”. Hopefully Adobe will address this issue quickly. —Jeffrey
Jeffrey,
Responding to your comments to my comment submitted November 19th, 2019 at 5:52am JST, two points.
I have used the same unzipper (7ZIP) for any number of files to zip and unzip, including all your plug-ins. No issues.
Adrian Walmsley’s comments submitted Nov. 10 and Nov. 20 seem to be describing the same issue I reported.
It’s a bummer that it’s an Adobe bug. You shouldn’t have to be (unpaid) quality assurance for Adobe. I can only hope that Adobe releases a fix for this bug before the normal 2 month release cadence. That cadence would mean a fix towards the end of December. Ugh!
I’ve done some more digging on the error message, and it seems to be a Windows-only issue related to saved passwords or other saved sensitive data. I’m at a loss to guess what this has to do with the plugin loading. The plugin doesn’t use that facility at all…. —Jeffrey
Hi Jeffrey
I have not been using your normally-marvelous plugin for well over a year because of the Google-API issue but now I have found a remedy that lets me insert my own Google-API key into the Lightroom (v 6.14) Location module. This was posted by “chicken” at https://github.com/astuder/lightroom-map-fix. It lets it work just like before, though I may not be remembering clearly as it’s been so long.
So back I go to the jf Geocoding Support and immediately I get the dreaded message that “There is something wrong in CryptUnprotectData”. I updated the plugin’s version by deleting its Modules folder and copying a fresh one of the latest version (20191118.336) and started Lr over again. Same problem. In the Plugin Manager it says that the plugin “is enabled, but has encountered some problems”. I saved the diagnostic to a file and it contains “Could not create info sections for plug-in”.
I went back over everything to do with Facebook and Flickr and disabled/eliminated them. Still no good. Maybe there’s something I missed but I don’t think so.
When I try using the plugin I get fairly frequent CryptUnprotectData messages and nothing is achieved. It seems that your plugin isn’t installing completely.
Please help!
Thanks
Mike
I don’t know where that Lightroom error comes from, but I’ve made an educated guess and made a blind update to the plugin that might help. —Jeffrey
I think I’ve managed to create Google AIP key for Geoencoding reverse lookup, Elevation and Time Zone. I bounced around the Cloud Developer site like a rat in a maze clicking randomly until pieces fell into place.
Google is offering to rescrict use of my API key in ways that my prevent others from using it (don’t know if that’s much of a problem). How would I restrict the key just for use by the GPS plugin?
From: Front Range, Colorado, US
That restriction that they’re talking about is aimed at web sites hosting tools that use their API (so that other web sites can’t use the same key, which may be visible in the web-site code). It makes little sense to use in this case, but if you have a static IP address, you could restrict use that that IP. —Jeffrey
I’m getting a plug-in error on my MacBook Pro with the 2019-12-04 and previous verson.
“?:0: attempt to perform arithmetic on a nil value”
The error seems to occur when I deduced that I need to change a parameter of the plugin (i.e. timezone) and try to run a second time on the same set of images.
It’s a known error that I’ve reported to Adobe. We can only wait for a fix )-; —Jeffrey
I’m very frustrated with the results. Lightroom is returning better and more precise reverse geoecoding data
Lightroom uses Google’s reverse geocoding service. The plugin can use either Google (if you provide your own API key), or OpenStreetMap. With the former, the preciseness is exactly the same as Lightroom, but with the plugin the formatting is personally configurable, so is better (or at least the same). —Jeffrey
re my post on on November 23rd, 2019 at 5:30am JST.
Whatever your educated guess was seems to have worked. I haven’t had the error message since updating the plugin.
Thanks very much Jeffrey!
I downloaded the 337 version but I am still getting those weird error messages, “There is something wrong in CryptUnprotectData.” I was trying to do a bulk reverse-geo-encoding operation.
I’m on LR 9.1. Had I known about this issue, I never would have upgraded. But I’ve done too much work with the LR 9 catalog to simply go back to my last copy of the LR 8 catalog.
Is there anything I (or others) can do to raise an issue on the Adobe LR forum?
I’ve just pushed out a new version of the plugin that lets you bypass that stuff completely… when registering your API key with the plugin, choose “Save to Lightroom Preferences”. —Jeffrey
I’m using the plugin to “confirm” the geocoding information “suggested” by LR Map module.
Is there a means to identify whether the plugin has not been run on an image with geoposition and proposed geocoding information?
It’s easy to create a smart collection that identifies images w/o geoposition, but I haven’t found a way to distinguish wether geoencoded information is “italicized” or not.
Thanks for your advise.
My plugin has nothing to do with Lightroom’s own “suggested” info… that’s all within Lightroom, and plugins have no insight into that or its data, until you “confirm” a specific photo. In other words, “no”. )-: —Jeffrey
Hi – thanks so much for these great plugins. I am using non-subscription LR6.14 on a Mac. I have used the Guess Timezone feature in your Geoencode plugin and this works great within Lightroom. What I am able to do for e.g. reverse geoencoding results, but not for this Timezone data, is to store the information directly in the picture’s Metadata. I.e. when I save Metadata to file and then run exiftool over it, I can find location data but not Timezone data. Is there any way to save Timezone to the file’s metadata in LR6.14?
Thank you so much, Chris
No, unfortunately, Lightroom doesn’t save plugin private data to an image’s in-file metadata. —Jeffrey
Good news – the Lightroom bug described in http://regex.info/blog/lightroom-goodies/gps#comment-59511 seems to have been fixed in Lightroom Classic with the 9.2 update just released.
I can now geocode from a static address again.
Hi – I’ve been aware of your plugins for a while but only started using in anger recently. I somehow think this must be “user error’ as no one else appears to have any problem remotely like I encounter…….and I what I’m trying to achieve appears pretty trivial compared to the functionality available in the plugin.
I was reminded of your plugins from the W3W website…..and my immediate requirement is simply to add the w3w address to images I have already Geoencoded from the LR Map Module. I’m sure I will have other uses, but I can’t even get this simple feature to work?
All of the ‘View’ functions work, and the “Get W3W Location”, but using the Geoencoding Dialog to fill the W3W location (or it seems any other metadata) does not appear to function even though the Plugin reports no errors.
Mac OS, LR & Plugin all on latest versions.
Hoping you can help,
Leigh
You’re referring to the “Fill w3w” button on the “Etc” tab of the Geoencoding Support dialog, right? It should work, and report how many images were updated. Perhaps send a plugin log after you encounter a failure? —Jeffrey
Hello Jeffrey
Thank you for your great set of LR plugins which I use a lot.
I am testing your geocoding plugin. It works fine, except that the time difference between camera and tracker app remains tricky and error prone. And time corrections need to be done manually.
Do you know about Gps4cam and its brilliant solution to this problem? This geocoding app automatically corrects camera times, and works even across time zones.
It works as follows: at the end of a trip you shoot a reference photo of an image produced by the gps4cam tracking app on your smartphone. The gps4cam desktop app then corrects all photo times and inserts the geotags using this reference photo. Do this with all cameras used during the trip and all photos are synchronised perfectly. I have been using it for years to time sync the pictures my wife and I take during our travels. Simply great.
Unfortunately gps4cam is no longer supported, and I am struggling to keep the desktop app running on a Windows7 (virtual) machine. Both the Windows and macOS desktop apps are still available, but they require an older version of Java. The Android app is still available, sadly the IOS version has been removed by Apple. I have unsuccessfully tried to contact the author with a view to explore ways of resurrecting the app.
I wonder if you would consider implementing this method in your plugin?
It would require a mini smartphone app to create the sync picture. Gps4cam generates a QR code containing date/time info as well as the full track. Sadly it seems to be in binary, not a text file, otherwise I would have sent you a test set to experiment with.
Grateful for your views,
Thank you,
Edwin Hermans
info on: gps4cam.com
That sounds like a nice solution, but a lot of work to create. Perhaps consider what I do: take a photo of an accurate clock (e.g. the clock app on your smartphone). In Lightroom, select all photos from about the same time, and make the clock photo the “most selected” one. Then use Lightroom’s basic update-timestamp feature to adjust the time of the clock photo to the time shown in the clock photo; Lightroom will then adjust all the other images accordingly. —Jeffrey
Using it everyday since years, thanks.
Could you add View location at opentopomap ?
https://opentopomap.org/
Added to the version that I just released. —Jeffrey
I’m getting a “Plug-in ‘jf Geocoding Support’ performing shutdown tasks” alert more often with my larger catalogs in Lightroom. Usually, it is just a minute or two, but currently, the one has been on the screen for over 10 minutes. I love this tool, and I guess I can just cancel it – except this time, I’m getting the beachball – but I just want to make sure there is not something wrong with my catalog or the plugin that might be causing this issue.
screenshot
The shutdown tasks should take just a fraction of a second, so if it’s taking a minute, something feels wrong. I don’t have any idea what that something might be, but perhaps start with checking the integrity of your catalog, and then optimizing it for good measure. —Jeffrey
Hi Jeffrey,
I just installed the Geocoding Addin. Its just great! 🙂
But … 😉 is there a reason that the “Configure URLs” at “Set Map URLs” is not listing OpenTopo?
Thanks in advance & Best Regards
Günther
The reason is that the “Configure URLs…” stuff was developed before any of the “View at…” stuff was; I never thought to tie the two together. I’ve done that for some of them now, including OpenTopoMap, so if you update, it should work. Thanks for the idea. —Jeffrey
Jeffrey,
With release 340 I was hoping that the weird errror message “There is something wrong in CryptUnprotectData” would be gone. No such luck. I am using LR Classic 9.2 on Windows 10 Pro 64. Bummer.
To avoid that error, you have to re-configure your Google API key, choosing “save to Lightroom preferences”… —Jeffrey
Jeffrey,
I’m writing you from Bradenton, FL USA. Any chance of adding support for Azure’s reverse geocoding API? I’m asking as I get a monthly credit toward Azure services.
Thanks!
Probably not, sorry. Given the work it would entail, and the apparent lack of demand (present company excepted), it just doesn’t seem worth it. —Jeffrey
Jeffrey,
I just want to express my deep appreciation for all the work you do with Lightroom plug-ins, including this one, and your dedication to supporting your users.
You (and John Beardsworth, John R Ellis and a few others) are the reason that I will probably never stop using Lightroom, unless Adobe tries to squeeze my wallet dry.
Phil Burton
I can see that the plugin can read Plus Codes, but is there a way to embed plus codes into a field similar to the “fill w3w” button on the etc… tab?
Thank you!
You can use the Write Data Field feature of my Bag-o-Goodies plugin, using {PlusCode} within your template to get the Plus Code. (I just added this feature, so if you already have that plugin, please update it.) What3Words has to be here because it can’t be accessed from a template due to the nature of how What3Words is implemented. —Jeffrey
How can I get rid of the annoying alert that hangs a while each time I quit LR?
I feel your pain. In trying to work around a problem in Lightroom, the plugin has to do a super-quick (done in miliseconds) housekeeping task when Lightroom ends. I’ve no idea why Lightroom feels the need to throw up that dialog, nor why sometimes it hangs there for seconds for something that should be over and done faster than the blink of an eye. Sometimes it’s quick. Well, I shouldn’t say “no idea why”… I suspect that the delay is just the catalog database flushing to disk, and that sometimes because of that delay Lightroom doesn’t get around to clearing the dialog quickly. In other words, I suspect that the dialog is not actually making the shutdown take longer… it’s just putting a face on the delay that is already there. But in any case, it’s super frustrating. —Jeffrey
The latest geoencoding zip file (20201018.345) is empty. Can’t install.
It’s certainly not empty on my server; please give another try downloading. —Jeffrey
Your zip is corrupted and unable to open.
Hi Jeffrey,
something with gps-20201018.345.zip is wrong. Chrome says something about of risk to download the file. And if i download the .zip (Chrome or Firefox), i can’t activate the plugin in LR.
Translation from German: An error occurred while reading the schema for the module “jf Geocoding Support”. The module is deactivated.
Hi
I have tried 5 times to download your LR10 compatible geocoding plugin and it never downloads fully — even after more than 1 hour. The .part file fills up to 7060KB and stops there. Of course the Zip file is 0 KB as mentioned in the previous comment (by Scott) and install is not possible
I really don’t think there’s a problem with the zip… if there were, I’d have literally thousands of complaints, instead of a few. What I don’t know is why there would be a few. Over the years I’ve gotten the occasional “the zip is corrupted” complaint, but it’s always been fixed by my suggesting to download with a different browser, or to unzip with a different tool, which suggests that the problem somehow lies in some fringe browsers/tools out there. But I don’t know. In any case, I just pushed out a new version (‘gps-20201028.346.zip’). If you have the standard program called sum, its output for the zip should be “54779 7062“, so you can check to ensure that you’ve received it properly. —Jeffrey
You are right Jeffrey: nothing wrong with your zip file…
The problem was on my side. Do not know the reason : slow internet ? US/European restrictions (I am currently in France) ?
Anyway, I asked my son who lives in the US to download the zip file and forward it to me via our Dropbox. I am up and running….
Sorry for the trouble.
Cheers,
Pierre
Jeffrey,
Are you planning on updating the GPS LR pluggin for the new version of LR?
Hope so, I so count on it.
Thanks
Patrick
I updated all my plugins a few hours after Adobe announced Lr10. —Jeffrey
Jeffrey,
Any suggestions on what the issue is when I try and install version 346?
I really want the geocode pluggin.
Thanks,
Patrick
Pretty much every time I hear that someone can’t install the latest version, it turns out that they were really trying to install some older version lying around on their system somewhere. So I’d suggest to delete all copies of the plugin and plugin zip files that you can find anywhere on your system, then download the latest from my server, unzip it, move it to where you want it to live on your system (and if that’s in a different place than it was before, point the Plugin Manager at the new copy). —Jeffrey
The issue seems to have been another plugin. Once it was handled I was able to install geocode
🙂
I’d be very curious to hear what the issue was; one plugin shouldn’t have the ability to cause install problems for another. —Jeffrey
Love the Peakfinder connection in the Plug-in. Only noticed this today – will save me a lot of time sorting out mountain shots. Thanks!
After geocoding some files I used your Geocoding View to see the Bearing (and speed) and it works great. Awesome! Is there a way to also put the Bearing in the Direction field so when I upload my 360 street view images, they will be oriented “correctly”, Bearing doesn’t appear to be used by any of the software pgms I use to upload to Google Streetview, only Direction. (Yes I know that LR turns all numeric values of Direction to the 8 primary directional words, silly LR… I’m ok with that even though it’s not ideal)
When I view the image exif in an external tool like ExifTool, the Bearing doesn’t show up, but Direction does. Does that mean that Bearing only lives in the LR cat? I don’t use sidecar files for my 360’s. I also tried to export and then look, but it still wasn’t there.
If your Geoencoding Support” Plugin cannot also update the Direction, do you know another program that can copy the LR Bearing to Direction?
I’m not familiar with this “Direction” field, but could it be the GPSImgDirection field? That’s the direction that the camera is facing, while the plugin’s Bearing is the direction of travel at the time the image was taken. If you want to copy the latter to the former (because, for example, you had a camera mounted on a car facing forward), you might consider using my Run Any Command plugin to invoke ExifTool to copy over the data. —Jeffrey
Hi Jeffrey,
I noticed that your website is only available via http, but not https. Most browsers (like chrome and firefox) block unsecure connections these days, so users cannot reach your site. You just get an error message saying the site is not available. Maybe sth to change on the server-end?
Kind regards,
Ben
I have had a secure server at this site for decades, but it is a different set of documents than the non-secure server. It is wrong to assume that they should be the same. —Jeffrey
Hi
Thank you very much for this plugin, its fantastic! however what can we do for video files? It seems its not possible to add GPS metadata to video files out of LR . I would like to save the GPS metadata to video files also….
This seems to be a bug in Lightroom. I’ve reported it to Adobe. Until fixed, you can use my Run-any-Command plugin to inject the coordinates, running:
exiftool -GPSLatitude="{Latitude}" -GPSLongitude="{Longitude}" "{FILE}"for the per-image command. For this, you need to have ExifTool installed, and of course, update the “exiftool” in the command so that you have the full path to it (where it’s “exiftool.exe” on Windows). —Jeffrey
Hi Jeffrey, I’ve been using your flickr and geo plug-ins ever since, so far never any problems, thanks!
with the latest LR upgrade and re-registration, the geo plugin won’t work, telling me that “current location has not been verified’. GPS coordinates exist, I have no clue what this could mean. any idea? Thanks!
I’ve got no clue either where that might be coming from, or what it means. Could you send a log, and perhaps a screenshot, the next time you encounter it? —Jeffrey
Hi,
I’m using LRC 11.0.1 (german) the plugin version 20211018.350.
When I’m using OpenStreetMap to geoencode some pictures there some inaccurate results.
An example:
GPS: 53°48’26.7578″ N 8°54’14.7928″ E
City: „Samtgemeinde Land Hadeln“
But correct would be
City: „Otterndorf“
„Otterndorf“ is a part of „Samtgemeinde Land Hadeln“ as some other cities around.
„Samtgemeinde Land Hadeln“ is comparable with counties in the USA.
Is this a problem of OSM?
Regards
Hans-Peter Dorn
For that area, OSM returns “Samtgemeinde Land Hadeln” as a “municipality” and “Otterndorf” as a “town”, and my plugin gives priority to “municipality” over “town”. In this case, that doesn’t match what you want, but it might match what someone else wants, and it might match what you want in a different location. It’s hard to predict. It would be best if my plugin made this configurable somehow. I’ll have to give it some thought… —Jeffrey
Hi Jeffrey,
I was using this plugins over years on my Windows-Machine. This year I switched to Mac.
For any reason it stopped working.
I am using a registered copy of “Geoencoding Support” Plugin Version 20220120.352 on Lightroom Classic-Version: 11.1 [ 202112022200-7fd1f998 ], Mac OS 12 – Version: 12.1.0 [21C52] – arm64.
Tried to geoencode 8 pics from a track log in gpa format (downloaded from a recorded walk on kommod.de (worked perfect multiple times). Your plugin confirms “images processed successfully: 8” but I cannot find any GPS coordinates in meta data of any pic.
Any suggestion?
Thanks so much!!
Micha
How exactly are you checking for coordinates, and what is the indication that they’re not there? —Jeffrey
Hi Jeffrey,
I am Using LrC 11.1 on macOS Monterey (M1) with licensed Geoencoding Plugin 20220120.352.
When I try to encode a few or single photo from a gpx file (exported from kommot) the plugin detects 718 datapoints. After processing it tells me that all pics were processed successfully. But I can’t see the GPS coordinates being stored to the photos.
On my Windows Machine all worked fine in the past.
What am I doing wrong?
Thanks
Micha
How have you checked for coordinates being stored to the photos? Do they show up on the map in the Map Module? When you view individual photos in Library, does the metadata panel show an empty box where the coordinates should be? —Jeffrey
Hi again,
just a quick note to let you know, still using geoencode as it works so well. And the $5 was just to renew my licence following a reistall of LR on a new laptop – couln’t leave $0.01 as it would seem just too insulting and hope this ‘refresh’ donation will at least get you a coffee 🙂
regards
and thanks for such a great app
Dave
Hey All, just wondering if there is a setting I can’t find in this plugin that will also write the location field into to the keywords while I am doing a reverse geocode? Right now my workflow takes me out of lightroom to just do that one task. Thank you.
My Metadata Wrangler plugin can inject data into keywords and some other fields, upon export. —Jeffrey
Hey Jeffrey,
Does your plug in write the location information directly to the photo file?
I am not a lightroom user but your plug-ins may be enough of a reason to switch. I did a test case and while the location data is visible in lightroom, I do not see it in Capture One, ACDsee, or the properties of the photos.
Frankly, your work is astounding.
Lightroom and the plugin update the database with location information, but it’s not normally written back out to the original master file. You can request that updated metadata is written out to the master file, but that works only for certain file types… non-DNG raw files, for example, have the updated metadata written to an XMP sidecar. If your only desire is to get location info into your files, Lightroom seems to be overkill. If you’re handy with the command line, consider ExifTool. There’s also something called “GeoTagr” or “Geo Tagger” or the like…. —Jeffrey
Hi Jeffrey,
I am not sure if this is an issue with the plugin, but when I try to view photos with OpenStreetMap it fails to load, it appears the URI scheme is HTTP and not HTTPS. Only OpenStreetMap is affected
Plugin Verson: Version 20220606.354
Thanks for the heads up. I’ve pushed out a new version. —Jeffrey
This method solves the persistent “There is something wrong in cryptunprotectdata” message:
https://forums.negativelabpro.com/t/cryptunprotectdata-workaround/3712/1
Hope this saves others time for Googling a solution.
Thanks!