<div dir="auto">I read this discussion with interest (as end user) and ignorance router-wise.<div dir="auto"><br></div><div dir="auto">Some unsorted early-morning thoughts on this subject:<br><div dir="auto"><br></div><div dir="auto">When trying to reach a destination that is defined by a complete address (city, street name, house number or name) is that the last meters of the route are, potentially,  much different for a ciclist/pedestrian/car-driver/delivery-van/ambulance/...</div><div dir="auto">One of the many problems is that we would need for any given address a navigation aid for each of the potential means of transport.</div><div dir="auto"><br></div><div dir="auto">I have come across one aspect of this when I noticed that Amazon Logistics staff systematically changed access tags on driveways around here from "private" to "yes" (or similar). </div><div dir="auto"><br></div><div dir="auto">Micromapping correctly the last meters for all the different means of transport is the correct theoretical solution. But is it practical ?</div><div dir="auto"><br></div><div dir="auto">Navigation aid?</div><div dir="auto">In Italy the house numbers are assigned to the pedestrian entrance point for the house/business/shop/airport/...</div><div dir="auto">Take an address in a pedestrian area within a limited-access zone in my city.</div><div dir="auto">Take car access. During the night the car access for drop-down is somewhere in walking distance outside the pedestrian area, but within the limited-traffic zone (which is not active at night). During the day it is most likely a park-and-ride location outside the city centre.</div><div dir="auto"><br></div><div dir="auto">You can construct many more examples.</div><div dir="auto"><br></div><div dir="auto">Volker</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 17 Jun 2023, 00:16 Minh Nguyen, <<a href="mailto:minh@nguyen.cincinnati.oh.us">minh@nguyen.cincinnati.oh.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:<br>
> On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:<br>
>> I neglected to mention another common heuristic: the geocoder can<br>
>> automatically bias the address point toward the street named in addr:street<br>
>> when coming up with a navigable point. The Mapbox Geocoding API is an<br>
>> example of a geocoder that does this [1][2], though unfortunately neither<br>
>> Nominatim nor Pelias has a similar feature so far.<br>
> <br>
> You need to remember that routers are only one kind of client of<br>
> Geocoders and certainly not the most important by far. While a nice<br>
> gimmick, I certainly wouldn't consider it a main task of a geocoder to<br>
> return a routeable point. The main task is to return the place/object you<br>
> were searching for. In that sense, the root of the issue is that<br>
> routers usually underspecify their search query. If the query is<br>
> 'airport Frankfurt', then the airport is what the geocoder returns. One can't<br>
> expect the geocoder to determine that what you actually wanted is the<br>
> street closest to the main entrance or the parking or the main bus stop.<br>
> 'parking near airport frankfurt' does yield results although we'd have<br>
> to do something about priority ordering.<br>
<br>
To be clear, all this talk about "navigable points" is about something <br>
that would supplement, not replace, the centroid coordinate that a <br>
geocoder already returns. If an end user searches for "airport <br>
Frankfurt", what Nominatim returns is quite sufficient for centering the <br>
map on the airfield. However, nowadays, the user also expects to see a <br>
row of buttons for navigating to a specific terminal, parking lot, or <br>
tram stop. This was not the case several years ago, but all you have to <br>
do is look at the most popular navigation applications to see why this <br>
topic keeps coming up.<br>
<br>
>> Then again, none of this complexity is necessary if OSM has a publicly<br>
>> accessible driveway or footpath leading right up to the building. A router<br>
>> should consider that driveway or footpath to be part of the most direct<br>
>> route.<br>
> <br>
> Exactly. It would be kind of counter-productive to add all this<br>
> functionality to a geocoder. A good router has all the right<br>
> data structures to make an informed decision about the navigation start point<br>
> and also the information about mode of transport etc. A geocoder's<br>
> data structures are rather unsuitable to solve these examples.<br>
> <br>
> The initial examples of Florian are quite telling in that way. The<br>
> closest road to<br>
> <a href="https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z" rel="noreferrer noreferrer" target="_blank">https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z</a><br>
> would in fact be the service way right next to the buildings. The fault<br>
> is with the router who does not include non-accessible roads to<br>
> determine the access and thus finds the wrong road. If it would create a<br>
> full routing network that includes inaccessible service roads and footways,<br>
> it would be able to make the right decision and bring the car to the gate.<br>
<br>
I agree that routers should consider inaccessible service roads more <br>
than they do now. However, this would not be a panacea. For one thing, <br>
if the router finds the nearest inaccessible service road to an airport <br>
centroid, more often than not, it will be along a vehicle service road <br>
(VSR) for ground support equipment, surrounded by taxiways or even runways.<br>
<br>
Nominatim returns a centroid for the San Francisco International Airport <br>
that's about 80 meters from a VSR used only by airfield maintenance <br>
crews; this is the closest road. [1] The restricted entrance that most <br>
directly leads to the VSRs is almost 4 kilometers from the domestic <br>
terminal's front entrance. [2] (This is a real service road. Last week, <br>
from my armchair in Economy, I watched a maintenance vehicle wait at a <br>
stop sign on the VSR as my plane passed by.)<br>
<br>
In more mundane cases, footways could definitely help a router send a <br>
ride-sharing driver directly to a drop-off point (albeit at the expense <br>
of a driver or cyclist needing to park their vehicle). This <br>
functionality is often lumped together with the idea of multimodal <br>
routing, but unlike true multimodal routing, it doesn't require looking <br>
up route schedules and timing transfers.<br>
<br>
> I'm not sure if there is any router around which does something even marginally<br>
> more clever than determining the closest road to the centroid. This even goes<br>
> as far as this:<br>
> <a href="https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889" rel="noreferrer noreferrer" target="_blank">https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889</a><br>
> (starting point given as: "47, Rue du Rouet, Marseille")<br>
<br>
Routers can only be more clever if they have more context. You gave an <br>
address to Nominatim, but all you ultimately gave to GraphHopper was a <br>
coordinate pair. For all GraphHopper knows, you need a route that begins <br>
on the Tunnel du Prado Carénage because you're already walking down that <br>
tunnel. (highway=trunk doesn't imply anything about foot=*.)<br>
<br>
OSRM and Valhalla allow you to pass in a "bearing" that filters out <br>
candidate routes based on the initial direction. This would be useful if <br>
a driver or cyclist is in motion, heading down Rue du Rouet rather than <br>
the tunnel, but it's counterproductive for pedestrians, who can turn on <br>
a dime.<br>
<br>
Mapbox's navigation SDK automatically map-matches the user's recent path <br>
to the road network to determine this bearing even if the user is at <br>
rest. Essentially, it remembers that you've been on Rue du Rouet all <br>
this time and figures out that you couldn't have jumped into the tunnel <br>
all of a sudden.<br>
<br>
(The three routers featured on <a href="http://osm.org" rel="noreferrer noreferrer" target="_blank">osm.org</a> have many capabilities that the <br>
site hides or even undoes, but at the same time it misleads users into <br>
thinking they're already integrated with a geocoder.)<br>
<br>
> So there is a lot of room for improvement in the routers by just using<br>
> the information already available. Another example: the heuristic you mention<br>
> above, that the geocoder should bias the start point towards the street named<br>
> in address street, this is something that could be just as easily implemented<br>
> by routers when determining the start point. Street names are usually<br>
> available to them.<br>
<br>
For better or worse, most geocoders do provide the navigable points that <br>
allow applications to display "sub-destination" buttons for large <br>
destinations. For smaller destinations, the application can automaically <br>
pick the correct street thanks to address matching.<br>
<br>
Whether this functionality should properly be part of a geocoder or a <br>
router is probably uninteresting to downstream application developers. <br>
They already complain that routing APIs like GraphHopper, OSRM, and <br>
Valhalla don't have a geocoder built right in like the Google Routes API <br>
does.<br>
<br>
But to your point, if OSRM were to take an address as input (before <br>
forward-geocoding it), or if it were to reverse geocode the coordinate <br>
internally, it would have enough context to snap the waypoint to the <br>
road network much more intelligently. They just aren't integrated that <br>
well so far.<br>
<br>
> That said, I do think it would be a good idea if Nominatim could return<br>
> entrances for larger buildings or areas. That's why<br>
> <a href="https://github.com/osm-search/Nominatim/issues/536" rel="noreferrer noreferrer" target="_blank">https://github.com/osm-search/Nominatim/issues/536</a> is still open.<br>
> I would just draw the line where the geocoder needs to make any policy<br>
> decisions like deciding which is the best entrance point, as this<br>
> largely depends on the client's requirements. (It pretty much rules out<br>
> the Mapbox approach which is biased towards vehicle routing.)<br>
>  > Maybe a separate service that computes navigation points for an OSM<br>
> object wouldn't be such a bad idea. It might be easier to play around<br>
> with heuristics based on micro-mapping using a separate software instead<br>
> of trying to cram it into exising routers or geocoders which are optimised<br>
> for other use cases.<br>
<br>
I agree that a separate service would be a good place to prototype <br>
heuristics, but I think it can only nibble around the edges of this <br>
problem. Long-term, there should be tighter integration with either a <br>
geocoder or a router.<br>
<br>
My apologies to everyone who was expecting a tagging discussion rather <br>
than a deep-dive into router engineering. But I think it's helpful to <br>
understand what data consumers are capable of -- or could reasonably <br>
become capable of -- before resorting to adding subjective hints in the <br>
database en masse. There may well be tough cases that require an <br>
override, reminiscent of the manoeuvre relation type [3], but it <br>
shouldn't be seen as a general-purpose solution.<br>
<br>
[1] <a href="https://www.openstreetmap.org/way/1182574218" rel="noreferrer noreferrer" target="_blank">https://www.openstreetmap.org/way/1182574218</a><br>
[2] <br>
<<a href="https://www.openstreetmap.org/directions?engine=fossgis_valhalla_car&route=37.6052%252C-122.3781%253B37.6170%252C-122.3841" rel="noreferrer noreferrer" target="_blank">https://www.openstreetmap.org/directions?engine=fossgis_valhalla_car&route=37.6052%252C-122.3781%253B37.6170%252C-122.3841</a>><br>
[3] <a href="https://wiki.openstreetmap.org/wiki/Relation:manoeuvre" rel="noreferrer noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Relation:manoeuvre</a><br>
<br>
-- <br>
<a href="mailto:minh@nguyen.cincinnati.oh.us" target="_blank" rel="noreferrer">minh@nguyen.cincinnati.oh.us</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank" rel="noreferrer">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>