On master, the OSMCyclewayParser parses cycleway properties for exposing to the frontend, which ultimately renders them on the map (green "lane", dashed green "shared lane", dark green "track", etc.). In doing so, it makes assumptions that are often not valid, such as that cycleways on the drive side always go forward and opposite the drive side always go backward (contradicted by two-way cycle tracks), and that one-way streets (for cars) can only have one cycleway value (contradicted by contraflow lanes). The first commit in this PR fixes these situations.
On master, BikeCommonFlagEncoder assumes that if a street is one-way for cars, it's also one-way for bikes, despite the fact that oneway=yes + oneway:bicycle=no is a common OSM tagging practice for a street which allows contraflow bicycle traffic (seen on Lyell St north of Alemany in SF). BikeCommonFlagEncoder also assumes that if a street contains a bike lane that is explicitly marked as a one-way bike lane (which is the default!), the whole street is one-way. The second commit in this PR fixes these situations, so the router can correctly use contraflow bike lanes (such as the aforesaid Lyell St).
On master, when assigning penalties based on street conditions, instead of reusing the forward and backward cycleway values computed by OSMCyclewayParser, BikeCommonFlagEncoder does its own parsing of cycleway tags (which also contains errors relating to one-ways, etc.). The third commit in this PR makes the flag encoder use the already parsed forward and backward cycleway values, so penalty assignment also benefits from the corrected logic in the first commit.
I've verified this correctly handles (not an exhaustive list):
Battery Street from Market to Vallejo, two-way cycle track, both forward and contraflow directions (previously broken)
Scott Street just south of Fell Street, one-way north but two-way for bikes, both directions (previously broken)
Lyell Street, both directions (previously broken)
Fell Street, one-way cycle track on one-way street (still works)
Indiana Street forward and contraflow bike lanes, 26th St to Cesar Chavez (previously broken)
master, theOSMCyclewayParserparsescyclewayproperties for exposing to the frontend, which ultimately renders them on the map (green "lane", dashed green "shared lane", dark green "track", etc.). In doing so, it makes assumptions that are often not valid, such as that cycleways on the drive side always go forward and opposite the drive side always go backward (contradicted by two-way cycle tracks), and that one-way streets (for cars) can only have one cycleway value (contradicted by contraflow lanes). The first commit in this PR fixes these situations.master,BikeCommonFlagEncoderassumes that if a street is one-way for cars, it's also one-way for bikes, despite the fact thatoneway=yes+oneway:bicycle=nois a common OSM tagging practice for a street which allows contraflow bicycle traffic (seen on Lyell St north of Alemany in SF).BikeCommonFlagEncoderalso assumes that if a street contains a bike lane that is explicitly marked as a one-way bike lane (which is the default!), the whole street is one-way. The second commit in this PR fixes these situations, so the router can correctly use contraflow bike lanes (such as the aforesaid Lyell St).master, when assigning penalties based on street conditions, instead of reusing the forward and backward cycleway values computed byOSMCyclewayParser,BikeCommonFlagEncoderdoes its own parsing ofcyclewaytags (which also contains errors relating to one-ways, etc.). The third commit in this PR makes the flag encoder use the already parsed forward and backward cycleway values, so penalty assignment also benefits from the corrected logic in the first commit.I've verified this correctly handles (not an exhaustive list):
Fixes #70
Fixes #119