graphhopper / graphhopper

Open source routing engine for OpenStreetMap. Use it as Java library or standalone web server.

Home Page:https://www.graphhopper.com/open-source/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

highway=cycleway + access=no + bicycle=NULL is used for routing

zidel opened this issue · comments

Describe the bug
Cycleways that are tagged as closed with access=no (and no conflicting bicycle=*) are still used for routing, e.g. https://www.openstreetmap.org/way/424854123

Expected behavior
Cycleways with access=no are not used for routing unless there is a bicycle=* or vehicle=* with a positive value

System Information
Tested via openstreetmap.org and graphhopper.com

Screenshots & Logs

https://graphhopper.com/maps/?point=61.459975%2C5.814842&point=61.459033%2C5.827119&profile=bike&layer=Omniscale
https://graphhopper.com/maps/?point=59.911557%2C10.627221&point=59.909744%2C10.625891&profile=bike&layer=Omniscale

See discussion in #870. Maybe @ratrun can comment on this.

Anyway, the discussion about the tagging above is valid. I'm going to prepare a change to accept highway=cycleway toghether with vechicle=no. We should allow this for bicyles. Cycleways under construction should be tagged with with highway=construction

commented

Access parsing aside, the road isn't tagged properly IMHO. This should be highway=construction + construction=cycleway as explained in the OSM wiki:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dconstruction#How_to_map_the_start_of_a_road_repair_or_reconstruction

Currently we are treating access=no and vehicle=no the same way with allowing this segment for bicycles. But according to https://wiki.openstreetmap.org/wiki/Tag:access%3Dno the intention of access=no is stronger. While on a segment tagged as vehicle=no it is still possible and legal to dismount and push for access=no this is not the case. So I think that this problem report is valid and we should change it. I'm going to prepare a PR if there aren't any objections.

And should we remove the special case way.hasTag("highway", "cycleway")) in BikeCommonAccessParser? And then consider the "dismount" for vehicle=no in OSMGetOffBikeParser and BikeCommonAverageSpeedParser?

And should we remove the special case way.hasTag("highway", "cycleway"))

I extended the check there in my first version of the PR, see #2981

And then consider the "dismount" for vehicle=no in OSMGetOffBikeParser and BikeCommonAverageSpeedParser?

Yes that is a good idea. I'll try to extend the PR.

commented

And then consider the "dismount" for vehicle=no

Broadly speaking, we should do this for all cases where foot access is allowed but biking isn't.

Have also thought about this like using foot_access in a custom model as exception when bike_access is false but there are several cases where is does not work like for steps or bad surfaces or a too big hike_rating (sac_scale) etc.

This issue can be closed, the provided examples are working.