[Tagging] navigational aid relation

Fri Jun 16 22:12:18 UTC 2023

Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:
> On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:
>> I neglected to mention another common heuristic: the geocoder can
>> automatically bias the address point toward the street named in addr:street
>> when coming up with a navigable point. The Mapbox Geocoding API is an
>> example of a geocoder that does this [1][2], though unfortunately neither
>> Nominatim nor Pelias has a similar feature so far.
> 
> You need to remember that routers are only one kind of client of
> Geocoders and certainly not the most important by far. While a nice
> gimmick, I certainly wouldn't consider it a main task of a geocoder to
> return a routeable point. The main task is to return the place/object you
> were searching for. In that sense, the root of the issue is that
> routers usually underspecify their search query. If the query is
> 'airport Frankfurt', then the airport is what the geocoder returns. One can't
> expect the geocoder to determine that what you actually wanted is the
> street closest to the main entrance or the parking or the main bus stop.
> 'parking near airport frankfurt' does yield results although we'd have
> to do something about priority ordering.

To be clear, all this talk about "navigable points" is about something 
that would supplement, not replace, the centroid coordinate that a 
geocoder already returns. If an end user searches for "airport 
Frankfurt", what Nominatim returns is quite sufficient for centering the 
map on the airfield. However, nowadays, the user also expects to see a 
row of buttons for navigating to a specific terminal, parking lot, or 
tram stop. This was not the case several years ago, but all you have to 
do is look at the most popular navigation applications to see why this 
topic keeps coming up.

>> Then again, none of this complexity is necessary if OSM has a publicly
>> accessible driveway or footpath leading right up to the building. A router
>> should consider that driveway or footpath to be part of the most direct
>> route.
> 
> Exactly. It would be kind of counter-productive to add all this
> functionality to a geocoder. A good router has all the right
> data structures to make an informed decision about the navigation start point
> and also the information about mode of transport etc. A geocoder's
> data structures are rather unsuitable to solve these examples.
> 
> The initial examples of Florian are quite telling in that way. The
> closest road to
> https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z
> would in fact be the service way right next to the buildings. The fault
> is with the router who does not include non-accessible roads to
> determine the access and thus finds the wrong road. If it would create a
> full routing network that includes inaccessible service roads and footways,
> it would be able to make the right decision and bring the car to the gate.

I agree that routers should consider inaccessible service roads more 
than they do now. However, this would not be a panacea. For one thing, 
if the router finds the nearest inaccessible service road to an airport 
centroid, more often than not, it will be along a vehicle service road 
(VSR) for ground support equipment, surrounded by taxiways or even runways.

Nominatim returns a centroid for the San Francisco International Airport 
that's about 80 meters from a VSR used only by airfield maintenance 
crews; this is the closest road. [1] The restricted entrance that most 
directly leads to the VSRs is almost 4 kilometers from the domestic 
terminal's front entrance. [2] (This is a real service road. Last week, 
from my armchair in Economy, I watched a maintenance vehicle wait at a 
stop sign on the VSR as my plane passed by.)

In more mundane cases, footways could definitely help a router send a 
ride-sharing driver directly to a drop-off point (albeit at the expense 
of a driver or cyclist needing to park their vehicle). This 
functionality is often lumped together with the idea of multimodal 
routing, but unlike true multimodal routing, it doesn't require looking 
up route schedules and timing transfers.

> I'm not sure if there is any router around which does something even marginally
> more clever than determining the closest road to the centroid. This even goes
> as far as this:
> https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889
> (starting point given as: "47, Rue du Rouet, Marseille")

Routers can only be more clever if they have more context. You gave an 
address to Nominatim, but all you ultimately gave to GraphHopper was a 
coordinate pair. For all GraphHopper knows, you need a route that begins 
on the Tunnel du Prado Carénage because you're already walking down that 
tunnel. (highway=trunk doesn't imply anything about foot=*.)

OSRM and Valhalla allow you to pass in a "bearing" that filters out 
candidate routes based on the initial direction. This would be useful if 
a driver or cyclist is in motion, heading down Rue du Rouet rather than 
the tunnel, but it's counterproductive for pedestrians, who can turn on 
a dime.

Mapbox's navigation SDK automatically map-matches the user's recent path 
to the road network to determine this bearing even if the user is at 
rest. Essentially, it remembers that you've been on Rue du Rouet all 
this time and figures out that you couldn't have jumped into the tunnel 
all of a sudden.

(The three routers featured on osm.org have many capabilities that the 
site hides or even undoes, but at the same time it misleads users into 
thinking they're already integrated with a geocoder.)

> So there is a lot of room for improvement in the routers by just using
> the information already available. Another example: the heuristic you mention
> above, that the geocoder should bias the start point towards the street named
> in address street, this is something that could be just as easily implemented
> by routers when determining the start point. Street names are usually
> available to them.

For better or worse, most geocoders do provide the navigable points that 
allow applications to display "sub-destination" buttons for large 
destinations. For smaller destinations, the application can automaically 
pick the correct street thanks to address matching.

Whether this functionality should properly be part of a geocoder or a 
router is probably uninteresting to downstream application developers. 
They already complain that routing APIs like GraphHopper, OSRM, and 
Valhalla don't have a geocoder built right in like the Google Routes API 
does.

But to your point, if OSRM were to take an address as input (before 
forward-geocoding it), or if it were to reverse geocode the coordinate 
internally, it would have enough context to snap the waypoint to the 
road network much more intelligently. They just aren't integrated that 
well so far.

> That said, I do think it would be a good idea if Nominatim could return
> entrances for larger buildings or areas. That's why
> https://github.com/osm-search/Nominatim/issues/536 is still open.
> I would just draw the line where the geocoder needs to make any policy
> decisions like deciding which is the best entrance point, as this
> largely depends on the client's requirements. (It pretty much rules out
> the Mapbox approach which is biased towards vehicle routing.)
>  > Maybe a separate service that computes navigation points for an OSM
> object wouldn't be such a bad idea. It might be easier to play around
> with heuristics based on micro-mapping using a separate software instead
> of trying to cram it into exising routers or geocoders which are optimised
> for other use cases.

I agree that a separate service would be a good place to prototype 
heuristics, but I think it can only nibble around the edges of this 
problem. Long-term, there should be tighter integration with either a 
geocoder or a router.

My apologies to everyone who was expecting a tagging discussion rather 
than a deep-dive into router engineering. But I think it's helpful to 
understand what data consumers are capable of -- or could reasonably 
become capable of -- before resorting to adding subjective hints in the 
database en masse. There may well be tough cases that require an 
override, reminiscent of the manoeuvre relation type [3], but it 
shouldn't be seen as a general-purpose solution.

[1] https://www.openstreetmap.org/way/1182574218
[2] 
<https://www.openstreetmap.org/directions?engine=fossgis_valhalla_car&route=37.6052%252C-122.3781%253B37.6170%252C-122.3841>
[3] https://wiki.openstreetmap.org/wiki/Relation:manoeuvre

-- 
minh at nguyen.cincinnati.oh.us