The unexpected result - Part of the “Temerin” municipality, but not of the village - Seems to have an extra “boundary:administrative” tag at rank 18 which I assume is causing the issue
I tried checking another street that’s in both cities called “Radnička”, and when searching for it with a similar query as above (expect I’ve changed the street, obviously), there was only 1 result (the correct one, in Temerin).
That street goes a tiny little bit into the city boundaries of Temerin at the eastern end of the street. That’s why Nominatim includes the street in the results.
As the more relevant result appears first, there isn’t really anything to do here. Simply take the first result and ignore additional ones.
The data is correct here and Nominatim has to err on the safe side of presenting two results. There are cases where a street really goes through two cities. Deciding if it is such a case or just a case of touching the boundary is surprisingly hard.
Actually, the Serbian community has a dedicated subforum, where such questions may receive more focused attention. We have recently practically completed import and periodic synchronization of OSM data with the open data about administrative boundaries, streets and addresses from the Republic Geodesic Agency (RGZ). Of course, there are always rough edges both in OSM and RGZ data, and edge cases such as this one.
See e.g. this thread for a running discussion on street import and mapping.
Street names and IDs are a messy subject. For every named street, RGZ assigns a numerical identifier which we keep in ref:RS:ulica tag, and that identifier is unique in every settlement. However, there are many streets which touch the settlement boundaries (like here) or, worse still, run along those boundaries. Those are particularly messy, since we sometimes have to split the street along settlement boundaries at semi-arbitrary points just to keep both ref:RS:ulica relevant. The worst offender is likely Ibarski put (better known as “Ibarska magistrala”), which has this name across ~100 towns and villages along the way.
That actually happens to be helpful for Nominatim. While it can find streets crossing multiple settlements with any of the settlement names, it will currently only present one random settlement it crosses in the result, no matter what the actual query was. That can be confusing and happens to be avoided when splitting streets.
Not that I would ever recommend to be mapping for the geocoder. ;)
Sadly the issue is that in my case the irrelevant one from “Sirig” is the first result, not from “Temerin”, I see that on the officially hosted nominatim instance it’s the other way around. On my local instance both have the same importance rating too.
But okay, I guess if it’s okay in terms of OSM, then I’ll have to find another way to deal with it.
I wouldn’t call it okay, since it’s clearly misleading – Nominatim should prioritize results according to street length (among many other things). In its defense, it has a very complex engine based on a lot of heuristic rules and a sprinkle of black magic, to cater for numerous shortcomings in the OSM data.
Yeah, we could fix this situation in the map – the street “protrudes” to a wrong administrative boundary by a meter or two, so we could split it there. But really, it would amount to hairplitting (pun intended).
Fair enough, I thought you were from [around] the country. But FYI, English is practically allowed in all corners of this forum, and it has a fairly good built-in translation engine to boot (“Globe” icon at the bottom of every foreign-language post).
So I guess could != should? Because if you look at it, there are a few more streets that also have the same “issue”. To be honest, I just noticed that the blue-white line (the adm. boundary) is there :D
I’am from the country though, but I’ll keep that in mind next time.
Alright, I moved the unnamed residential 758486343 slightly westwards, so that it practically overlaps the boundary line. Whether it will fix the Nominatim issue remains to be seen.
It’s not a “wrong place”. There’s no reason to assume that the previous layout was correct in the first place.
The administrative boundary (which is the most precisely drawn object out there, since it was imported straight from the cadastral agency GIS data) has apparently been placed somewhere along that street. The intent was likely for it to be exactly in the middle, but we can’t know for sure if perhaps it should be slightly to the left or slightly to the right. Before my change, the way was drawn 2-3 meters eastwards from its footprint at ESRI World imagery; after the change, it’s 2-3 m westwards. It’s something different still if you switch to Bing. So, all those objects were (and still are) well within the error margin of aerial imagery and an average GPS system.
But now the street overlaps the administrative boundary, which is most probably the correct result.
I’m sure there are hundreds of similar situations out there, not just in Serbia but elsewhere in the world. We don’t (and should not) bother to split them exactly at the administrative boundary they belong to, and I certainly don’t plan to go for a tweaking spree just to make Nominatim happy (it should be eventually fixed to allow for fuzzy matching at boundaries).