Nominatim
Nominatim copied to clipboard
display connected ways with same name and type as one result
As example: When I search the Street xyz, which is stored in OSM as several, together connected way's, nomatim give me one result per way.
It would be nicer, if nominatim connect this ways internal to an group, and display it as big group, and not as individual results.
My idea is, that together connected ways with the same name, and type (as example highway=residential) are grouped. tags like bridge=yes, tunnel=yes,parking-lanes, lanes=*,... are ignored because that tags represent only a part of the same street.
thx, pointhi
I understand that for a very long road, this would have its own issues, but I have just had this problem looking for a Main Road in the borough of Bromley (in Greater London). https://nominatim.openstreetmap.org/search.php?q=Main+Road%2C+Bromley gives you 15 results for one long Main Road (all in/around TN16 outer postcode), and then the road I was looking for (in BR5) is results 16-19.
If I may: One solution to improve existing situation in some regions knowing that it would not be enough to handle all cases would be to extand https://github.com/osm-search/Nominatim/issues/463#issuecomment-920369049 mechanism to index Relation:associatedStreet relations and hide its members. Where those relations exists it would do the job. But it would not help to group by ref or other criteria since its not there purpose. This would also means that bounding box for results would encompass addresses, which might be usefull (or not...).
Otherwise the solution I can see would be to add a cluttering/grouping process either at indexing time or at search time:
- At indexing time such mechanism might have to group N items into X because search criteria are not known at this point. For instance, there might be 5 ways with a same
refbut 2 differentnames (because it spans on 2 cities). At indexing time I guess at least 3 items would have to be kept (one for group by name in city A, one for group by name in city B and one for group by ref). There might be also the opposite case: 5 ways with a samenamebut 2 differentrefs; - At search time only one item (based on search words) would have to be kept. A configuration file/db would define some cluttering rules such as (In results if more than one ways have same name and same class and are connected then group them). This would be set for highways, waterways and probably other type of linear objects (railways? bus route?...).
I think approach 2 would be the most flexible and the less bug prone but at the cost of an additional processing time/ressource.