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
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
