Author Topic: Reverse Geocoding Service Update  (Read 704 times)

Offline JS

  • Full Member
  • ***
  • Posts: 204
    • View Profile
Reverse Geocoding Service Update
« on: February 13, 2023, 01:13:44 PM »
 I don't like this update very much. Can I go back to the old style? For example: I photograph the Canal Grande di Trieste, standing just beside it. Before "Location" would have shown just " Canal Grande di Trieste", now it shows some cryptic " Palazzo Carciotti, Riva Tre Novembre, Riborgo, Città Nuova-Barriera Nuova-San Vito-Città Vecchia, Triest, Friaul-Julisch Venetien, 34121, Italien" Nobody can know what the foto shows. Just "Canal Grande", and everybody would understand.

Offline PabloGG

  • Camera Bits Staff
  • Newcomer
  • *****
  • Posts: 10
    • View Profile
Re: Reverse Geocoding Service Update
« Reply #1 on: February 13, 2023, 02:40:14 PM »
Hi JS,
Could you please provide me with the GPS location you are having issues with? That will help me better understand the root cause of your issue. If you prefer, you can email it directly to me at pablogg@camerabits.com.
Thanks,
-Pablo

Offline Jamie

  • Newcomer
  • *
  • Posts: 16
    • View Profile
Re: Reverse Geocoding Service Update
« Reply #2 on: February 19, 2023, 02:12:48 AM »
This release offers a fix that I, too, have requested. I read https://home.camerabits.com/2022/12/15/reverse-geocoding-updates/ with much interest. Unfortunately, it’s a case where the adage applies, “if that’s the solution, I want my problem back.” I am not being snarky. Instead, the release has shown me how hard a good solution is.

My issue is slightly different than JS’s. In my case, I want the location* field to show a street address and/or a location name. In the old version, geocoding often delivered just the house number (“472” instead of “472 S. First Avenue”), which was obviously flawed. If it returned “Eiffel Tower” that was often correct and acceptable for me. To compensate for the house numbers, I created a set of code replacements for places I commonly photograph and resorted to manual corrections for the rest.

The entire postal address, as found in the new version, is too much information. Country, city and state/province are redundant, since fields exist for those items. Isn’t the field “location” intended as a “sublocation” within the city?** If so, why the redundancy? AFAIK, PM does not provide an easy way to set up an automatic parsing of the entire postal address. An elaborate set of code replacements seems daunting.

I see three main issues and a few possible fixes:
  • Redundancy, as described above: This should be fixable by removing Country, State, City (and postal code) during the JSON parsing by Photo Mechanic.
  • International differences: The house number is listed in the American order (### Street name). Where I live (Germany) and in several other countries I know, the house number follows the street name. So, I should see “Willi-Brandt-Str. 25”, but PM gives “25 Willi-Brandt-Str.”.***  Maybe Nominatum includes an “international” switch in the API.  A search in OSM reveals that OSM likely contains house number in a separate field. (It’s separated by commas, whereas Photo Mechanic returns it without commas.)  For my purposes, the wrong ordering renders it useless, as the addresses will be inconsistent with other photos. I’ll have to brute force it with CRs for a few important locations.
  • Open Street Map. OSM is a wonderful example of the democracy of information of the internet age. But, that democratization also means no or only loosely applied standards. Without standards (i.e. an official name that OSM endorses), there’s no easy fix to JS’s issue. His needs and my needs may not match someone else’s. And, I should note, it’s not really PM’s problem
.
   
Here are some of the challenges with OSM:
  • Difference of Opinion: JS’s issue was about the naming of the Canal Grande. If he edits it in OSM, maybe someone will reverse the change a week later. I also note that the address returned includes “Italien” as the country, which is the German spelling. (Why? Could be intended, as German is spoken there.)
  • Multiple close location names: What do we do with multi-story buildings, where the geocoding gives me the name of the store on the ground floor, but I actually took the picture several floors up?
  • Errors: For at least 10 years, a forest within the city limits of Bonn was recorded in OSM as belonging to the town of Königswinter, which is on the other side of the Rhein! I noticed this error in OSM and multiple programs that relied on OSM for their data. (I assumed someone with an OSM account would fix it. They did eventually.)

I hope that issues 1 and 2 can be fixed.  Thanks for reading.

Cheers
Jamie


* For sake of clarity, I am only talking about the location created field in the section "event and location", not the "sublocation" in "Locations Taken and Shown".

** The IPTC standard seems to imply this. For “Location Structure” it states: “A structured datatype for details of a location. It includes a Sublocation, a City, a Province or State, a Country (Name and ISO-Code) and a World Region.” My RAW converter, Capture One, places “location” hierarchically under “city”.

*** And, there are plenty of examples, such as France, that also place the house number in front. Who knows how many different conventions there are world-wide. This really should be managed at the OSM or Nominatum level.

Offline Jamie

  • Newcomer
  • *
  • Posts: 16
    • View Profile
Re: Reverse Geocoding Service Update
« Reply #3 on: February 19, 2023, 04:12:47 AM »
Here is an additional example to show just how crazy the entries for OSM are. It is taken on a hike near the border of two states (Bundesländer) here in Germany.
The returned entry for "Latitude: 50.63926° N, Longitude: 7.19880° E" is  “Rodderberg, Vulkanstraße, Mehlem, Bad Godesberg, Rolandswerth, Remagen, Landkreis Ahrweiler, Rheinland-Pfalz, 53424, Deutschland”.

7 elements are correct, but 3 are outright wrong:
  • Mehlem and Bad Godesberg are sections of the city of Bonn, which is > 3.5 km (2 miles) away and they are in a completely different state (Northrhine-Westfalia, not Rheinland-Pfalz).
  • Rolandswerth is part of Remagen and close by (< 500 meters as a crow flies), but the Rodderberg is not inside it.

This is a perfect example of how hard it will be for PM to parse the JSON string from OSM.  How do you determine what to exclude?  Excluding everything from Remagen to Deutschland would be right, but, a local might say “Rodderberg is close enough to Rolandswerth, and the path comes from there, so…”  So, abstracting to the effectively infinite number of cases worldwide, PM or Nominatum faces real challenges here for finding what to include/exclude. 

There’s got to be a better method.

Offline ahoward

  • Camera Bits Staff
  • Hero Member
  • *****
  • Posts: 567
    • View Profile
Re: Reverse Geocoding Service Update
« Reply #4 on: February 23, 2023, 01:27:07 PM »
Hi Jamie, just wanted to say that we do really appreciate the thoughtful feedback and it will be considered as we continue to improve/update the service.