gps-20090701.84.zip
· Version History
· Update Log via RSS
· Installation instructions
· More Lightroom Goodies
· All-Plugin Update Log via RSS
· My Photo-Tech Posts
· My Blog
This plugin – for Lightroom 2.0 and later – allows you to geoencode your photos from within Lightroom.
See the Introduction and Instructions for features that existed when I first released it, as well as the version-history below, for the many features that have been added since.
“Shadow” Data
As described on intro page, the plugin maintains “Shadow” GPS data, separate from any GPS data that may or may not be held in Lightroom's library database.
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.
As of version 20081102.9 the plugin allows you to 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.
Availability
I distribute this plugin as “donationware”. It is provide for free and is fully functional for the first six weeks, after which it becomes limited to processing at most 10 photos at a time until registered. Registration costs 1 cent; any additional donation you'd like to make in encouragement or thanks is up to you. For details, see my blog post titled Lightroom Plugin Development: Now With Added Encouragement.
( Update Log via RSS )| 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 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 th 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.