Hi there,
I just tried looking from the other perspective: Why is it so difficult
to extract proper routes from the osm data and what has already been tried.
I just looked over the the issues and some first-sight information on
github and have seen that we're facing two different problems here:
The first thing is to find the proper coordinates of the routing
destination (job of Nominatim:
https://github.com/osm-search/Nominatim/issues/536 Open issue since
2016 - the statement by lonvia that nominatim didn't take any entrance
information into account seems to be outdated).
The other thing is to find the appropriate route once you have found the
proper coordinates, which can be complicated if access rules block the
most suitable way.
The solution of the second problem could be via the first point: just
only try routing to a suitable public access point to the destination -
then you can give coordinates where you can do a routing to.
For the first problem it is quite already solved as nominatim returns
the coordinates of a simple node with entrance=yes and an addr:
information.
You only would have to change the wiki page Key:entrance and encourage
people to allow single nodes with the tag entrance=yes and addr:xyz
(like this: https://www.openstreetmap.org/node/10979019687) if it is not
obvious where the entrance to the property is. (What happened before for
the whole row of houses you still can see if you plan a route to "Am
Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
any entrance nor the house due to a high hedge, and you sometimes see
people walking down the Voltmannstraße looking for entrances...
Difficult, because you would have to turn in "Am Rottmannshof" to get to
"Am Rehwinkel" ;-) )
Maybe an easy solution would be just to use the access-tags here
possibly introduce some additional tags for "entrance". In some
situations this would be a wider sense of "entrance" (in this examples
at any place there is a gate, but it works even without the mapping of a
gate and is still correct in the narrow sense). But even without an
distinct entrance it could be some kind of an entrance if you have to
leave your vehicle and enter an area of another transport mode like
walking.
Greetings,
Sebastian
Am 15.06.23 um 09:34 schrieb Minh Nguyen:
Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết:
Management Summary:
In navigation/routing the point the router is routing to is the
nearest
point on the routable network from the poi/address we like to navigate
to. The nearest point may not be a location where the address/poi
can be
reached from.
I suggest a navigational aid relation hinting the link between
geocoding and router to use a different point on the routable network.
I agree that there is a need for geocoders to produce more
routing-friendly locations than the centroid. Navigable points are
nothing new in the field of location services. Most geocoders already
do this, including some that are often used with OSM-based maps,
although none are open source as far as I can tell.
I've written something of a white paper on the subject of navigable
points. [1] The short story is that most scenarios would be well
served by micromapping in OSM combined with some clever heuristics in
the geocoder, without the need for a new relation type. I've provided
some example OverpassQL queries to prove the concept, but in reality a
serious data consumer would perform spatial queries or traverse the
relation hierarchy more directly, without the help of a separate API.
With this heuristics-based approach, we can take advantage of the
large and growing body of data that's implicitly optimized for
routing. Mappers generally wouldn't have to familiarize themselves
with routing engines; they can just map what they observe, but in
greater detail.
When none of the heuristics applies, the last resort can be a site
relation, using each relation member's role to clarify why the
application might want to present the member as an option. I've used
site relations in a few cases where a spatial query won't turn up any
useful results.
For example, a nearby American football stadium [2] has multiple
parking lots, but all of them are off-site, on the grounds of an
amusement park, a college, and some office parks. A driver would only
be interested in the parking lot that corresponds to the ticket they
purchased. The parking lots are members of a site relation with the
stadium. [3] We have no hope of precisely modeling ticket classes in
OSM, but the application can simply list the lots by name and let the
user choose manually.
Unfortunately, I'm unaware of any OSM-based data consumer that
implements these heuristics, but routers aren't the only reason to map
building entrances or site relations.
[1]
https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen/Navigating_between_entrances
[2] https://www.openstreetmap.org/way/296503400
[3] https://www.openstreetmap.org/relation/14507813
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
