Following Murphy's Law, I spotted what appears to a case of bad routing with OTP while we we giving a product demo.
I'm interested in a second set of eyes to see if you possibly reproduce it.
What happened is that a trip plan "mode=CAR" was routed through a bike-only facility where cars are not al. Here's the location, but we've since updated OSM to specify "motor_vehicle=no" there to be even more explicit. Here's the way: it's a bike/walk path connecting two streets:
I believe the root cause may trace back an issue with this patch:
That in turn was a fix for this problem:
OSM Tag Combination "highway=living_street" and "bicycle=designated" prevent Drive routing.
#2374
To recap:
1. There was originally a problem was mode=CAR being routed on ways where "highway=living_street" and "bicycle=designated"
2. The fix was to allow mode=CAR to be routed where ""highway=living_street" and "bicycle=designated"
3. What we observed this week is now kind an inverse problem-- we are seeing mode=CAR routed on ways where "highway=cycleway" and "bicycle=desginated".
I observed this with 1.x, but I found the parallel file for routing rules in 2.x and it appears to have the same structure.
Here's a direct to the file for 2.x:
From reading the last patch and the code comment in the file, it appears the current syntax *should* work, because this rule:
props.setProperties("highway=cycleway", StreetTraversalPermission.PEDESTRIAN_AND_BICYCLE,
0.60, 0.60);
Appears first in the file before this rule:
props.setProperties("highway=*;bicycle=designated",
StreetTraversalPermission.ALL, 0.97, 0.97);
But I don't deeply understand this code and I may be missing something.
A second set of eyes would be welcome! To reproduce, you'll need to find an OSM way where "highway=cycleway" and "bicycle=designated" that's not right next to a road and see if OTP will route a trip across when "mode=CAR".
Thanks!