Missed the notification. Indeed I suggested network=Uber with brand= for =Uber Black in mind. Didn’t mention it to avoid overcomplication there.
I would like to ask why except:conditional= is being discussed here. Is it Lyft’s router? restriction:rideshare:conditional= none @ (*) is shorter and more organized. However, except:network= or eg except:rideshare:network= (to avoid the network= being interpret for others bus= etc) is an interesting simplification.
Using except= , it should still be except=bus;bicycle + except:conditional=rideshare @ (*) , no need to have the first two in except:conditional= (assuming buses and bikes are always exempted)
To date, the infamous restrictions in downtown San Francisco are signposted as turn restrictions preventing turns onto Market Street with four exceptions: trucks, buses, (licensed) taxis, and bicycles. As you travel along the street, signs and markings also indicate that the left lane is reserved for buses and taxis only, while the right lane is designated for bicycles. Beyond that, there are no signs restricting access, of the sort that we normally tag with access tags, but such signs would be moot anyways.
After an initial round of confusion several years ago, we’ve avoided tagging Market Street with a full complement of access tags, instead mapping turn restrictions based on the signs. The bus–taxi lane is modeled as a separate busway due to the enhanced lane change restriction indicated by double solid white lines.
I’ve been assuming that SFMTA would allow the exempted ride sharing services on the right lane only, since the left lane is useless for making pickups and dropoffs. I’ve also been assuming that they’d continue to rely on turn restriction signs over access restriction signs for enforcement purposes, whether or not they bother to replace the existing turn restriction signs during this pilot program.
Is that how it works when combining conditional restrictions with semicolon value lists? I was never quite clear on that.
Oh my mistake, was only looking at bus; bicycle lacking conditions. Forgot this is semicolon multival. But then bus; bicycle; rideshare @ (brand:wikidata=Q136550451 AND 19:00-06:00); would cause brand:wikidata=Q136550451 to be evaluated for bus; bicycle together. It’s either wrong; or meaningless, confusing, and cluttering. It would seem *:conditional= can’t be used when the conditions don’t apply to all of them. This makes another reason of not using except:conditional= , which has few number anyway. except:conditional | Keys | OpenStreetMap Taginfo
So far, GraphHopper and the others are willing to have cyclists turn right from Seventh onto Market, despite the turn restriction, because of the exception tagging. The turn restriction was edited yesterday to include these brand-based conditional exceptions. Let’s see in a couple days if they cope with the tagging. We can then document this syntactic edge case in terms of how routers behave.
The GraphHopper bicycle profile unfortunately completely ignores turn restrictions, exception or not. When I complained, the justification I was given was that a cyclist can always get off and cross the street. Unfortunately this isn’t always an option if you are stuck in multiple lanes of fast moving traffic. Anyway, for you this means that GraphHopper’s behaviour in this case won’t tell you anything about how GraphHopper evaluates conditional excepts.
1 Like