SUMMARY "county" label in advanced search refers to XMP-iptcCore:Location but the meaning of the latter is different : https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#sublocation-legacy So, instead of 'county', the field should be labeled 'location' (or 'sublocation' if you want to use the same label as IPTC Standard). (By the way, thanks for adding these location fields to the advanced search.)
In fact, I would leave it as is for now. It is based on the designations of OpenStreetMap in the reverse geolocation tool. For me, County (or in the German "Bezirk") is definitely the right term for it. We also use City for village etc. Do you think County is completely wrong for the location, regardless of the IPTC metadata? Maik
(In reply to Maik Qualmann from comment #1) > Do you think County is completely wrong for the location, regardless of the IPTC metadata ? Yes, absolutely. It is not a choice between two names for the same thing, there are two different things. OpenStreetMap defines county as "a geographical region of a country used for administrative or other purposes", so something similar to state/province. On the other side, for IPTC, location (sublocation) is the FOURTH level of a localisation (country, province/state, city, sublocation), so something as "14, River street" or "Museum of arts" or "Blue lake". You are trying to solve the fact that OpenStreetMap has two intermediate levels between country and city (province and county) when IPTC has only one (province/state) by changing the semantics of the fourth level of IPTC. I think it is not a good thing to do (IPTC should be the first driver for a photo management tool).
IPTC : location/sublocation Exact name of the sublocation shown in the image. This sublocation name could either be the name of a sublocation to a city or the name of a well known location or (natural) monument outside a city. In the sense of a sublocation to a city this element is at the fourth level of a top-down geographical hierarchy.
I'm not necessarily looking at the IPTC standard here, we need to syncronize that with the reverse geolocation and OpenStreetMap. OpenStreetMap supports: Country, State, State district, County, City, City district, Suburb, Town, Village, Hamlet, Street, House number, Place Which of these corresponds to your idea of sublocation for you? Maik
The problem is that we need to fill in IPTC with the result from OpenStreetMap. So we need to group OpenStreetMap items to IPTC. Maik
Git commit 901d528a2e1e51586321cfafedefbbc93cfb3e77 by Maik Qualmann. Committed on 14/02/2023 at 06:58. Pushed by mqualmann into branch 'master'. change i18n locations term FIXED-IN: 8.0.0 M +2 -1 NEWS M +4 -4 core/utilities/searchwindow/searchfields_createfield.cpp https://invent.kde.org/graphics/digikam/commit/901d528a2e1e51586321cfafedefbbc93cfb3e77
To be in line with its semantic, "sublocation" field should be below "city" field, in fourth position.
Git commit 8bddf1f1a12ced1423e9c51d05c2edadaa83664d by Maik Qualmann. Committed on 16/02/2023 at 11:29. Pushed by mqualmann into branch 'master'. swap location fields M +12 -12 core/utilities/searchwindow/searchfields_createfield.cpp M +1 -1 core/utilities/searchwindow/searchgroup.cpp https://invent.kde.org/graphics/digikam/commit/8bddf1f1a12ced1423e9c51d05c2edadaa83664d
@mahikeulbody, which of the OpenStreetmap fields (comment 4) would you assign to the sub-location? Maik
(In reply to Maik Qualmann from comment #9) > @mahikeulbody, which of the OpenStreetmap fields (comment 4) would you assign to the sub-location? For sure, the closest one would be "House number [concatenated with] Street". IPTC sublocation is larger than "House number [concatenated with] Street" since it could also refer to places such as "eider peak" or "restaurant xxx". But if I understand right, the need is to find a mapping gps --> sublocation, not sublocation --> gps, so it should be right.
(In reply to Maik Qualmann from comment #8) > Git commit 8bddf1f1a12ced1423e9c51d05c2edadaa83664d by Maik Qualmann. > Committed on 16/02/2023 at 11:29. > Pushed by mqualmann into branch 'master'. > > swap location fields > > M +12 -12 core/utilities/searchwindow/searchfields_createfield.cpp > M +1 -1 core/utilities/searchwindow/searchgroup.cpp > > https://invent.kde.org/graphics/digikam/commit/ > 8bddf1f1a12ced1423e9c51d05c2edadaa83664d Thanks. City and sublocation need also to be swapped into "Captions right menu"/"Information panel"/"Location" sub-panel.
In fact, now I understood better what you meant with the reverse geo-localisation stuff (I was a little bit too much focused on my sublocation wish ;-) I have a suggestion about the mapping OpenStreetMap --> IPTC fields. Country --> iptc.country State & State district & County --> iptc.state (separated by "/" for example) City & City district & Suburb &Town & Village & Hamlet (some of them are probably exclusive each others) --> iptc.city House number & Street --> sublocation Place : I don't understand the exact use of this key, that seems a meta-key ? If an item of a list is not provided by OpenStreetMap, just skip it, no "//".
Git commit 7a7677f99f0005780865222d92e16559e9922321 by Maik Qualmann. Committed on 16/02/2023 at 20:40. Pushed by mqualmann into branch 'master'. modify OpenStreetMap fields mapping to locations M +25 -20 core/utilities/geolocation/geoiface/items/gpsitemcontainer.cpp https://invent.kde.org/graphics/digikam/commit/7a7677f99f0005780865222d92e16559e9922321
(In reply to mahikeulbody from comment #12) > Place : I don't understand the exact use of this key, that seems a meta-key ? The OpenStreetMap keywords belong to the API. If you query "City" or "Street" you will get the names for the location if they exist or are known. Maik
You wrote : OpenStreetMap supports : Country, State, State district, County, City, City district, Suburb, Town, Village, Hamlet, Street, House number, Place So I thought that Place was a key like the others of the list, hence my previous question.
I just tried the last beta (2023-02-17). 1) City and sublocation could be swapped into "Captions right menu"/"Information panel"/"Location" sub-panel (it is cosmetic though). 2) Digikam concatenates City district and/or Suburb into sublocation instead of city as suggested. There is an unexpected side effect of this choice on Advanced Search function : since OpenStreetMap can eventually define a localization with more items that those you know about a place (typically suburb or city district) it is almost impossible to set a search about sublocation if the beginning of the field is not known (and there are generally thousand of items in the list of choices for this field) The concatenation City & City district & Suburb &Town & Village & Hamlet --> City as suggested is less problematic since we know generally the City much more often than the City district or Suburb. Another way to do (but probably more complicated to implement) would be to be able to set an item of a list of choices typing any subset of the item (and not only the beginning). 3) The choice of "/" as the separator introduces a may be confusing display of Captions menu/Information panel/Location "State/Province" field in case of OpenStreetMap provides both State and State district. The user can think "Province" = "State district" which is not true. Renaming this field "State or Province" would remove this ambiguity. 4) A (very) cosmetic wish : put a "," or " " between "street" and "number street.
Git commit 9f546a7ad47e13e3209f0b6f214ddf8c043e407c by Maik Qualmann. Committed on 17/02/2023 at 20:49. Pushed by mqualmann into branch 'master'. use only a single location string from OpenStreetMap M +33 -23 core/utilities/geolocation/geoiface/items/gpsitemcontainer.cpp https://invent.kde.org/graphics/digikam/commit/9f546a7ad47e13e3209f0b6f214ddf8c043e407c