De use_sidepath toegangswaarde: gebruik gaat verder dan documentatie

Achtergrond

Afgelopen maand heb ik een bug deels opgelost in OSRM (vrije software navigatiebibliotheek o.a. gebruikt op openstreetmap.org) gemeld door AllRoads:

Bicycle and oneway, routing wrong

OSRM paste de toegangsbeperking die bicycle=use_sidepath impliceert nog niet toe. Nu wel (deze fix is nog niet beschikbaar op openstreetmap.org).

De tagwaarde use_sidepath betekent dat er een aparte weg is ingetekend waar de fietser wel hoort te fietsen. Voor navigatiesoftware volstaat dat de weg met use_sidepath effectief verboden is voor de fiets. Dat er semantisch onderscheid valt te maken tussen bicycle=no en bicycle=use_sidepath is voor navigatie volgens mij niet relevant. Hooguit zou een geavanceerde navigatietool de instructies anders kunnen formuleren (maar de route blijft gelijk).

Deze fix zou een hoop routingissues moeten oplossen waar fietsers over (vaak gevaarlijke) rijbanen gerouteerd worden. Nu zal dat in de praktijk niet heel problematisch zijn omdat de lokale situatie de gebruiker al snel naar de parallelle ventweg of fietspad stuurt, maar het moet wel kloppen.

Helemaal opgelost is de bug daarmee niet, want er gebeurt in het voorbeeld van AllRoads iets interessants: de navigatiesoftware ziet dat de snelste route over een paar meter eenrichtingsverkeer gaat. En wat doe je als fietser als je de keuze hebt tussen afstappen en vijf meter met de fiets aan de hand lopen of tweehonderd meter omfietsen? Je stapt af (of als je een botte hork bent fiets je door) en vervolgt je weg na een paar meter lopen.

OSRM doet dit ook (maar vertelt het nog niet duidelijk in de routeomschrijving dat de fietser daar af stapt).

Waarom gaat het dan mis bij dat voorbeeld van AllRoads? Je mag toch niet lopen over dat stukje weg?

De tags:


bicycle   use_sidepath
foot      use_sidepath
highway   secondary
mofa      use_sidepath
moped     use_sidepath
oneway    yes

De tag use_sidepath wordt ook op foot, mofa, en moped toegepast. Dat botst op dit moment expliciet met de documentatie (zie ook access) en het oorspronkelijke voorstel, die deze tag voor bicycle reserveren.

De tagwaarde wordt echter ook toegepast op andere tags. Relatief vaak, en hoofdzakelijk in Nederland:

Het gaat hier mis omdat OSRM (en andere navigatiesoftware) niet weten dat foot=use_sidepath betekent dat voetgangers en afgstapte fietsers daar helemaal niet horen te komen. Zij hanteren een lijst van waarden die toegang verbieden, waaronder no en private, maar use_sidepath ontbreekt.

Waarom gaat dit mis?

Zonder documentatie en consensus over tags kan navigatiesoftware er geen rekening met houden. Wanneer het gaat om iets kritieks als access-tags, is documentatie erg belangrijk. We schieten daar nu in te kort. De documentatie zegt nu dat use_sidepath alleen voor bicycle een geldige waarde is.

Als iemand op termijn een navigatieprofiel voor mofa of moped wil maken, dan is het ook belangrijk dat use_sidepath voor die categorieën kloppend gedocumenteerd is.

Hoe lossen we dit op?

Ten eerste: stel vast wat use_sidepath betekent voor alle access-sleutels. Waarschijnlijk betekent dat simpelweg dat de defintie van bicycle=use_sidepath wordt overgenomen en geldig wordt verklaard voor alle toegangssleutels, met name foot, mofa, en moped.

Wanneer dat gedaan is, kan het probleem aangedragen worden bij de navigatiesoftware die mensen gebruiken. Ik wil zelf best wel een poging wagen het te zijner tijd op te lossen in OSRM voor voetgangers en (afgestapte) fietsers; de documentatie laat ik graag aan anderen over die meer in deze materie zitten.

Zaken waar ik geen antwoord op heb

Volgens mij kan hier binnen de NL-gemeenschap wel consensus worden bereikt over de bredere definitie van use_sidepath, maar ik vermoed (verbeter me als dit niet klopt) dat dit nooit op de tagging-mailinglist is afgestemd. Dit gebruik van use_sidepath buiten bicycle lijkt een clandestiene introductie van een nieuwe tag te zijn. Daar kan terughoudend op gereageerd worden. Een wijziging van de documentatie van access zal ongetwijfeld vragen oproepen. Heeft iemand een idee hoe hier mee omgegaan kan worden?

Omgekeerd. als eerst de documentatie wordt geschreven, dan is het verwijt dat er autoritair wordt gehandeld omdat er wordt gedicteerd welke tags er moeten worden gebruikt. Het is maar net wie er reageert.

De documentatie hoort eigenlijk pas na een voorstel (waar de voorlopige documentatie ook in zit) en consensus over dat voorstel te komen. Zo is bicycle=use_sidepath ook geïntroduceerd.

Natuurlijk gebeurt het ook andersom: eerst de tag gaan gebruiken, draagvlak creëren, documenteren, rendering regelen, etc. Dat kan soms ook prima. Maar, het gaat bij use_sidepath om een access-waarde. Daar zal iets zwaarder aan getild worden dan een nieuwe shop-tag voor bepaald soort winkel.

Hoe dan ook, we hebben nu tienduizenden access-tags in gebruik die niet gedocumenteerd zijn.

Ik kan me vinden in je betoog. Wel is het goed een klein beetje context te geven op het ontstaan van bicycle=use_sidepath. Dit voorstel komt o.a. van mij en destijds heb ik er ook aan gedacht om het breder te trekken dan alleen bicycle. Op advies heb ik dat bewust niet gedaan. Dit omdat het toch best een complex voorstel was waarbij het al moeilijk genoeg was om voor bicycle consensus en een geaccepteerd voorstel te krijgen. We zijn nu een aantal jaren verder en daarbij zien we dat het in de praktijk breder wordt toegepast dan alleen bicycle. Ik zou dat niet clandestien willen noemen maar een logisch gevolg van. Op zich is daar niets mis mee maar ik ben het met je eens dat het beter is als het een geaccepteerd voorstel met een gedocumenteerde wiki zou zijn.

Ik denk dat het nu relatief makkelijk zal zijn om een algemeen xxx=use_sidepath geaccepteerd te krijgen maar iemand zou dan een voorstel moeten maken (bv richting tagging mailinglijst) en een wiki in elkaar moeten zetten. Ik denk dat het met knippen/ plakken en wat kleine aanpassingen te doen moet zijn. Ik ga het in ieder geval niet doen maar wellicht voelt iemand anders zich geroepen.

Ook ik begrijp je gedachtegang.

Dat een value met dezelfde intentie gebruikt wordt bij andere keys komt veel vaker voor.
Niet voor elke key/value combinatie wordt een proposal met voting geschreven.
En daarna een WIKI pagina.

Proposal process

Proposal

Besproken op een overleg wiki pagina, Talk, dit forum, anders en ook eigen initiatief (het beste na een goed onderzoek en afweging).

En zo staat het al op de NL:Sidewalks pagina. Vertaald Sidewalks

“kan” maar ook op cycleway. Ik heb laatst een JOSM ticket aangemaakt, zag een validatie melding op een cycleway omdat de tag segregated niet was ingevuld bij een foot=use_sidepath op een cycleway. Inmiddels opgelost.
Een reactie was:

Zo is het in de Austria OSM tags for routing/Access-Restrictions pagina beschreven.

Moet het Nederlandse deel dan ook zo aangepast worden?

Zo komt het op verschillende plaatsen in de wiki voor. duckduckgo

Het lijkt er op, dat het als een “vanzelfsprekendheid” al is geaccepteerd.

Misschien moeten we daar de conclusie al trekken en op eigen (forum) initiatief, wiki pagina’s aanpassen.
Zo ook de access List of possible values Die ook een bredere invulling van gebruik nodig heeft.

De kern van het gebruik is dat er een separate way ingetekend moet zijn, om use_sitepath te kunnen gebruiken.

Een wiki page use_sidepath zou welkom zijn!

OSRM
Add support for foot=use_sidepath / sidewalk=separate
Daar kan je op in haken, want dat is een onderdeel van de topic openings problematiek.

Inmiddels heeft Jeroen Tag:foot=use_sidepath aangemaakt, bedankt!

Fijn dat je dat opviel. :slight_smile:

Wat fijn dat foot/mofa/moped = use_sidepath nu in de Wiki gedocumenteerd zijn! Misschien nog, voor de zekerheid, erbij schrijven dat die value alleen geldt als toegang niet expliciet door een bordje verboden is? Bijvoorbeeld voor het laatste zinnetje van ‘How to tag’

If the highway is explicitly forbidden for foot/mofa/moped traffic (typically by means of a traffic sign), do not use use_sidepath but foot/mofa/moped=no.

Leef je uit, dat klinkt als een goede toevoeging. :slight_smile: Iedereen kan de wiki aanpassen.

Gedaan :slight_smile: