You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Author: RobJN [Added to the original trac issue at 7.26pm, Tuesday, 6th October 2015]
This would be good, unfortunately the request seems to have been inactive for a few years. Is there any objection or is it just a case of lack of time/not major enough?
My type=site example is Hadrian's Wall : [https://www.openstreetmap.org/relation/5538074]
Author: lonvia [Added to the original trac issue at 7.46pm, Tuesday, 6th October 2015]
It's not very high on the priority list, so lack of time is surely an issue and this needs some careful research first about how these relation types are used. In particular, public transport routes might skew the search results (lots of refs to search for). type=site is probably safer but it still needs to be tested out.
Author: vibrog [Added to the original trac issue at 10.36am, Friday, 22nd April 2016]
There's a lot of names in the OSM database that are not presented in nominatim search results.
Considering that OpenStreetMap data validators encourages contributors to put tags on multipolygon relations rather than its members, it will make a lot of sense that nominatim must present relation names in search results.
I have contributed a lot of relation routes and hiking route networks that simply will not be found using nominatim searches. In several cases I have to put names on ways or nodes to trick nominatim to find these names.
Reporter: yvecai
[Submitted to the original trac issue database at 1.04pm, Thursday, 7th March 2013]
It would make sense to have some results on name search for relations type=route and type=site.
For example this one: http://www.openstreetmap.org/browse/relation/1439729
or this one: http://www.openstreetmap.org/browse/relation/27005
Giving a centroid lon-lat should be enough, I guess.
The text was updated successfully, but these errors were encountered: