Geosetter configuration after Google Maps API changes

[jch2103]

Friedemann Schmidt has posted instructions on how to use GeoSetter with Google Maps following changes to their API. If you have a Google Maps API key, you can use it in Geosetter with this information:

http://www.geosetter.de/mantis/file_download.php?file_id=739&type=bug

I can confirm that it works. Normally, I'd just use IMatch but Geosetter is useful for dealing with fixing some problem files that have incorrect GPS coordinates.

[Carlo Didier]

Excellent! Thanks for the tip.

There's just one typo in your doc. Instead of "file:///..." it should be "file://...", only two "/", not three.

[PaulS]

Very cool!  Thanks John.

[Mario]

I can confirm that it works. Normally, I'd just use IMatch but Geosetter is useful for dealing with fixing some problem files that have incorrect GPS coordinates.

Anything that's useful for more than a few users and maybe should be added to the IMatch Map Panel?

[jch2103]

I can confirm that it works. Normally, I'd just use IMatch but Geosetter is useful for dealing with fixing some problem files that have incorrect GPS coordinates.

Anything that's useful for more than a few users and maybe should be added to the IMatch Map Panel?

Yes.

#1. The 'Ignore files with existing GPS data' checkmark doesn't seem to do anything currently (see https://www.photools.com/community/index.php?topic=8692.0).

#2. I was working with images taken during a 14 hour day, with the latest version of Nikon's SnapBridge and my Nikon Z6. Some images were tagged with inaccurate GPS coordinates, but I had also recorded a GPX track using my Garmin 935 watch which proved much more accurate. (See https://www.dpreview.com/forums/post/62161884 for details).

I had two issues with the IMatch Map Panel for the GPX track; the first issue related to #1 above, the other with locating my images within the long GPX track (that is, the images were within only a portion of the track) and applying the proper time zone offset. In my prior use of the Map Panel, I hadn't run into issues, mostly because the images hadn't had existing coordinates. In this case, the combination of #1 above and the long GPX track relative to the time interval during which images were taken made it difficult to try to set the proper offset.

The Help refers to the screenshot of the Time Zone Offset window, "1 The timeline gathered from all images in the current scope (selected files in the active File Window)." However, it actually seems to include all files in the current active File Window, irrespective of whether they are selected or not (is this bug #2?). In my situation, the File Window included images from days before and after the images I was working with, so the Settings window showed the images spanned 296.90 hours(!).  See screenshot.

To further complicate things for me, the TZ Offset window File Timeline referred to Local time (i.e., -7:00 UTC on my home desktop) rather than the time zone where the images were taken (-10:00 UTC), and because of bug #1 showed 0 of 0 files mapped.

I then turned to GeoSetter and was able to geocode all of the images after using a -10 hour offset between images and my 0:00 UTC GPX track.

[Mario]

I will look into your #1 issue for one of the next releases. Thus bug report is still open but I'm working on other important things right now and it might take a bit until I get there.

If you found a bug, please add a bug report. If you want a feature enhancement, please post it in the FR board.
This "Off Topic" board is not the right place and I will not remember in a month.

To further complicate things for me, the TZ Offset window File Timeline referred to Local time

A track log covering 300 (!) hours is a bit unusual.
The purpose of this offset is to match the time recorded in the track log with the time recorded in the EXIF record of your images.
Basically, how many hours and minutes to add/remove to/from the image time time to fit it to the track log.
Track logs (supposedly) record time always in UTC. This is the base on which the Map Panel has to operate.
Timestamps in EXIF are usually in local time (whatever is set in the camera).

The track log offset displays UTC time and the matching local time, as a hint.

[jch2103]

A track log covering 300 (!) hours is a bit unusual.

No, the track log was only ~11 hours. The 300 hours was the time span for the image files in that folder.

[Mario]

Right. My bad.

[eritch]

Friedemann Schmidt has posted instructions on how to use GeoSetter with Google Maps following changes to their API. If you have a Google Maps API key, you can use it in Geosetter with this information:

http://www.geosetter.de/mantis/file_download.php?file_id=739&type=bug

I can confirm that it works. Normally, I'd just use IMatch but Geosetter is useful for dealing with fixing some problem files that have incorrect GPS coordinates.

It would appear that GeoSetter's Mantis bug tracking database is down.  Does anyone have a copy of the instructions that they wouldn't mind posting elsewhere?

[Mario]

Which things you can do in GeoSetter which you cannot do in the Map Panel in IMatch 2019?
I'm always interested in potential improvements - unless this something really specific for GPS nerds only 

[PaulS]

Here is what I have from January 2019.  Maybe this will help?

[eritch]

Thanks!  That does help!

As for using GeoSetter over iMatch, it's more a matter of it being a fairly lightweight program that I can use on low-resource computers fairly easily.

[ColinIM]

Which things you can do in GeoSetter which you cannot do in the Map Panel in IMatch 2019?
I'm always interested in potential improvements - unless this something really specific for GPS nerds only 

I think this reply will be for 'GPS nerds' only  and I'm quite sure that 'GPS Altitude' has been discussed (and a conclusion has been reached) previously on this Forum, but I'm simply offering this hint below in response to your invitation Mario - in case it might someday be feasible.

I do like the ability in Geosetter to readily obtain an Altitude value for the current GPS coordinates:
GPS Altitude / {File.MD.XMP::exif\GPSAltitude\GPSAltitude\0}

And frustratingly (for me), I can't get an Altitude value from the IMatch Map Panel, even when I use the Locations or Lookup features.

In some of my pre-defined Locations I've even pre-populated the Altitude value using the Location Editor, and I'm still surprised that that preset Altitude is not one of the metadata values inserted into my selected files (even with the "Update only empty fields ..." UNticked) when I 'Apply' that Location data to them.

I accept that 'Altitude' is one of the least standardized EXIF parameters, and it's true that the photographer's 'altitude' value returned by Geosetter often needs to be adjusted when (for example) I took the photo while standing on a bridge, or on the ninth floor of a building in a city, but 'Altitude' is still an important detail for me, so Geosetter is my preferred tool at this stage in my workflow.

(In Geosetter, I use the button labelled Get from Web on the Location tab in the Edit Data dialogue. (Accessible via CTRL+E in Geosetter.)

This (Altitude value) is indeed a minor frustration with the otherwise superb Map Panel, and I do recall that we've discussed (and concluded) this topic already in the distant past, otherwise I would raise a Feature Request. Nevertheless, this (GPS Altitude) is the sole reason that I prefer Geosetter for injecting GPS data into my photos 

[Mario]

Not sure that I can follow.

I have no problems getting Altitude when using the reverse-geocoding in IMatch (what you call "Get from Web" in GeoCoder).

It#s only the pre-made locations you can create in the Map Panel which don't handle Altitude property always.
But this feature is only rarely used. Most users let IMatch reverse geocode their files using Google, GeoNames or HERE. Easy, always precise.

[jch2103]

I have no problems getting Altitude when using the reverse-geocoding in IMatch (what you call "Get from Web" in GeoCoder).

I think I see the issue. When you use the Map panel to generate location coordinates, it doesn't populate Elevation. It's not until you run Reverse Geocode that the Elevation field gets populated.

There are a number of situations where I will use the Map panel to record location coordinates, but I may not run Reverse Geocode (usually if I use a Metadata Template to record a frequently used Country/State/City but don't care about Location).

If the Map panel recorded Elevation as well as coordinates, that wouldn't be an issue. Should we make this a feature request?

[GPS geek note: Doing a Reverse Geocode will fill in data for GPS Dest as well as location lat/long. As noted above, GPS Altitude is filled in then, and also Location Shown GPS Altitude. However, it appears that the same altitude value is used for both tags (based on my very limited testing). I don't know if that's because of what Google returns for a lookup, or if there are other reasons.]

[Mario]

Both EXIF and XMP have only one Altitude component. No separation between shown and created coordinates. A limit in the standards.

Applying a coordinate to selected files in the map panel also sets Altitude. Just checked, works.

[jch2103]

Both EXIF and XMP have only one Altitude component. No separation between shown and created coordinates. A limit in the standards.

Applying a coordinate to selected files in the map panel also sets Altitude. Just checked, works.

Umm, not what I'm seeing. I took three NEF files for which I'd added location coordinates from the Map window.
1. Location added in Map window: ECP output doesn't show an 'altitude' tag. (DSC_2582.txt)
2. Location added in Map window, reverse geocoded: ECP output shows 'altitude' tag and value. (DSC_2580.txt)
3. Location added in Map window, added destination shown, reverse geocoded: ECP output shows 'altitude tag and value (DSC_2579). Also, the Metadata Browser for this file shows two altitude tags, XMP::exif\GPSAltitude\GPSAltitude\0 and XMP::iptcExt\LocationShownGPSAltitude\LocationShownGPSAltitude\0. (Both tags have the same data value.)

[Mario]

Manual or automatic reverse geo-coding is required for setting the Altitude.
The maps used by the map panel don't provide elevation data, this requires separate API calls (to get the Altitude).

IMatch combines this with the manual or automatic (recommended) reverse geocoding.
You have a free choice between GeoNames.org, Google and HERE. Pick the service you like best.

This is how this is implemented in IMatch.

[ColinIM]

Thank you John for following up on this with more details than I had provided, and thank you Mario for explaining the behavior further.

Regarding the Altitude being returned (in some cases) by the Reverse Geocode option ... I had long ago stopped trusting the Location data returned by a Reverse Geocode and - as I should have mentioned - I rarely do a 'direct' Reverse Geocode on my photos now.

The Reverse Geocoded Location and State values will often not match the names and identities that are in common use locally here, at least around the South West of England, and I found it easier and quicker to enter them manually on groups of photos, rather than reviewing and sometimes second-guessing multiple Reverse Geocoded Location values.

So, for me, Reverse Geocoding is a bit of a mixed blessing. A sort of "swings and roundabouts" option  ... and of course IMatch allows us the freedom to "choose the best tool for the job in hand"! (Excuse the mixed metaphors  )

[jch2103]

Manual or automatic reverse geo-coding is required for setting the Altitude.
The maps used by the map panel don't provide elevation data, this requires separate API calls (to get the Altitude).

Thank you for the clarification on how IM works re altitude data.

[hamishr]

I came across this discussion when searching to find out if I could enter elevation from the IMatch map panel. Yes, updating the elevation metadata is a greatly desirable feature and when I set up my Google API key I included the Maps Elevation API, assuming it would be needed. Rather than using the Geosetter app (more stuff to get my head round), my manual work-around is to use Google Earth as it is easy to hover the mouse icon over the location and read off elevation from the bottom right-hand corner of the window. Elevation is quick to enter manually, unlike the coordinates and it doesn't change as much as  the coordinates.

[Mario]

IMatch automatically retrieves elevation when you do reverse geo-code. Why don't you just use that instead of manually entering elevation?

[hamishr]

I tried out reverse geocoding but it comes up with locations well away from where I actually was. For instance, I was on a hike in the mountains near Cape Town where elevation changes rapidly - reverse geocoding came up with locations in the nearby town and didn't even pick up the nature reserve I was in. I am sure reverse geocoding works well in regions where there is dense geographical information such as in urban settings but not where I am.

[Mario]

IMatch offers 3 different reverse geo-coding services: GeoNames.org, Google and HERE.

Implementing an automatic lookup for elevation data every time you set or move a GPS coordinate on the Map panel would be possible.
But it could cause delays and of course additional cost. Google and HERE charge for API calls once you have exceeded your monthly free quota. And I don't want to abuse the free and paid for by volunteers GeoNames.org service more than required. IMatch could cache elevation data retrieved by GeoNames, but many users tell me that Google is more precise and covers wider areas. And HERE is focused on roads anyway.

If you think that I should add an automatic elevation lookup to the IMatch Map Panel, feel free to add a feature request in the feature request board. If a number of other users +1 your suggestion I will consider it.