De werelwijde access defaults tabel in de wiki

Communities Nederland (Netherlands)
1

Ik ben aan het kijken naar de wereldwijde access defaults tabel.
Die roept bij mij een paar vragen op.

  1. Weet iemand toevallig waar de kolom “access” voor dient? Die geeft bij alle wegen als default access=yes en bij alle paden access=no.

  2. highway=service ontbreekt. Ik zou die er wel in willen zetten. De world wide default access voor sommige voertuigen is denk ik omstreden, maar dan zou ik “undefined” geven.

  3. highway=track ontbreekt. Weer zo’n omstreden geval… maar dat vind ik geen reden om hem weg te laten!

  4. highway=busway ontbreekt. Maar er is ook geen kolom voor bus. Is bus als transportwijze algemeen genoeg om een eigen kolom te krijgen?

  5. Niet alle voertuigvarianten hebben een eigen kolom, dat snap ik want de variatie is enorm en dat neemt alleen maar toe. Je zit ook al heel gauw in de nationale verkeerswet-, -regelgeving- en -bouwvoorschriften-sfeer. Maar is dat een reden om ze helemaal weg te laten uit een tabel die defaults moet aanbevolen voor wereldwijde routers en renderers? In de sectie over de voertuighierarchie staat veel meer maar dan moet die arme data user dus een speurtocht doen om het uit te zoeken, en dat maakt de tabel stukken minder bruikbaar als hulpmiddel.

  6. highway=pedestrian heeft foot=yes, ik zou denken dat dat designated moet zijn.

2

Dat was ook het eerste waar ik naar keek, aangezien ik toevallig net een gesprek had met @Friendly_Ghost over access=permissive voor brandstegen (service=alley) - waar osmose een broertje dood aan heeft (maar wat wel juist is in de meeste gevallen, of in ieder geval de voorbeelden waar we naar keken).

Het valt me op dat highway=service wel in de Nederland-specifieke lijst, maar ik vraag me af of dat juist is en uberhaupt kan. In theorie hangt de access immers nogal af van het type service. Voor een benzine-station vs. parking isle vs. alley bijvoorbeeld zou ik verschillende permissies voor foot= verwachten.

3

Plus dat er geen algemene overeenstemming is wat service=alley precies is. Dan wordt het heel lastig een wereldwijde default te bepalen; een groot deel van de wereld vindt een achterafstraatje een alley, voertuigen in principe toegestaan, en een ander groot deel vindt een achterpad een alley, voertuigen niet toegestaan. Default undefined denk ik, aleen foot lijkt me onomstreden.

4

Ik puzzel nog altijd met dat designated.
Mijn taalgevoel zegt me dat het met die tag het toegangsrecht nog niet is vastgesteld, enkel het gebruiksdoel (zie Oxford of Webster). Of gebruik verplicht is (mandatory) moet je ook nog vastleggen, wat dan weer wordt weergegeven met *:use_sidepath op een hoofdweg, afhankelijk van nationale wetgeving.

Highway=cycleway met bicycle=designated vind ik dan ook raar: een fietspad bedoeld voor fietsers …
En highway=pedestrian met foot=designated ook: een trottoir/voetgangersgebied bedoeld voor voetgangers.

In die wereldwijde lijst zou designated dan ook juist niet moeten staan, want het is geen access tag. Yes en No zijn de enige mogelijkheden. Een footway is toegewezen aan gebruik door voetgangers en het toegangsrecht is dan default ‘Yes’.

5

Volgens mij komt het beter over als je designated gaat vertalen met “bedoeld voor”.
Een fietspad is aangelegd en bedoeld voor fietsers, een ruiterpad is aangelegd en bedoelt voor ruiters, een voetpad etc.
Op zich vind ik de wiki niet heel onduidelijk hoor: Tag:access=designated - OpenStreetMap Wiki

6

Eens met Geim: wegen voor hulpdiensten geven we ook het etiket emergency=designated.

7

Dat is wat ik immers ook doe. Wat ik gek vind is dat in de door Peter aangehaald default tagging-tabel de term designated voorkomt.
Bijvoorbeeld bij highway=cycleway staat voor de toegang niet ‘yes’ maar ‘designated’. Maar dat is gewoon ‘yes’. De Wiki zegt ook dat de toegang hier al impliciet op 'Yes" staat omdat die volgt uit de naam.
Immers, als je de vraag stelt ‘mag een fietser daar rijden’ is het antwoord ‘Ja’ en niet ‘daar is het fietspad voor bedoeld’.

8

Voor een router is het binair: ja, de weg doet mee, of nee, de weg doet niet mee, voor het gekozen transport.
Voor de weggebruiker is het niet binair. Je mag erop maar het hoeft niet, je moet erop, je mag er absoluut niet op, je mag er alleen op als 't niet anders kan. Een toegespitste renderer kan ook de nuances weergeven met stijlkenmerken bv kleurtjes of stippels.

Voor OSM is afgesproken hoe een deel van de nuances getagd kan worden. bicycle= designated betekent: Dit is de aangewezen weg voor fietsen. Voor de router is dat yes, maar die kan dan bv een hogere waarde (of hoe die dat dan ook doet) toekennen omdat het ook nog het aangewezen pad is.
Verplicht wordt niet als access op het pad zelf getagd. Ik vind dat niet gek, omdat verplicht altijd geldt ten opzichte van een alternatief, dat dan níet mag, en dat wil je dan op het alternatief getagd zien. Dat hoeft de data user dan niet apart te gaan uitzoeken.

Of het de moeite waard is om dat allemaal te taggen? Och. Ik ga ervan uit dat men dat heeft afgewogen, en nu wordt het in NL in ieder geval massaal toegepast, het draagt informatie, dus ik zie ook geen reden om dat dan nu weer om te keren. Mijn enige zorg is dan nog om het zo volledig en consistent mogelijk uit te voeren.

9

Ha! Hier ga ik even ingrijpen voordat het tot hooglopende discussies leidt! (Of misschien lok ik die nu juist wel uit…)

Die tabel is géén tagging tabel! Hij geeft de vervangwaarden die data users kunnen toepassen als de benodigde tagging ontbreekt. Uiteraard gaan mappers daarop anticiperen, maar dat kan snel tot fouten leiden.
Mijn mening is dat de impliciete tags, die per definitie volgen uit het highway-type, zowizo niet getagd hoeven te worden. Dus highway=cycleway is automatisch bicycle=designated.

Een router kan dat als yes behandelen, maar ook een iets hogere waarde geven omdat het niet alleen toegankelijk, maar ook bedoeld is voor fietsen; het is een fietspad.

Mijn mening is verder, dat de wereldwijde defaults als impliciete tags beschouwd kunnen worden. Als heel OSM stelt dat secundary’s belopen mogen worden (tenzij anders aangegeven), dan is foot=yes vanzelfsprekend voor highway=secundary. Niet impliciet, want niet per definitie maar per consensus, maar dat is dan een academisch onderscheid waar de praktijk niks mee doet.

Aangetekend: ik vind dat sommige waarden in de wereldwijde default tabel anders zouden moeten zijn.

Het verschil tussen default en impliciet wordt lastig als je nationale defaults gaat vaststellen. Dat kan je doen, en is ook gedaan, maar… die zou je domweg niet als defaults moeten zien. Waar een nationale “default” geldt die niet overeenkomt met, of die niet voorkomt in, de wereldwijde default access tabel, juist daar moet je expliciet taggen. Je “vertaalt” dan de specifiek NL situatie naar tags die wereldwijd gelden.

Als je afwijkende nationale “defaults” niet tagt, dan bedien je nationale data users, maar je laat algemene (wereldwijde) data users in de steek, want die passen de wereldwijde access defaults toe (of hun zelfbedachte variatie daarop, die als het goed is overeenkomt met de wiki-tabel).
Of je dwingt ze om per land een andere set defaults te gebruiken, en dat is best wel heel erg lastig (blader maar eens door de nationale “default” tabellen op de access-wiki heen, met duizend voetnoten, speciale situaties, mitsen, maren en uitzonderingen). Gaat niet gebeuren, denk ik zo.

De vraag “mag een fietser daar rijden” is een routervraag. De vraag die de mapper beantwoordt is: “Wat is dat voor een weg en wat is de toegankelijkheid van die weg?”

10

Tja, het dwaalt nu een beetje af van mijn opmerking dat in die tabel designated beter yes kan zijn. Wat je eigenlijk zelf ook onderstreept immers want het is geen tagging-tabel maar een default access tabel. Heel strikt genomen betekent designated ook niet access=yes al wordt het wel zo opgevat en zal het meestal ook zo zijn.

Dat is wat ik ook schreef. Die tag hoeft er dus niet bij. Een ‘yes’ in de tabel is genoeg.

Dat je op een niet-cycleway die tag zet is al gebruikelijk. Of je er ook werkelijk fatsoenlijk kan fietsen moet dan nog uit andere tags volgen. Anders krijg je wat mij al is overkomen: kom je op een volledig onbegaanbaar pad terecht. Het nuttig gebruik volgt niet uit designated, zoals ook in de Wiki staat. Dat moet volgen uit andere tags.
Daarom render ik in Orux op mijn telefoon Duitsland ook anders dan Nederland. Ze noemen daar dingen fietspad die we hier als onbegaanbaar beschouwen.

Daar zijn we het oneens. Het gebruik van nationale defaults heeft grote voordelen. Als morgen bij ons de fat-bike van het fietspad wordt verbannen hoef ik bij nationale defaults dat maar op 1 plek te wijzigen. En niet expliciet op alle betroffen fietspaden.
Vroeger noemden we dat dan een relationele database maar misschien ben ik te oud voor het vak …

1 Like
11

Maar ook niet uit yes. Als je als data user de daadwerkelijke bruikbaarheid wil weten, dan kun je naar andere tags kijken, maar als die er niet zijn dan lijkt mij dat je als default ervan uitgaat dat het bruikbaar is.

Daar ben ik het wel mee eens, maar er is geen OSM-breed systeem van vastleggen van nationale defaults voor tagging, en vziw is er geen overeenstemming binnen de data users hoe ev. die toegepast zouden kunnen worden. Data users zijn dus aangewezen op hun eigen voorkeuren en doelgroepbehoeften, hoe ze met ontbrekende waarden omgaan.

Taggen met het oog op nationale defaults vind ik echt verkeerd, want dan verklaar je je eigen land tot maatstaf voor osm-tagging. Persoonlijk vind ik geen enkel land zo belangrijk dat hun manieren van taggen en hun defaults osm-breed geldig zijn. Zelfs Nederland niet.

Wat mij betreft moeten landen zo taggen dat hun landspecifieke eigenaardigheden, borden en wetgeving omgezet worden in tags die wereldwijd in OSM dezelfde betekenis hebben. Wij vertellen aan de wereld hoe het bij ons zit, in termen die overal begrepen worden.

12

Dat roept de vraag op: voor wie ben je aan het werk? Ik map niet voor data-users maar voor medemappers. Hoe anderen (routers/overheden) met die data om gaan is niet mijn zorg. Het is hun verantwoordelijkheid om te (leren) gaan met eigenaardigheden per land.
Ik zie ook geen verschil tussen het invoeren van wereldwijde defaults, die ook nog niet bestaan, en landelijke defaults. Waarbij vaak die landelijke defaults eigenlijk best aardig in de Wiki beschreven staan, en uiteindelijk minder werk voor de mappers opleveren.

Maar goed, daar gaan we dus niet uitkomen. Net als de keus tussen yes/designated in de default tabel waarmee het eigenlijk begon.

13

Precies daarom ben ik voor OSM-breed mappen, zodat iedereen aan de mapping en tagging ziet hoe het hier zit. Als wereldwijd alle wegen behalve de motorway voor voetgangers toegankelijk zijn, en bij ons is dat voor een bepaalde wegklasse anders, dan is het aan ons om foot=no bij te taggen, zodat wereldwijd alle mappers en data users weten dat bij ons die weg geen voetgangers toelaat.
Als je dat niet doet, dan gaat een OsmAnd de weg gewoon toelaten in het voetgangersprofiel. Heb ik daar een boodschap aan? Ja, daar heb ik een boodschap aan.
Zou OsmAnd dan een Nederlandse stand moeten hebben? En, omdat andere landen ook zulke eigenaardigheden hebben, en niet alleen met voet op die wegklasse maar met alle transporttypes op alle wegen, moet OsmAnd dan maar meteen een speciale stand hebben voor alle mogelijke nationaliteiten? En alle andere landoverstijgende toepassingen ook?
Volgens mij is het nog niet zo ver dat je dat kan eisen.

Als het wereldwijd aanvaard is dat op zo’n weg motorroad=yes kan staan, met de betekenis dat er geen voetgangers op mogen, dan hoort dat in de wereldwijde tabel toegevoegd te worden, zodat alle data users weten dat daar impliciet foot=no geldt.

Nog een gedachte verder: als ik in andere landen, internationaal naar fietsroutes zoek, mag ik dan verwachten dat de router alle landelijke regels en defaults kent en van land tot land toepast? Of mag ik verwachten dat de kaart die gegevens in internationaal bruikbare vorm aan de toepassing levert?

14

Wat mij betreft: ‘Ja!’ (volmondig). Als dit de moeilijkste eisen zouden zijn aan een routingprogramma…

15

En hoeveel routingprogramma’s doen dat?

16

Dat weet ik niet. Maar als in Nederland bij default voetgangers op het fietspad mogen behoeft dat niet op ieder fietspad getagd te worden. In Duitsland, bijvoorbeeld, is dat niet zo; daar zouden uitzonderingsgevallen wel op het fietspad getagd dienen te worden. Een look-uptabel in een router lijkt me niet zo ingewikkeld.

17

Één lookuptabel voor één toepassing in één router lijkt mij ook niet ingewikkeld. Maar landafhankelijke lookuptabellen voor alle defaults voor alle routingprofielen, voor alle routers en data users, dat lijkt me niet de beste overall aanpak.
Volgens mij zijn router-defaults nu hardgecodeerd in de profielen, niet in lookuptabellen.
(Als ik zoiets zeg krijg ik meestal de wind van voren van iemand die er echt verstand van heeft… maar dan wil ik wel man en paard horen: welke router gebruikt standaard landafhankelijke lookuptabellen, of een dergelijk mechanisme, om geautomatiseerd de toepasselijke landgebonden defaults te vinden?)

18

Off-line routers/kaarten gebruiken de database van OSM niet rechtstreeks. In plaats daarvan importeren ze secties (landen) en vertalen die naar tags waar ze zelf mee uit de voeten kunnen. En ze negeren tags die voor het routeren niet van belang zijn om het bestand zo klein mogelijk te houden. De ‘vertaalslag’ vindt dus al plaats op het moment dat de gegevens uit OSM (overpass) worden gehaald.

19

Ja, dat ken ik van OsmAnd. Die voert een omzetting uit, waarbij bv ook lidmaatschap van een bepaald type routerelatie (maar niet welke relatie precies) omgezet kan worden naar een tag van de weg zelf.
De omzetting gebeurt adhv een vertaalspec, een xml-bestand denk ik, in ieder geval gewoon tekst, net als de profielbestanden. De resulterende minidatabase wordt naar je mobiel gestuurd. Ik denk niet dat je dit onder “lookuptabellen” kan laten vallen. Er zullen in zo’n vertaalspec defaults toegepast worden, daarnaast weet ik zeker dat de profielen ook defaults gebruiken.
Ik kreeg niet de indruk dat er per land verschillende vertaalspecs zijn; er werd voor mij iets geregeld in de vertaalspec en toen ging het maar over 1 vertaalbestand, en het mechanisme wat daarop gebouwd is werkt overal. (Dat is: een toggle voor de optie “Prefereer wegen die lid zijn van een wandelrouterelatie”).
Ervan uitgaande dat andere data users vergelijkbare systemen gebruiken (allemaal, of sommige?), blijft de vraag dus: hoeveel routingprogramma’s doen dat, voor alle landen aparte defaults implementeren? Of misschien voor sommige landen/werelddelen/regio’s maar zit Nederland er dan bij? En Sierra Leone? Litouwen?

20

Ik heb geen inkijkje in de ‘keuken’ maar kan me goed voorstellen dat je in verschillende landen zo anders tegen wegen aankijkt dat wereldwijde defaults heel beperkt worden.

Zelf gebruik ik geen routeplanners maar kijk ouderwets op de kaart. Het wordt alleen steeds moeilijker een nette kaart te maken.
Stel highway=path met bicycle=designated. Is dat een fietspad? Nou nee, want die tags staan ook op MTB-routes. Nou goed, dan filter ik alles met route:mtb eruit. Helaas, veel mtb-routes gaan ook over stukken ‘echt’ fietspad als doorsteek of aanrijroute. En die wil ik weer wel zien. Kijken naar een surface-tag werkt dan ook niet goed: ik kan proberen alle surface:dirt/grass uit te sluiten. Maar er zijn ook weer landen waar een zandpad wel een fietspad is.
Je kunt dan misschien beter zeggen dat bicycle=designated op een MTB-pad niet handig is. Maar mtb=designated is ook moeilijk. Op mijn toerfiets heb ik daar uiteraard ook niks te zoeken. Maar dan: is een 29’er eigenlijk wel een MTB? Of bedoelen we alleen 26 inch fietsen.

Dat zijn vraagstukken waar ook een routeringsprogramma tegenaan loopt.
En ik zie dat je daar ook al eens met Ligfietser over van gedachten gewisseld hebt.