Access tagging discussies zijn een blik wormen, maar ik heb een konkrete vraag. Het gaat erom hoe Knooppuntnet (analyse en planner) kan zekerstellen of een route doorgankelijk is voor fietsen.
Gegeven hoe access nu getagd is (alle voorkomende varianten), met welke logika evalueer je of een weg toegankelijk is voor fietsen?
Hoe het zou moeten of hoe het gedaan wordt door routers?
Je kan de broncode van OSRM en GraphHopper inzien, maar de basis is dat je de impliciete access-tags neemt op basis van land en highway-type, en daar de getagde accesswaarden volgens de access-boom aanvullend op toepast volgens de boomhiërarchie. Dan nog rekening houden met richtingsbeperkingen. Verder kan een node op de route (een bollard bijvoorbeeld) ook nog beperkend werken, hoewel dat fietsen niet snel het geval zal zijn. Deze hebben ook impliciete waarden waar de getagde accesswaarden weer overheen komen.
Naast dit moet je nog rekening houden met conditional accesstags die van toepassing kunnen zijn op basis van bijvoorbeeld de datum of de tijd van de dag, maar als je zulke uitzonderingen negeert (begrijpelijk) mis je misschien een promille of wat van de route.
De gewenste logika analyseert een fietsrouterelatie op toegankelijkheid voor fietsers en levert ofwel Ja ofwel Nee op. Dit is de huidige logika in de knooppuntnet analyser:
private def bicycleAccessible(way: Way): Boolean = {
(way.tags.has(“highway”) ||
way.tags.has(“highway:virtual”) ||
way.tags.has(“route”, “ferry”) ||
way.tags.has(“bicycle”, “yes”)) &&
!way.tags.has(“bicycle”, “no”)
}
Het idee is om daar in ieder geval aan toe te voegen:
&& !way.tags.has(“highway”, “construction”)
Maar misschien moeten er ook nog andere bicycle= waarden bij
? bycycle=sidewalk en bicycle=lane bijvoorbeeld?
En wat moet je met bijvoorbeeld vehicle=yes|no al of niet met een bicycle=no|yes erbij?
Correct.
Verder mis ik:
!way.tags.has("bicycle", "private") &&
!way.tags.has("bicycle", "use_sidepath")
destination houdt een router ook nog rekening mee, maar dat is complexer, want je mag dus wel starten of eindigen in een access=destination gebied, maar er niet doorheen gaan. Voor fietsers zijn deze zeldzaam gelukkig.
bicycle=lane ontleent volgens mij de accesswaarden aan de weg zelf, net als alle andere lane-constructies. Overigens kunnen lanes ook nog extra beperkingen hebben, maar daar heb je in de routing geen last van tenzij je ook wil tonen op welke strook een fiets hoort bij een bepaalde route. bicycle=sidewalk bestaat niet.
Specifiek gaat boven generiek.
vehicle=no
bicycle=yes
Fiets mag.
access=yes
vehicle=yes
bicycle=use_sidepath
Fiets mag niet.
Een fiets is verder een vehicle, dat kun je in de accessboom zien (fiets valt onder vehicle, die onder access valt).
vehicle=no
Fiets mag niet, tenzij een bicycle-tag nog anders zegt.
vehicle=yes
Fiets mag, tenzij een bicycle-tag nog anders zegt.
Dat laatste betekent dat je dus meer moet doen dan wat je in die ene Boolean-functie kan doen. Je krijgt vier stappen:
Mag een fiets over dit type highway als er helemaal geen access-tags opstaan? (Ja/Nee)
Staat access=* toegang toe? (Ja/Nee/Niet ingesteld)
Staat vehicle=* toegang toe? (Ja/Nee/Niet ingesteld)
Staat bicycle=* toegang toe? (Ja/Nee/Niet ingesteld)
Een Ja of Nee waarde overschrijft de initiële Ja/Nee uit functie 1. Een Niet ingesteld laat de vorige waarde staan.
Voor de drie onderste functies geldt dat je moet vaststellen wat de Ja- en Nee-waarden zijn, bijvoorbeeld:
yes
designated
permissive
dismount
no
private
use_sidepath
Voor doorgaande fietsroutes kun je dus goed overwegen om ook waarden zoals customers en destination als Nee te rekenen.
Als je allerlei foutmeldingen van fietsroutes bij grote wegwerkzaamheden wil verkomen, zou ik net als nu de highway=construction toegestaan laten.
Je kan de routes ook verleggen naar een omleidingsroute, maar hoe garandeer je dan dat de route weer teruggezet wordt naar de oorspronkelijke weg als je werkzaamheden voorbij zijn?
Fiets aan de hand, vele routers zien bicycle=no niet als een harde no.
Voor een harde no is nog geen tag.
Deel community vindt dat no wel hard is een ander deel niet.
In bepaalde gebieden mag je de fiets niet aan de hand meenemen, zo ook dragen ( in possession ).
Bijvoorbeeld art.461 gebieden.
Routers zijn het anders gaan gebruiken, gevolg, deel gaat er in mee.
Waarschuwingen zijn goed. Je hoeft er niet op te acteren immers. Als een tool een mogelijk probleem detecteert aan de hand van logica dan rapporteert deze dat aan de gebruiker van de tool. Die kan dan alsnog besluiten dat iets inderdaad niet routeert, maar dat dat komt omdat de omleiding niet ingetekend is bijvoorbeeld. Hoe je daar dan mee omgaat is een kwestie van beleid, niet techniek. Als mapper zou je kunnen besluiten om bicycle=yes (of bicycle=dismount) op de higway=construction te zetten als je daar enigszins langs kan en mag, of om de melding gewoon te negeren.
Doorgaans geen probleem voor fietsknooppuntroutes. Die lopen immers niet over wegen waar je zelfs niet met de fiets aan de hand mag lopen. Met uitzondering van dingen zoals pontjes etc. zijn de fietsknooppuntroutes bedoeld om te kunnen fietsen zonder stukken met de fiets in de hand te moeten lopen.
Ja daar heb je het al… maar dat is toch een andere vraag. Het gaat niet om al dan niet tijdelijk verleggen en omleiden, maar om: is een highway=construction in principe toegankelijk voor fietsen via een knooppuntroute of niet.
Bij wandelen denk ik zelf al gauw: ik ga eerst even kijken, want meestal kom je er wel langs. Maar met de fiets gok ik daar niet op. Ik zou van een routeanalyser dan ook verwachten dat die de route wel toont, maar een melding geeft en hem niet voor planning gebruikt. Op het moment dat de construction eraf gehaald wordt, verdwijnt de melding en kan je er weer mee knooppuntplannen.
De analyser kan hier soepeler zijn dan een router, want iemand heeft die route zo gemaakt dus die heeft geoordeeld dat het mogelijk en de bedoeling is om daar met de fiets te gaan en dat op de weg ook aan te geven met fietsnetwerkbordjes. Daarom zijn er ook weinig problemen met de huidige check!
Ik ken inderdaad (buiten pontjes) ook andere plekken waar je meestal of soms zal moeten afstappen. Ik zou zeggen highway=pedestrian is toegelaten (hangt vaak van drukte, tijd van de dag, dag in de week of marktdag af), highway=path en highway=track ook toegelaten, misschien zelfs highway=steps, maar highway=footway (tenzij met bicycle=yes) en highway=bridleway niet.
Trouwens, ik ken ook cycleways waar je om de paarhonderd meter van de fiets moet om door een schapenhekje te gaan.
Maar met die redenering heb je helemaal geen analyzer nodig, want de route is zo gemaakt en beoordeeld.
Als een fietsknooppuntroute over een highway=pedestrian gaat waar fietsers niet expliciet wel over heen mogen volgens aanvullende tags, dan is waarschijnlijk die route niet in orde, of het is geen highway=pedestrian. Als je analyzer daar op valt, en het is wel een deel van de route maar je behoort af te stappen, dan is dat een hint dat daar wellicht een bicycle=dismount nodig is.
Als je een analyzer hebt om mappers op mogelijke fouten te wijzen is dat nuttig. Een deel van een fietsknooppuntroute zou immers ook in een router gewoon moeten werken (pontjes daargelaten).
Wat is je doel?
Bij nieuw invoeren of aanpassen van een knooppuntroute (bv op basis van een gpx, waarbij je zelf nog de daarbij passende ways moet aangeven) checken op de minimaal noodzakelijke access, oftewel checken op ontoelaatbaarheden die je kan aanpassen. Bijvoorbeeld dat je een nog niet ingevoerd fietspad moet nemen ipv de hoofdrijbaan waar je niet opmag. Als het echt niet kan volgens de tags, maar je weet zeker dat de route daar loopt, dan is de tagging waarschijnlijk onjuist en moet je daar achteraan.
Bij bestaande knooppuntroutes, detecteren als er iets aan de weg veranderd is waardoor die niet meer toegankelijk is. Zo heb ik (bij wandelen dan, daar is de logika natuurlijk weer anders) onderbrekingen gevonden doordat taggers foot=no op de fietspad gezet hadden. Klopt, wel wat streng maar er waren voetpaden naastgelegd en dan is lopen op het fietspad niet meer toegestaan.
Bijvoorbeeld een lift of een roltrap zou er in principe wel in mogen zitten. Een trap, een trekpontje, zou kunnen. Afstapgevallen, maar wel planbaar. Een path, een pedestrian, een track, allemaal niet onmogelijk en ik weet er ook voorbeelden van. Dus die zou je, lijkt mij, voor dit doel moeten toelaten tenzij expliciet bicycle=no.
Path en track is prima, dat staat ook in de implicietewaardentabel, maar pedestrian wijst zonder aanvullende tags wel op iets waar je als mappers eens moet kijken waarom dat zo ingepland is. Als dat echt een deel van een fietsknooppuntroute is, dan zou mijn vermoeden namelijk zijn dat iemand daar highway=pedestrian ten onrechte gebruikt, of dat het wel klopt, maar dat aanvullende tags (zoals bicycle=yes) ontbreken, of dat het klopt en de fietsroute verlegd is.
De beheerders van de fietsknooppuntroutes werken immers in opdracht van de lokale overheden, en houden zich gewoon aan de verkeersregels met uitzetten (Marrekrite in ieder geval wel).
Er liggen fietsknooppuntroutes bewegwijzerd en wel over voetgangersgebieden zonder bicycle=yes. Men gaat er vanuit dat je dan met de fiets aan de hand wandelt. Deze routes moet je dus niet afkeuren.
Ook zijn er routes waar de bewegwijzering je over een trap laat gaan.
track staat niet in de defaults tabel, maar is in een aantal landentabellen wel toegevoegd, vaak met aantekeningen.
een steekproefje: Italië Frankrijk België Nederland Duitsland (fietsen toegestaan), Default Engeland Amerika niet gespecificeerd. Dat wordt een imp-liciete bicycle=yes lijkt mij.
pedestrian: B dismount or slow D dismount F slow A yes E yes I yes N no Default no
Dus voor Nederland en als default niet fietsen, maar er zijn wel erg veel uitzonderingen bij de landentabellen. Dus hoe internationaler de knooppunten worden, hoe minder het klopt. Ik heb de neiging een highway=pedestrian voor de (internationale) Knooppuntnetplanner wel toe te staan.
Je hebt nog meer dismountgevallen: lift (maar dat is een punt), roltrap, ?voetgangersbrug? daar zou je misschien een bicycle=dismount op mogen verwachten.
In de verstekwaardentabel mis ik trouwens highway=service. Fietsen is daar in principe niet verboden denk ik?
service is niet verboden
Als je die gaat verbieden, lopen er heel veel routes niet meer.
Er staan veel wegen op service, die eigenlijk unclassified of residential moeten zijn
En ook lopen er routes over parkeerplaatsen
Dus:
(yes betekent: mag in fietsknooppuntrouterelatie voorkomen; no: wordt afgekeurd door Knooppuntnet analyse en kan niet gepland worden in de Knooppuntnet fietsplanner.)
highway=motorway[_link] (no) Ook niet met bicycle=yes denk ik?
highway=* and motorroad=yes (no) Ook niet met bicycle=yes, denk ik?
highway=trunk[_link] (WEET IK NIET! F, B, N no, maar default yes en US, VK, D en I yes. )
highway=primary[_link] (yes)
highway=secondary[_link] (yes)
highway=tertiary[_link] (yes)
highway=unclassified (yes)
highway=residential (yes)
highway=living_street (yes)
highway=track (yes)
highway=path (yes)
highway=bridleway (no)
highway=cycleway (yes)
highway=footway (no)
highway=pedestrian (yes)
highway=service (yes)
highway=road (yes)
highway=steps (yes) ev met conveying=yes voor roltrap.
route=ferry (yes)
Verder nog (ways only):
highway=construction (no)
highway=proposed (no)
highway=* and motorroad=yes (no)
highway=busway (no)
highway=bus_guideway (no)
highway=raceway (no)
highway=escape (no)
highway=corridor (no)
highway=platform (no)
highway=<other_values> (no)
Dat zijn de highway values die in aanmerking komen met de verstekwaarde of ze voor mogen komen in een fietsknooppuntroute.
In principe kan een yes overruled worden door een bicycle=no, en een no door een bicycle=yes.
Met expliciete bicycle=yes|no is het duidelijk. bicycle=dismount voor dit doel is een yes.
En dan wordt het lastig met access=, vehicle=
bicycle=troeft alle andere af, alleen bekijkt de huidige functie nu maar twee waarden en in feite kan het zijn:
bicycle=…
(bekijk access=* en vehicle=* )
lane (=ontbreekt)
yes (yes)
no (no)
designated (=yes)
use_sidepath (=no) /* want dan moet de fiets het apart gemapte fietspad kiezen /
dismount (=yes)
permissive (=yes)
private (=no)
customers (=no) / denk ik. Of is een pad dat bv een natuurreservaat ingaat, waar je een fietskaartje voor moet kopen, getagd met bicycle=customers? /
destination (=yes) / want je mag er wel inrijden, het kan een aanlooptakje of eindtakje naar een veerpont zijn)
Dus wat er nog bij moet is combinaties van access=* en vehicle=* zonder bicycle=*, wanneer het wegtype bij verstek a. wel / b. niet akkoord is voor knooppuntfietsers.
Daarvoor geldt dan, ongeacht access=* of default voor het wegtype, als vehicle=yes (of vergelijkbaar) dan is het akkoord.
En als er ook geen vehicle=* tag is, dan geldt access=*.
Het zou dan denk ik handig zijn als die functie (per OR evaluatie) kapt zodra hij een False tegenkomt. Dan hoe je niet alle mogelijke kombinaties van tags en waarden volledig uit te schrijven.
@Peter
De defaulttagging in de verschillende landen waaronder Nederland
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#The_Netherlands
Bij highway=trunk is een fiets dus =no per default