On lau 15.júl 2017 11:13, marc marc wrote: > > Your demonstration is only that a wrong map create sometimes a wrong > routing :-) > What will your reaction be when Mapzen tell you to cross a road where it > is impossible ? However this is exactly the current map for [2] > You would not agree that the routing would make you drive from one road > to another because they are close and it save 1km. Therefore I do not > understand why you would want the routing to do this when you are walking. > If the map is wrong, first fix the map, not the routing engine. My example was rather the inconsistency in the assumptions the routers are making based on the current data. I do think that the routers should be programmed to evaluate when it's safe to suggest to the user to cross the street without a specifically mapped crossing. Due to the potential legal and logistics issues, I do assume the routers would need more map data than is currently provided. The data isn't innocent. Some routers assume living streets have that property but one (currently) can't tell the router it may assume the same regarding a specific segment of another highway type. Is a part of the solution to implement such a tag? I don't know. > >> but GraphHopper directs the user to take a complicated path > Complicated because the map is wrong in this case. > GraphHopper will not make you cross a road where a mapper tell > (unintentionally but erroneously) it is impossible. > Is it bad? IMHO no, it is the best reply. > I think that is the problem. You would like the routing to guess errors > and guess where we can jump from one path to the other in the absence of > connection. > But the simplest/efficient/only solution is to fix the map. To continue from my point before. GraphHopper is ready to determine the user has reached the destination when on the street itself, therefore assuming no barriers from that location to the destination, but is not ready to (properly) take into account the same situation from the starting point to the street itself. If the routing engine had done that from the beginning, it would've suggested the user to cross the street instead of the much longer route. In another case I tested, Mapzen suggested that I would start on a footway on the other side of the house across the street, therefore starting my journey on foot by jumping over a house. There is a street between the houses, which could lead to the destination albeit by a little longer route, so it wasn't absolutely forced in its decision. When it comes to start and end positions compared to the calculated path between them, there is a big routing bias favouring the former.
I think it's unavoidable for routers to guess mapping errors, although we should always aim to limit the type of guesses they need to make, especially when it comes to the aforementioned jumps. If the routing software is mainly written to work efficiently in areas with perfect mapping data, they start to become much worse where the data is incomplete/incorrect. The aim is, of course, to have perfect mapping data, but it's not realistic to expect that to apply everywhere at any time. There has been some effort to detect where mapping data has the potential to cause problems in routing calculations, and I'm all for that. Then there are situations where the cause is based on our own limits, like the availability of officially accepted tags to deal with certain situations. There are official accepted tags to indicate tha location of a barrier but none (that I know of) to indicate the absence of them. The router doesn't *really know* there are no barriers in the space between; for all it knows, the footway and the street could be separated by a local black hole. In the GraphHopper case, it's more afraid of local black holes when it leaves no. 73 than when it suggests stopping on the street in front of no. 42. So, how can we help the routers deal with this? Deleting the footways is not a realistic action in this case, IMHO. >> 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? >> I'm not objecting to such a method, I've just been hesitant to apply it >> without approval by documentation or the community. > Guidelines for roads is very easy: split a road in 2 when you can NOT > switch from one to the other (for example a road with a island). and > create connection where you can switch. But do NOT cut a road into 2 if > you switch everywhere from one to the other (for example a street with 2 > lanes must be keep as one street, not 2). > Just do the same with the sidewalk as if the sidewalk was a lane > reserved for pedestrians. I never see a problem with that. The data is already there. I'd see myself as a vandal if I were to start deleting footways en masse, for that purpose. There might also be valid future cases where it becomes necessary to keep them separete, which would then urge the community to draw/import them again, wasting its time. So I'm rather looking for solutions which would not entail deletion of data in that manner. With regards, Svavar Kjarrval _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
