-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow routing cars in pedestrian streets #2940
base: master
Are you sure you want to change the base?
Conversation
Allow routing cars in pedestrian streets
This reverts commit 373b233.
A way with highway=pedestrian that is by default accessible should be avoided as this is often not properly tagged and I would only allow cars on pedestrian roads if it is explicitly tagged. (Furthermore the access "customers-only" should not be allowed by default for car.) @michaelkrog Can you have a look if this branch fixes the problems you saw in #2888? |
@karussell Yeah. It seems to give me the same results as I had with my PR (but this is obviously improved only allow those explicit tagged) Issue that remains as stated above is that routing through pedestrian streets in city centers that is tagged correctly (fx. motor_vehicle=destination; motor_vehicle:conditional=no @ (11:00-04:00)) may be routed via shortcuts in the pedestrian streets instead of around the pedestrian streets. Example of wrongful short cut route across city center using the changes in issue_2888 branchExample of correct route across city center using production versionExample of correct routing into pedestrian streets using the changes in issue_2888 branchExample of wrongful routing into pedestrian streets using production version |
@michaelkrog not sure if I can follow. So in the branch created by @karussell, the accessibility of the ways is evaluated correctly, but the routing incorrectly favors them instead of the faster detour? Maybe the average speed estimation is a bit off? 5ae8297 only touches the access bits but doesn't introduce a default speed value. The fallback of 10km/h might be too high? Should we treat it like a |
@otbutz Yes and no. As I understand it, graphhopper does not support motor_vehicle=destination for car. In the shown examples, the pedestrian streets are tagged with motor_vehicle=destination; maxspeed=15, and the branch by @karussell still uses the pedestrian streets to cross the city center. The optimal would be to only route using the pedestrian streets when the destination is in a pedestrian street. Changing the default speed for pedestrian streets (as you mention) may help it to use normal highways when destination is not in the pedestrian streets. I did that in my own PR(this PR), but the result is the same. But maybe that is because the pedestrians streets in this example are tagged with maxspeed=15 and then overrides the default walking speed? BTW: In the example images above I referred to this PR in the last example by mistake. I have corrected it now. The examples are only between the branch created by @karussell and production |
An explicitly tagged value would override the default. But I'd still aim for a rather pessimistic assumption if no max_speed tag is present, just to be sure.
We take the road access into account as far as I'm aware: graphhopper/core/src/main/java/com/graphhopper/routing/weighting/FastestWeighting.java Lines 90 to 97 in 6905ff4
Could you check if the parser yields |
We do avoid motor_vehicle=destination in production via a custom model with |
This PR fixes #2888 by adding support for importing pedestrian streets in the car profile - allowing routing cars in pedestrian streets that is tagged with vehicles allowed in pedestrian streets.
Because #733 and #374 are open issues, routes through pedestrian streets might occur when not legal. When they are fixed this should work fine.
Adding specific/correct legal_default_speeds for pedestrian streets will ensure that routing will most often be routed using other ways.