Wiki: “Each barrier has its own accessibility defaults. Use tag access=* to override them.”
Nooit van gehoord.
Wiki: “Barriers with undocumented default access imply access=no. This default restriction prevents softwares from routing through undocumented barriers (and generating a potentially unsafe route).”
Enige tijd geleden had iemand het onzalige plan uitgevoerd om bij heel veel bruggen in Nederland lift_gates te plaatsen. Volgens mij zijn die daar niet voor bedoeld. Resultaat… niets routeerde meer.
Dan kun je twee dingen doen … of weghalen… of yes toevoegen
Als barrier tag impliceert access=no zal je als de lift_gate open staat het op moeten heffen met een yes. Op basis van tijden op de node.
Als de bebording het toe laat kan je dan van de lift_gate gebruik maken, C1 gaat over de way, C1 bepaald vervoervorm op de way.
Eigenlijk staat node lift_gate en way C1 los van elkaar.
De vraag is zijn de uren van lift_gate bediening, hetzelfde als het C1 onderbord aan geeft.
Enige relatie hebben ze dan met elkaar.
Vandaar mij keuze van vervormen op de lift_gate, eigenlijk zou dat ook alleen met access:conditional af kunnen.
Het is maar net welke benadering het correctst is.
Vanuit de barrier optiek (access=no default) of de verkeersbord optiek (met aanpassing om open te stellen access=yes)
Ik uit gegaan van barrier optiek.
Wat is het?
Er moet wel gecheckt worden of tijden en open staan barrier klopt.
Er staat ook een bus=yes op de lift_gate.
Als de bus altijd de mogelijkheid heeft om door te rijden, met knopje om de lift_gate omhoog te laten gaan.
Dan zal elke :conditonal de tag bus=yes overrullen.
Met access=yes access:conditional=no @ (Mo-Fr 16:00-18:00), dan is het ook voor de bus gesloten.
En moet je nog een conditional voor de bus regelen (=yes), tussen die tijden staat het op *:conditional=no
Bij barrier optiek.
Is het al bus=yes en de :conditional=yes is ook aanwezig. (Dubbel op voor die tijd)