The use of information board 'names' in the reverse search.

[m-hew]

Hello,

I use the Nominatim reverse search to tag photos I took based on the recorded GPS coordinates. Today I noticed some weird location called "Pest, entweiche!". English "Plague, begone!".
The cause is a so called information board next to the position.
https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=10782634850&class=information

IMO the name of information boards should not be returned at all, not even at address rank 30. I use that rank because it works fine with other POIs where the name is actually the name of the POI. E.g. a reverse search for coordinates near the Lutherbuche https://www.openstreetmap.org/node/4157724006 correctly tell me that I'm near that named tree.
But in the case of information boards the board name is often not the name of a place, just some information with more or less connection to that place. There are e.g. tons of boards with information about local fauna and flora in the woods, but they are often not specific for that kind of area. Then there are also boards with names pf people, geology, times in history etc.
And even if the board name is a place nearby, the place itself is also nearby and should be picked instead.

(I'm not sure if the same applies for guideposts. Lots of people put a prominent title of a guidepost as their name, but that could even be a hiking trail kilometers long and not indicative of the actual place.)

PS: The use of the name of a board would make sense if the name tag would be properly used, but that is not the case with information boards.

[mtmail]

For reference

https://www.openstreetmap.org/node/10782634850

board_type=nature
information=board
name=Pest, entweiche!
tourism=information

https://github.com/osm-search/Nominatim/blob/master/lib-lua/themes/nominatim/presets.lua
currently contains

    information = {include_when_tag_present('tourism', 'information'),
                   yes = 'delete',
                   route_marker = 'never',
                   trail_blaze = 'never'},
[...]
    tourism = {'always',
               attraction = 'fallback',
               no = group,
               yes = group,
               information = exclude_when_key_present('information')},

[lonvia]

See #2837.

[m-hew]

I have seen that issue, but since it is about /search and not /reverse I decided to open a new one.

Information boards are a tricky subject. They typically do not have a name in the intended meaning, but people added the titles into 'name' for years. 'board:title' is a newer tag and usage grows rapidly, but e.g. the people involved in the iD editor ignore the correct tag and keep 'name' as a default field, so mappers will keep adding board titles to 'name'.

Regarding this issue: I would not want the name, i.e. title, of a nearby board to be part of the address from /reverse. There are many boards that have man unspecific information that do not add precision to the overall address. E.g. board with information about bees, climate change, historic times etc.

And regarding the search: I haven't used the search through the API yet. Maybe if you could explicitly ask the API to search board titles, then Nominatim needs to consider 'name' and 'board:title'. If not searching for information boards it should just return the mentioned promenade, not a board with the info about it: https://www.openstreetmap.org/way/66102215#map=17/46.852428/17.876011&layers=N

[lonvia]

Try layer=address,natural, it might be closer to what you need for your photo tagging. Other than that, it really depends on individual requirements what counts as a POI and what doesn't. I'm fairly sure that there are a lot of people who would violently disagree with you that natural=tree are appearing in the reverse search results. (In fact, it doesn't appear by default as it is a natural feature. It's the viewpoint next to it that is reverse geocoded which is again a POI.) So for the general geocoder at nominatim.openstreetmap.org there is little we can do here. You can always set up your own instance and tweak the imported feature as you require them.

[m-hew]

address,natural definitely makes no sense for photo tagging. Obviously POIs are often the subjects of the photos. I tried that setting with the coordinates of the most famous statue in my town and then a tea shop is the result of the reverse geocode.

I never said that every natural=tree should appear in the reverse search. I mentioned that it is a named tree. That named tree is a POI in itself. It is actually the POI that is the cause, why the other POIs next to it exist. Without it there would be no information board, no hiking stamp, and maybe no view point, at least not named.
And it does appear by default. If I search at that location, the named tree is used to as the most detailed information and its name is used, not the name of the viewpoint. Which makes sense.
https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=4157724006&class=natural

My own instance would be overkill. The official API worked fine in most cases of 10000 of photos. It's probably easier to adjust my request and code that parses the result.

But I have a deeper understanding of Nominatim now. I thought the reverse geocode is a "Give me the best description of this coordinate", but instead it is "give me the closest OSM object". This is not always identical. And information boards have a big influence here.
E.g. if I move a few meters from the Lutherbuche tree it snaps to the information board with no name. Now the reverse geocode gives me the name of the trail as the "best" information, even though the POI tree and POI viewpoint close by are named and would describe the position better.

IMO the results would be better if information boards would be ranked lower than other POIs. I.e. unless I want to look for information boards they would be skipped. In this case the location would snap back to either the tree or the viewpoint and I would have the name "Lutherbuche" in the result.