On fös 14.júl 2017 11:08, marc marc wrote: > Le 14. 07. 17 à 12:20, Svavar Kjarrval a écrit : >> A street with a sidewalk on either side but no marked crossings: >> http://www.openstreetmap.org/#map=17/64.08800/-21.89846 >> (Sidenote: If one tries to route from no. 73 to 42, >> GraphHopper suggests a long route while Mapzen assumes the user is >> already on the other side of the street) > It is a fault (and in my opinion a mistake) to tag a sidewalk separated > from the road where it is not! > there is only one point that the maper create to connect the sidewalk > and the road https://www.openstreetmap.org/node/2673312760 > of course routing can only use this point, luckily ! > > A sidewalk really isolated from the road (= by a barrier) does not allow > crossing outside a crossing. This is the current situation of your example. > This is not specific to the sidewalk, the same happens with roads: > If you cut a road with 2 lanes into 2 road without any link between > them, routing will not allow you to jump from one lane to the other. The routing engine seems to have made the mistake of latching too much onto the footway and ignoring the road as a possible point of travel. I've noticed the behaviour in some routing engines using OSM data that when it finds a footway close by which has a possible route to the destination, it tends to ignore the nearby roads completely or place too little value on them. Some routing algorithms mistakenly ignore a seemingly expensive first link even though it might lead to a much cheaper overall path. My previous routing example [1] seems to demonstrate that.
I do acknowledge those limits on routing engines, although it's mostly in the assumptions the programmers are prepared to make. This point is demonstrated in my quoted example [2]. Mapzen assumes the user can jump over the road (or assume the user is already there) and walk a few steps, but GraphHopper directs the user to take a complicated path via the footway in front of the house (totalling 1.1 km), only to end the directions by suggesting to the user to walk on the street itself to the front of the house with the starting pin. Mapzen seems to be prepared to assume that there are no barriers between the starting pin and the footway on the other side of the street, but GraphHopper does not do that initially but is, later on, prepared to assume that there are no barriers from the street itself and to the destination point. Routing engines aren't perfect and it's a major balancing act when it comes to performance and cost of operations. That's why I'm interested in knowing if there's something we can do, data-wise, to help the routing engines perform such tasks quickly and cheaply, with the end result being directions which would make sense to the user. At least while avoiding tagging purely for the sake of the router. > >> where the footway ends >> prematurely, the routing software doesn't know it may suggest such a >> "jump" onto the street or not, > the end of the footway must be connected to the street if you are > able/allowed to switch to the street by foot. > If needed, cut the road : one segment with sidewalk=left/righ, second > segment with sidewalk=no Just to be clear: Is it valid, in your opinion, to connect the end of a footway along a street, directly to the street itself? That is, to continue the footway but make a direct connection from the end of the footway directly to the street. I'm not objecting to such a method, I've just been hesitant to apply it without approval by documentation or the community. > >> I haven't been able to find any tag or method to do it > a road with not-separed sidewalk should be taged as such :-) Is there documentation or guides on how to apply that in different situations and how to solve some of the gray areas? > >> the "common sense approach" would expect. > routing doesn't know "common sense approach" :) > if 2 sidewalk or roads are taged as "separated without any link", > routing can't guess that a connection exists. Yep, we're not that far yet. :P But until it does, it might not hurt to help it along by aiding it make such decisions. While I do understand that need, I don't want to apply and advocate measures which might damage the data quality needlessly. [1] https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=64.14793%2C-21.96048%3B64.14875%2C-21.96216#map=18/64.14809/-21.96170 [2] A link with navigation routing: http://www.openstreetmap.org/directions?engine=mapzen_foot&route=64.08769%2C-21.90140%3B64.08802%2C-21.90113#map=19/64.08791/-21.90122 With regards, Svavar Kjarrval _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
