After the recent changes, the search function is playing up again. Things I’m looking for aren’t found, instead places and objects with only tenuous connections to the search term are shown. Try e.g. Bradford Road, Oakenshaw, West Yorkshire (a more than 2 km long street), and what you get is South Bradford Golf Course which is not even on that road. Granted that Oakenshaw is a village that sits astride a boundary of two metropolitan boroughs, but it has worked properly before.
Sorry about that but unfortunately the place and boundary data for the UK in OpenStreetMap is rather unsuitable for creating a geocodable dataset. Figuring out something like “Bradford Road” being in “Oakenshaw” is always going to be a hit and miss until the OSM UK community agrees on some kind of usable standardization.
Indeed, local boundaries are a problem in the UK, in particular as there are a lot of unparished areas, and nobody seems to be able or willing to tell where one village ends and another begins. Still, my impression was that the search involved nearby points associated with place names, which gave mostly sensible (if not always exact) results. However, this does not seem to work as well any more as it used to.
It takes into account boundaries and place nodes. And it makes the assumption that boundaries are hard borders. In this particular case the village place node of Oakenshaw happens to be within the admin boundary of Bradford while Bradford Road happens to be in Kirklees.
Nominatim could work with other kind of area types if admin boundaries as defined by the British government are useless for defining settlements. I’ve considered ceremonial boundaries at some point but they are too sparsely available to be a commonly available solution.
Nominatim might get away with a strategy of using place nodes only in the UK countryside. Sadly results become significantly worse for the big cities.
Totally naive question, and I’m sure there are reasons why it doesn’t already work this way, but could the boundaries be treated as a bit more fuzzy? I.e., check for instances of the searched item within adjacent boundaries too?
It would make processing and searching much more expensive. It would also lead to worse results for a lot of other cases: adjacent settlements tend to have the same street names in many countries, so you don’t want fuzzy there.
Thanks - makes sense.
I was thinking of this in the case where the initial match didn’t return a sensible result (such as this example). That would presumably mitigate the issues you mention but I know edge cases are always a nightmare to deal with and my suggestion would probably have other unintended side effects!