I read this discussion with interest (as end user) and ignorance router-wise.
Some unsorted early-morning thoughts on this subject: 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/... 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. 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). Micromapping correctly the last meters for all the different means of transport is the correct theoretical solution. But is it practical ? Navigation aid? In Italy the house numbers are assigned to the pedestrian entrance point for the house/business/shop/airport/... Take an address in a pedestrian area within a limited-access zone in my city. 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. You can construct many more examples. Volker On Sat, 17 Jun 2023, 00:16 Minh Nguyen, <m...@nguyen.cincinnati.oh.us> wrote: > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
