Limitation of Automatic Reverse Geocoding

[novaca]

Is there a way to limit the automatic reverse geocoding to only some tags? 
For example, only at altitude.

[Mario]

No.

Why would you need such an option? Something like this was never requested before, so I wonder in which situation geocoding some files but not others automatically would be useful...?

[novaca]

...if I have already tagged files and I additionally specify the location on the map, the altitude is not updated. When reverse geotagging starts again, all values are overwritten (I don't always use the value that was automatically offered, so I don't want to have them overwritten).
So I would have to delete the original data first and then let only the empty fields be filled. But if, for example, I have Location not filled in, I would get filled in data that I don't want. Just like when I have described files where altitude (which I want to add) and Location (which I want to leave empty) are missing. To maintain control, I would have to pre-populate these fields to say "X" and after geotagging, use a filter to find and delete them. I also have no retroactive check that the elevation matches the gps coordinates (if I've adjusted the location in the past after geotagging).

So my idea was that I would enable automatic reverse geocoding and only the elevation would be automatically filled/adjusted when the file was placed or moved on the map panel. (I add names in batches with manual editing).
I hope it is understandable. Thank you.

[Mario]

I'm not quite sure I follow.
What do you mean by "already tagged files"? Usually "tagged" is used as a synonym for adding keywords...?

Is the problem that your geocoding service does not deliver the right altitude?

Have you enabled the Edit menu > Preferences > Geo & Maps: Retain existing altitude option?
This option was added to retain an existing Altitude when the geocoding service you use delivers the wrong altitude. This option is off by default.

The automatic reverse geocoding, when enabled, automatically fills all location tags. It also updates the location tags when you move the location of a file on the map, producing a new set of GPS coordinates. There are no further options.

If you are in the habit of manually filling (sometimes) some of the location fields or you move files on the map after manually setting or updating location data, I would suggest that you disable automatic reverse geocoding.

This way you can run reverse geocoding at a suitable stage in your workflow, and then change the data filled in by reverse geocoding to your liking. You can then also move files around on the map without their location data being updated.

[novaca]

Maybe I made it too complicated (given my ability to express myself in a foreign language), sorry.
I have files that already have tags written for "Country Code, Country Name, State, City, Location" (City and Location are blank for some though). Some of these files do not have the Altitude filled in, some have it out of date due to the additional coordinate change, and some are correct. Is there a way to bulk update/fill the Altitude so that the "Country Code, Country Name, State, City, Location" tags remain intact?

If it were possible to limit the reverse geocoding to only "Elevation" tags, I could do it this way.

Another advantage would be if I enabled automatic reverse geocoding with this constraint, IMatch would automatically sync the altitude with the GPS coordinates (when changed in the map panel). Then I wouldn't have to keep an eye on which files I need to perform revision geocoding again.

[Mario]

This sounds all very complicated.

Some of these files do not have the Altitude filled in, some have it out of date due to the additional coordinate change, and some are correct. Is there a way to bulk update/fill the Altitude so that the "Country Code, Country Name, State, City, Location" tags remain intact?

You mean via reverse geocoding?
No. Reverse geocoding always fills all location tags.

You can update the Altitude yourself in the Metadata Panel. If you have multiple files selected and you change only the Altitude (or click the pen in front of it to mark it as updated), only the Altitude tag is updated in the selected files. This would be the workflow to add or correct the Altitude for any number of files at once.

If you don't know the Altitude, do a Ctrl+G,R for one file. Copy the altitude returned by your geocoding service into the clipboard. Select all files you want to apply this altitude to and then paste the altitude into the altitude tag in the Metadata Panel. This updates all selected files.

[novaca]

I understand, thanks for the comments.
It concerns about 40,000 files, but I think I'll find a way around it.

[Mario]

If you have

a) files without altitude
b) files with correct altitude (for which reverse geocoding returns the 'wrong' altitude)
c) files with incorrect altitude 

there is no way reverse geocoding could figure that out or help you with that.
It's easy to filter for files with missing altitude but no way to filter for 'wrong' altitude.
Not with built-in features.

[novaca]

I will deal with this in several steps.

But what I found out only now, using Reverse Geocoding (Google):
after pressing Lookup it offers several Select Shown Address options and I can select the most appropriate one. However, each of these options will not only return different names, but also a different altitude! This makes this method of getting the altitude unusable for me and I will have to find another way/app to ensure that the altitude corresponds to the coordinates...

[Mario]

But what I found out only now, using Reverse Geocoding (Google):
after pressing Lookup it offers several Select Shown Address options and I can select the most appropriate one. However, each of these options will not only return different names, but also a different altitude! T

I have no control over the results of the reverse geocoding Google performs for your coordinates or the contents of their database. I suggest you contact Google about your findings and tell them where their altitude data is wrong.
IMatch uses the "elevation" API to retrieve altitude measurements for GPS coordinates from the Google cloud, if that's of any help.

Maybe you get better results with HERE or Bing...?

[novaca]

I tried GeoNames and it's the same (different results but same "property"). It seems that the detected altitude does not depend directly on the coordinates of the file, but on the Address that is found near...
Unfortunately, for a photo from the top of the mountain, it could be the address of a village in the valley.
To put it plainly, the altitude data obtained in this way is worthless - in uneven terrain, in the lowlands can +/- correspond.

[Mario]

That's nothing I can change. And, in my experience, most people don't care much for altitude, so maybe geocoding services also don't care too much.

[jch2103]

If you need to know altitude of specific geographic coordinate points, you might want to use a GPS unit/phone app to create a GPX log file that you can use in IMatch to geocode your photos. This may be additional work, but probably more accurate (although GPS vertical accuracy is not as good as horizontal accuracy). This can be especially useful if spending several hours in a photo shoot in multiple locations.

There are also various on-line GPS coordinate/elevation websites if you want to know elevation of particular known location points, e.g., https://www.freemaptools.com/elevation-finder.htm, https://www.advancedconverter.com/map-tools/find-altitude-by-coordinates, https://www.dcode.fr/earth-elevation, etc.

[novaca]

If you need to know altitude of specific geographic coordinate points, you might want to use a GPS unit/phone app to create a GPX log file that you can use in IMatch to geocode your photos.

Yes, that's a possibility. I have a great app (Locus) on my phone. But a lot of "handwork", perhaps for selected ones, not for the entire catalog.

[novaca]

That's nothing I can change. And, in my experience, most people don't care much for altitude, so maybe geocoding services also don't care too much.

I understand, beyond the interest of the majority.

Last question a bit off. Is it possible to make an OpenStreetMap layer other than Standard available? For example, the CyclOSM layer has nice contour lines (which, unlike Google terrain, do not disappear with zooming) and also has hiking/cycling paths. But maybe their license doesn't allow it, or it's not accessible via api.

[Mario]

Last question a bit off. Is it possible to make an OpenStreetMap layer other than Standard available? For example, the CyclOSM layer has nice contour lines (which, unlike Google terrain, do not disappear with zooming) and also has hiking/cycling paths. But maybe their license doesn't allow it, or it's not accessible via api.

IMatch already supports 4 different mapping services: Google, Bing, HERE and OpenStreetMap.
Which is kinda hard to support and maintain. I have to keep up support, implement changes in IMatch when their APIs change etc. This is a lot of work and I understand why most other DAM software just defaults to Google and that's it. Easier and cheaper. But I prefer to offer IMatch users choices and not forcing them to use a specific service like Google. Which probably would make me some extra money if I would force users to work with Google...

If you have a feature request, feel free to post it in the feature request board here in the community. Other users can comment and like your request. Which then tells me if only one or a handful users would need more altitude accuracy. Or many.

Adding and supporting yet another layer (in this case, a bicycle map) is probably doable. But what are the license details? What about the legal? The usage conditions?  And, most importantly, how many IMatch users would benefit from it?

OpenLayers has very restrictive and limiting policy for their reverse geocoding API. Which I understand and accept.
And which is also why IMatch does not support reverse geocoding via OpenStreetMap. It's just not doable using their license.

Again, IMHO, most users care a lot less about exact altitude than you. Which is fine, of course. Different users, different requirements.

If you have an app or service that produces better altitude data than the four geocoding services IMatch already supports, great! Use it to fill the location data in your files. IMatch will pick up the new data automatically and make it available to you.

[sinus]

I understand, thanks for the comments.
It concerns about 40,000 files, but I think I'll find a way around it.

40'000 files, well, ok, but how many different altitude, you guess, would that be?

Say, you are in London. Well, then it depends, how precise you will have the altitude. 

In fact, if you go up small "hill" there, then the altitude is maybe 20 Meters higher. Or you take pictures in the tube, then it is less high.
Are such things important for you? I guess, then it will be not easy. 

For me personally, the altitude from London is more or less equal, if my precision is about, phew, 10 Meters more or less does not care for me, I think, even 30 Meters would be ok, maybe the pictures has been taken inside a high tower. 

Altitude is important for me, I even use it in my personal timeline as a graphical view (bar-chart). 
But it is not that important like it was in my Military service, I was there a Aircraft photographer. 

[novaca]

Accuracy of 10, 20, 30 m for most photos is OK. But I like to take pictures in the mountains... I tested a photo from the top of a mountain that I know is 2108 m high - depending on the chosen Address from Reverse Geocoding, I got values in the range of 430 - 2093 m.
Unfortunately, there is no way to determine which option is applicable if, as in this case, I do not know the correct value in advance (the most accurate one was not the first one offered). If it can't be assigned automatically from Reverse Geocoding, at least a map with usable contour lines would help (I've created a Feature Request).

[novaca]

Solved
If you are interested.
A little annoying, but I think quite usable:

- in IMatch, mark the files for which you want to add/update the altitude.
- in the map panel, choose Generate KML File
- upload this file to https://www.gpsvisualizer.com/elevation
- select Convert and add elevation
- download the gpx file
- in IMatch in the map panel load this gpx file and apply to the same marked files as in the first step.
- Done

For my test batch of files, the deviation of the altitude obtained in this way compared to the elevations on the map was about -5 m (in the Alpine terrain).

[jch2103]

Cool! Another example of being able to do almost anything with IMatch!

[rolandgifford]

Have you enabled the Edit menu > Preferences > Geo & Maps: Retain existing altitude option?
This option was added to retain an existing Altitude when the geocoding service you use delivers the wrong altitude. This option is off by default.

I'm late to this topic which I have found useful.

As an aside, does reverse geocoding ever change the GPS coordinates o the image if a nearest location chosen manually or automatically for a selection of files not match the starting GPS coordinates? The top of the mountain/bottom of the mountain type issue

[Mario]

See Reverse Geocoding for details about reverse geocoding.

[novaca]

As an aside, does reverse geocoding ever change the GPS coordinates o the image if a nearest location chosen manually or automatically for a selection of files not match the starting GPS coordinates? The top of the mountain/bottom of the mountain type issue

No, definitely not. The coordinates will always be preserved.

It may just happen that these coordinates are assigned an altitude by Reverse Geocoding that does not correspond to the location they refer to.
Not a problem in densely populated or flat areas. In areas where this is not the case, do not rely on this altitude assignment. That is, if you already have an altitude assigned from another source, do not let it be overwritten in this way.

[Mario]

It may just happen that these coordinates are assigned an altitude by Reverse Geocoding that does not correspond to the location they refer to.

That's what reverse geocoding is supposed to do. It sends the lat/lon to the geocoding service and uses the information returned by the service into the corresponding metadata fields.
IMatch has no idea if the altitude/elevation returned by the service is correct.

Since several users (some years ago) reported that the altitude returned is not always correct (also depends on the service used and the location), IMatch offers the Edit > Preferences > Geo & Maps: Retain existing altitude to control this behavior and to optionally ignore the altitude returned by the service you use.

So, if you consider the altitude you enter more correct, enable this option before running reverse geocoding.

When you work with IMatch Locations and you assign a location to files, you can enable an option in the location to snap all coordinates of processed files to the lat/lon of the applied location. This can be very helpful for certain scenarios.

Using IMatch Locations instead o reverse geocoding gives users a lot more control, but it may be futile if your images are taken at many different locations. For photographers who shot the same locations, venues and in the same studio(s) often, IMatch Locations are the best choice and privacy friendly.

[novaca]

That's what reverse geocoding is supposed to do.

Yes.
I don't want it to sound like I think it's a mistake. It's just a feature I didn't understand at first. I originally thought that the altitude was determined from the coordinates and then nearby addresses were offered, not that the altitude of the chosen address was returned. My fault.

[Mario]

I don't want it to sound like I think it's a mistake. It's just a feature I didn't understand at first. I originally thought that the altitude was determined from the coordinates and then nearby addresses were offered, not that the altitude of the chosen address was returned. My fault.

I think the services argue that way: The user supplies a lat/lon and the services provide nearby address matches (each with a associated lat/lon/alt). They may not even have an altitude for the lat/lon provided by the user, only for the address records they maintain.

In my experience, most users are not much interested in a maximum precise altitude. Much more in the address data itself.
For hikers, bikers, mountaineers, skippers etc. altitude is much more important, and often there is no real address for a GPS coordinate.

This is why IMatch offers different service providers to choose from. And the option to keep the original altitude even if it does not match the address data used.

[novaca]

Only Google and GeoNames return me the elevation and they use the same principle. But you just need to know it and adapt the workflow to it (that's what you can take away from this thread, the topic of which seems already exhausted).
Thanks for showing direction.