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.
