Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Yaobing]

Description:

Reverse GeoCoding is a process of obtaining geographical information, i.e. Country, State, City, etc. from an Internet server, using known GPS coordinates.

This feature is now available in Media Center 32.0.46 for images.

Instructions:

• Optional but recommended.  Go to site https://geocode.maps.co/ and create a free account by clicking the (red) button "Free API Key".  You can choose to upgrade to a paid account later if you so desired, but you probably don't need to.  If you do not create an account, free or otherwise, you will be sharing the same key with other Media Center users.
  
• In Standard View, using any image view, select a few image files (not too many, see below) that have data in Latitude and Longitude fields, and right click and choose "Reverse GeoCode".  Note that if the "Reverse GeoCode" menu item does not appear when you right-click, it is because your selection does not contain any files that have [Latitude] and [Longitude] fields filled.  If that is the case, you may try "Update library (from tags)" in case previous importing did not get the fields right.  The bottom-line is, you must have the GPS coordinates in order to use this feature.
  
• After you select "Reverse GeoCode" from the menu, Media Center may ask you whether you want to run "Update library (from tags)" because it found deficiencies in your selection.  There are two reasons this can happen, some selected files just don't have [Latitude] and [Longitude] data, or some files have [Latitude] and [Longitude] data that are not precise (they have only integer values for second of angle, for example, 20°13'3"N instead of 20°13'2.78"N).  After clicking the "Yes, update..." button, you should wait for the update to finish, and then try right-click > Reverse GeoCode again.  The update may or may not fix all the deficiencies.  So you may get the prompt again the second time around.  This time you should click "No, don't update..." button.
• When the process is complete, you should notice that [Country], [State/Province], [City], and [Sublocation] fields are filled, for the files that have valid [Latitude] and [Longitude] data and the server has data for the location.  Some locations will have no results because the server simply does not have any data.  An example would be an image taken on a cruise ship sailing on an ocean in the middle of nowhere.
  

We obtained an API KEY for Media Center, a free one.  There is a severe restriction on a free key.  They limit requests to ONE PER SECOND.  So, if multiple MC users use the feature at the same time, there is definitely going to be congestion.  If we make too many requests in a short time, the server may reject our requests altogether.   Therefore we recommend you signing up for your own key.

To mitigate this issue, Media Center pauses for 1 second between each requests.  Also, we determine if multiple images have coordinates that are close enough to each other, within a 20 meter x 20 meter box, if so, we do not hit the server again during the same session.

So, here are a couple of things that users can do, to make the process easier:

• Do not select too many files at one time.
  
• DO select images that were taken at the same location into a single batch.  This way we get the data for all of these images with one server request.  So it is very helpful if you sort your list of files by [Latitude] and by [Longitude] before you make your selection.
  

Additional comments:

Data quality from the server ranges from decent to great, depending on locations.  For example, an image taken somewhere in China may have the City field wrong.  Instead of the correct city name, the server sends a city subdistrict name as city.

Do let MC run "Update Library (from tags)" when prompted, because previously imported images might have latitude and longitude values rounded to the nearest number of seconds of angle, without the fractional part.

Make sure that [Latitude] and [Longitude] tags are not empty and that values are not rounded to nearest number of seconds.

Limit the number of files to 100 or less at a time.  See above for reason.

[marko]

Tried a few of these this morning... It worked well...

You do know though, don't you, that virtually nobody will acquaint themselves with the information provided above

Will be interesting to see how that pans out...

and, Yaobing, thank you very much for your time on this. Photo stuff is very important, the more that get on board with it, the better

I'll go wholesale at some point in the coming week and see how that fares.
For the first time in decades, I might need to rethink my workflow. Currently, all my places tags are kept in a nested "Locations" branch of [Keywords], so, I don't use the [Places] field at all...

This reverse geocode stuff is so simple though, it's brilliant 

[zybex]

Yaobing, maybe it's worth it to cache the query results locally with a large expiry time, or a manual "clear cache" option? The coordinates for London tend to stay the same over time.

Edit: Maybe it's already done, or is this only for the current batch?
7. Changed: During Reverse GeoCoding, if the GPS coordinates match (or are close enough) to an already processed image, we use the known data, instead of hitting the server again.

One other option is to allow the user to add its own API key for the service. This would reduce congestion, and some users may want to get a paid key.

[lello]

I selected a photo, right mouse but the Reverse GeoCoding item does not appear in the list: where am I wrong? ?

Obviously first I started Update library (from tags)

[zybex]

Check if the photo has info in the [Latitude] and [Longitude] tags.

[Yaobing]

Yaobing, maybe it's worth it to cache the query results locally with a large expiry time, or a manual "clear cache" option? The coordinates for London tend to stay the same over time.

Good idea.

Edit: Maybe it's already done, or is this only for the current batch?
7. Changed: During Reverse GeoCoding, if the GPS coordinates match (or are close enough) to an already processed image, we use the known data, instead of hitting the server again.

That is for the current batch.

One other option is to allow the enter to add its own API key for the service. This would reduce congestion, and some users may want to get a paid key.

I have thought about it and will try that too.  Not sure if the server cares about that.  It is called "API KEY", not "User Key".

[JimH]

Request here:  https://yabb.jriver.com/interact/index.php/board,13.0.html

[Doof]

Any reason not to direct users to register for their own API key and have MC use their own instead of a shared key? Even with the one second delay, you run the risk of hitting their limit once this version gets out into the hands of more users. Additionally, it would give users the flexibility of being able to pay for a higher tier key and geocode a higher volume of photos if they need to.

[Yaobing]

Any reason not to direct users to register for their own API key and have MC use their own instead of a shared key? Even with the one second delay, you run the risk of hitting their limit once this version gets out into the hands of more users. Additionally, it would give users the flexibility of being able to pay for a higher tier key and geocode a higher volume of photos if they need to.

There is no reason, other than not knowing how the server intends this key to be used.  I am implementing it for the next build.

[darichman]

Excellent. Thanks so much for incorporating this Yaobing & team

I prepared four files and did some testing
1. Has Coordinates, Has Place Tags already
2. Has Coordinates, No Place Tags
3. No coordinates, Has Place Data
4. No coordinates, No Place Data

Currently MC can help me address 1 & 2.

Where existing data is in the Place fields, MC will update/over-write existing entries (as expected)
Overall seems to work very well with a few test files (have not tried in bulk noting the API issues!)
I have not seen any errors, just a few quirks and incosistency with how granular the location data is in Geocode

Agree some fields end up empty. I tagged some from a recent farmstay not far from a major city in Australia lat 153°7'0.27"E  long 27°57'9.93"S
  [Country] Australia
  [State] Queensland
  [City] empty
  [Sublocation] Boyland, Boyland Road

Sublocation: I am not sure how the API handles sublocation queries...
See above, has two entries. I'm guessing we are limited by how data is stored on the geocode site (preference above would be for 'Boyland' to be the City and 'Boyland Road' to be the sublocation.

For a file with lat 27°29'2.12"S & long 153°1'36.66"E
It gives me [Sublocation] South Brisbane,South Brisbane,Stanley Street,Queensland Children's Hospital
   Country = Australia, State = Queensland, City = Brisbane City as expected
All of the entries populated in Sublocation are correct, but it would generally be desired to have a single entry, or to comma delimit them (or even nest them if they are predictably hierarchical)?
I am not sure why  South Brisbane would be duplicated in the above example.
See 'Sublocation Tag.jpeg' attached
Another consequence of this is that there must be a character limit when Lightroom reads the IPTC location field (see truncated value in LR IPTC Fields.jpeg)
Otherwise all Country, State, City, Sublocation visible in LR IPTC as expected

Would you consider using \ as the delimited in [Places] such that it can be nested in views?

Some indicator that the query is occurring could be helpful eg in the status bar Eg 'updating location data file 1/4' etc

I agree with others that I would pay for a user API if this were available. Can sometimes have a thousand photos to tag at a time, not to mention a library of several hundred thousand I may be going back to Don't want to stretch the friendship and get MC banned. And obviously would like longevity and reliability of the service.

Next feature will be 'Add coordinates from Map' to address scenarios 3 & 4 above

[Yaobing]

I updated the instructions.

Users can use their own key.
Data from the server is cached, so the next time you try to run it on an image that is taken at the same or near location, the server will not be involved.

[Yaobing]

a major city in Australia lat 153°7'0.27"E  long 27°57'9.93"S
  [Country] Australia
  [State] Queensland
  [City] empty
  [Sublocation] Boyland, Boyland Road

Code: [Select]

<addressparts>
<road>Boyland Road</road>
<city_district>Boyland</city_district>
<municipality>Scenic Rim Regional</municipality>
<state>Queensland</state>
<ISO3166-2-lvl4>AU-QLD</ISO3166-2-lvl4>
<country>Australia</country>
<country_code>au</country_code>
</addressparts>
The data returned has no <city> element.  We try <town> (seen in some of your previously provided sample images), and <village> (common in the US), if we don't find <city>.  Maybe we should also try using <municipality> if City is still empty.

For a file with lat 27°29'2.12"S & long 153°1'36.66"E
I am not sure why  South Brisbane would be duplicated in the above example.

Code: [Select]

<addressparts>
<amenity>Queensland Children&#039;s Hospital</amenity>
<house_number>501</house_number>
<road>Stanley Street</road>
<suburb>South Brisbane</suburb>
<city_district>South Brisbane</city_district>
<city>Brisbane City</city>
<state>Queensland</state>
<ISO3166-2-lvl4>AU-QLD</ISO3166-2-lvl4>
<postcode>4101</postcode>
<country>Australia</country>
<country_code>au</country_code>
</addressparts>

Here "South Brisbane" appears both as a <city_district> and a <suburb>.  Not sure how we should handle this.  Only use one?  Or don't use duplicate?

Would you consider using \ as the delimited in [Places] such that it can be nested in views?

[Places] is comma-delimited and that was not my decision (it has been like that for a long time).  I don't have a preference but I don't know if there was an initial reason for it.

[Sublocation] is delimited the same way.

Some indicator that the query is occurring could be helpful eg in the status bar Eg 'updating location data file 1/4' etc

Maybe.

I agree with others that I would pay for a user API if this were available. Can sometimes have a thousand photos to tag at a time, not to mention a library of several hundred thousand I may be going back to Don't want to stretch the friendship and get MC banned. And obviously would like longevity and reliability of the service.

Update MC to build 48.  You can use your own key.

Next feature will be 'Add coordinates from Map' to address scenarios 3 & 4 above

That seems to be more challenging.  We will see about that.

[darichman]

Changed: Reverse Geocoding will use "municipality" for [City] field, if other elements ("city", "town", or "village") are not found.

Sounds good. I hadn't realised they had such granular breakdown. In my 'Boyland' example, the Scenic Rim regional information would have been very useful, so agree with this.

Propose: [City] amalgamates municipality, city, town, village in the form Municipality\City\Town\Village ?
If any empty, they are ignored. If any identical, they are not duplicated? Would this be doable?
This ensures all useful permutations of the info is available, and also nested with the highest 'region' information (below state/province) captured, and ability to expand to smaller areas.

How are you handling sublocation? I can see various fields of 'Street', 'suburb', 'amenity' etc

Could we agree on the hierarchical structure of these? With some fields consolidated in a [City] hierarchy (like above) and others in a[Sublocation] hierarchy.
The broader [Places] could either be a non-hierachical ; delimited list (ie no nesting or groupings)
....or a full [Country]\[State]\[City - Municipality\City\City district\Town\Village]\[Sublocation - Suburb\Road\Amenity\]

Any thoughts from others?

Sorry Marko, this won't line up with your nested keywords approach, but the with magic of MC expressions I'm sure you can migrate (in either direction) as you desire

[Yaobing]

Propose: [City] amalgamates municipality, city, town, village in the form Municipality\City\Town\Village ?
If any empty, they are ignored. If any identical, they are not duplicated? Would this be doable?
This ensures all useful permutations of the info is available, and also nested with the highest 'region' information (below state/province) captured, and ability to expand to smaller areas.

This is interesting.  I am not sure if our users have already any fixed ideas about this field.  In the US, an address is almost always in the form of "### StreetName, CityName, StateName, PostalCode", where the StateName is the two letter abbreviation, while "CityName" can be a city (like Chicago), or a village, like Homewood.  It seems that the county and township names are always ignored.  No one pays any attention to them except at tax-paying time 

That is why I initially ignored <municipality>, as it is used to return Township name in my home location.

I would like other users to chime in on this.

How are you handling sublocation? I can see various fields of 'Street', 'suburb', 'amenity' etc

Could we agree on the hierarchical structure of these? With some fields consolidated in a [City] hierarchy (like above) and others in a[Sublocation] hierarchy.

This is the part that involved some guesswork by me and in need of more refinement.  We can try agreeing on some basic format.

Right now, [Sublocation] will contain most entries below [City].  For a rural location, there are not a lot.  Below <village>, I have seen <hamlet> for my home (which I didn't even knew we had) and <residential> for other locations, and then <road>, and <house_number>.  We ignore <house_number>.  So for my home location, [Sublocation] will contain "HamletName, StreetName", but for larger cities, we might have <city_district>, and other levels.  For example, a picture taken on University of Chicago campus has the following data:

Code: [Select]

<?xml version="1.0" encoding="UTF-8" ?>
<reversegeocode timestamp='Tue, 28 May 24 14:08:06 +0000' attribution='Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright' querystring='lat=41.7894749999999959&amp;lon=-87.5985000000000014&amp;api_key=664cb89f83401276276823uenaed537&amp;format=xml'>
<result place_id="330249619" osm_type="relation" osm_id="13117436" ref="The University of Chicago" lat="41.79139685" lon="-87.60084387193544" boundingbox="41.7877878,41.7949773,-87.6061459,-87.5894438" place_rank='30' address_rank='30'>
The University of Chicago, 5801, South Ellis Avenue, Hyde Park, Chicago, Hyde Park Township, Cook County, Illinois, 60637, United States
</result>

<addressparts>

<amenity>The University of Chicago</amenity>
<house_number>5801</house_number>
<road>South Ellis Avenue</road>
<quarter>Hyde Park</quarter>
<city>Chicago</city>
<municipality>Hyde Park Township</municipality>
<county>Cook County</county>
<state>Illinois</state>
<ISO3166-2-lvl4>US-IL</ISO3166-2-lvl4>
<postcode>60637</postcode>
<country>United States</country>
<country_code>us</country_code>
</addressparts>

</reversegeocode>

Here <municipality> "Hyde Park Township" is just a sub-district of the city of Chicago.  "Hyde Park Township" probably coincides with <quarter> "Hyde Park", which I had not included, and should include in [Sublocation].

<amenity>/<tourism>/<leisure>/<building>/<commercial> (usually only one of these) can be thought of as the "place of interest", and is included as the last level of [Sublocation], below <road> (Street).

The broader [Places] could either be a non-hierachical ; delimited list (ie no nesting or groupings)
....or a full [Country]\[State]\[City - Municipality\City\City district\Town\Village]\[Sublocation - Suburb\Road\Amenity\]

Any thoughts from others?

We should talk more about this.  I just followed previous code of combining Country, State, City, and added Sublocation after that.

[zybex]

Falsehoods programmers believe about addresses:
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

[JimH]

Programmers don't exist anymore.  They're developers now.  If I were either though, I'd want to give up after reading that.

[zybex]

But I thought developers built houses?