Dat gaat over het gewicht dat ze toekennen nadat de way geselecteerd is, dus de router heeft de principiele access voor dat profiel al op yes gezet. Bij primary’s is de berijdbaarheid niet zo’n punt, dus de toegang is ofwel yes ofwel no; bij ontbreken moet de router toch kiezen of de way meedoet in de routing of niet, en dat is dus de default. Wereldwijde routers zullen primary’s mee laten doen; een puur Nederlandse router zou waarschijnlijk kiezen voor no als default fietsaccess op primary’s.
Aan de mappingkant is de keuze: mappen we voor de wereld, dan houden we default yes aan. Op de weg is dat ook zo: het fietsverbod moet uit borden blijken, anders mag de fiets er in principe gewoon op. Dan moeten we dus alle primary’s waar je vogens de bebording niet met de fiets opmag, bicycle=no (of iets anders wat op no neerkomt) geven.
Mappen we specifiek voor Nederland, dan kun je overwegen om de default op no te houden, en alleen de yessen expliciet te mappen. Dan map je dus het ontbreken van een verbodsbord.
Mijn mening is dat we niet specifiek voor Nederland moeten mappen. Het is niet realistisch om te verwachten dat alle software en apps on the fly vaststellen dat het om Nederland gaat en specifiek voor dat grondgebied om te schakelen naar aparte NL-regels (waaronder zeer specifieke access-regels en defaults). Ik vind dat we de Nederlandse situatie moeten uitdrukken in wereldwijd geldende tags. Dan hoeven niet alle toepassingen de speciale NL-bebording en -wetgeving te kennen en in te programmeren. En ik verwacht ook van andere landen dat ze dat doen, zodat niet alle Nederlandse toepassingen alle borden en alle verkeersregels en -wetgeving hoeven te kennen om ook over de grens bruikbaar en juist te zijn.
En vervolgens geldt: als het resultaat een foute weergave of foute routering is, dan zit daar een fout of gat in de OSM-data, en is het aan ons om dat te verbeteren/aan te vullen. Als het om verkeersveiligheid gaat is de prioriteit hoog, daar moet je gewoon op kunnen vertrouwen. Maar daarvoor moet je niet de methode van tagging veranderen, daarvoor moet je de data compleet en correct en consistent maken. Dat wil zeggen dat het voor routing access niet van toevallige mapping afhankelijk mag zijn, zoals dat voor rendering nog wel kan. Je kan dat ook omkeren: als je de mapping en tagging afhankelijk laat zijn van toevallige mappers, dan kan je niet verwachten dat een router, of een andere toepassing waar dingen serieus van afhangen, dat oplost.
Precies dat gevoel had ik bij de verwijdering van die banners die daaraan voorafging -die ik dus niet zelf had geplaatst maar wel heb hersteld, al helemaal omdat de daarbij genoemde redenen (“These defaults are extremely important, and the claim about the Netherlands is factually incorrect.”) niet onderbouwd zijn en ook niet te rijmen zijn met de inhoud van de betreffende wiki.
Het gemak waarmee -ook in dit discussiedraadje- wordt gesuggereerd dat data kan worden verwijderd enkel alleen omdat het “default” is -terwijl er op die wikipagina veel tegenin wordt gebracht- onderstreept het belang om dat voldoende duidelijk te maken en niet ergens weg te stoppen op een talk-pagina.
En ik moet wel bekennen dat ik hier een beetje allergisch voor ben geworden, het verkeerd interpreteren van die tabellen heeft eerder geleid tot massale verwijdering van correcte data zoals foot / bicycle=yes op highway=path “omdat het default is” .
En het is ook bepaald niet de eerste keer dat erop gewezen is dat dat niet is hoe die tabellen gelezen moeten worden.
Eerder hadden we bijvoorbeeld deze discussie met een flinke baard, waar bij sommige mappers het kwartje is gevallen, ik wordt er soms wel moedeloos van om dat steeds opnieuw aan te moeten kaarten. Vooral als je dan bedenkt dat meerdere andere (ervaren) mappers ook al -jaren geleden- berichten van dergelijke strekking op die default wikipagina hebben gezet en dat ook hier weer wordt afgedaan dat ja maar (recente…) wiki’s zeggen ook niet alles
En wat ik nog jammerder vind, is dat het nu gaat om allemaal bijzaken en edge-cases in plaats van dat er een goed inhoudelijk debat plaatsvindt over wat we willen met situaties zoals bijvoorbeeld die 147km highway=primary zonder bicycle=no:
willen we die 147km reduceren tot 0 en overal een waarde voor bicycle aan hangen, zoals we ook met maxspeed proberen
of willen wie die 147 km juist vergroten door de bicycle=yes te verwijderen op de 9km waar die getagd is “omdat het default is” en het daarom weg moet (en idem voor andere wegtypen in de tabellen)
en als we dat laatste niet willen, hoe is er dan wel een bruikbaar voorstel te maken om te zorgen dat je geen zaken hoeft te taggen die in een land zonder uitzondering gelden voor bepaalde wegtypen (ik zie daar wel kansen)
Dat lijkt me een veel constructievere manier vooruit
Het probleem doet zich alleen voor bij highway values zonder impliciete beperkingen/toelatingen, zoals primary en path. Primary betekent niet autoweg, wel zijn auto’s impliciet toegestaan. Een kleine weg kan de functie van primary verbindingsweg hebben.
De NL veldsituatie regelt de bicycle en foot access met expliciete =no bebording voor categorieën weggebruikers, op wegen die niet als autowegen aangeduid zijn. Of af te leiden uit de aanwezigheid van verplichte fietspaden, mbv de bijbehorende borden. Geen borden: dan is het toegestaan, maar of het verstandig is en je dat wil doen als fietser/loper, dat is een ander verhaal. Dat komt overeen met de weging op secundaire kenmerken die de router geeft aan de wegen die in principe bereden/belopen mogen worden. Het is best slim van de router om het ontbreken van expliciete tags zwaar nadelig te vinden in de routing. Of dat in het buitenland ook werkt weet ik niet zeker; ik heb zat wegen gereden/gelopen waar ik in NL niet over zou peinzen, omdat ik anders een nog onaantrekkelijker optie moest gebruiken). En de wandelpaden die ik volg lopen geregeld over (IMO) snelwegen, die officieel toegankelijk zijn voor langzaam verkeer.
Stel je nu autoweg gelijk aan primary? Want een autoweg (weg waarop alleen motorvoertuigen voor boven de 50 intuur mogen), impliceert bicycle=no, foot=no en mofa=no, dus als je een highway value hebt voor autoweg, dan hoef je die no’s echt niet te taggen omdat het al inbegrepen is. De fietsrouter neemt de autoweg niet mee, dus hoeft hij niet naar bijkomende tags te kijken.
highway=primary impliceert die no’s niet. Dus primary’s die geen autoweg zijn, doen in de fietsrouting mee, en als er geen bijkomende access tags zijn gelden de meestgebruikte wereldwijde defaults, en die zijn yes. En daarnaast allerlei kenmerken die de weg aantrekkelijker of minder aantrekkelijk kunnen maken voor de fietsroute.
Dus om je vraag te beantwoorden: voor alle highway=primary in NL ja, tenzij ze tegelijk als echte autoweg getagd zijn (daar was een tag voor toch?).
Zeker niet, maar ik volg ook niet meer wanneer mensen het nog over autowegen hebben en wanneer het onderwerp ineens verandert naar highway=path of primary.
Nou je 't zegt… ik ben er ingetrapt!
Het onderwerp is foot=no op autowegen.
autoweg impliceert foot=no. Dat is de reden dat foot=no daarvan wegkan. Dat is geen kwestie van defaults: het is gewoon inbegrepen, net als dat foot=designated bij een highway=footway al inbegrepen is en dus wegkan.
Oké, cool. Dan hebben we, tenzij ik iets gemist heb, tot zover alleen Multimodaal die het er niet mee eens is dat foot=no op autowegen al impliciet is en daarmee weg kan.
Multimodaal is terecht bezorgd dat er vanwege een tabel tags verwijderd worden die een betekenis hebben. Maar voor impliciete gegevens geldt die hele tabel niet.
Dat is een prima idee. De tabel is mijns inziens ook bedoeld om dataconsumenten die het land niet kennen op weg te helpen, niet om data te verwijderen.
Het principe dat je een motor nodig hebt op een motorway (autosnelweg) of een road for motor vehicles (autoweg) overstijgt echter deze tabellen.
Eens en we zouden die tabel verder kunnen verrijken voor dataconsumenten door duidelijk te maken welke waarden in Nederland
zonder uitzondering gelden (omdat de verkeersregel die bepaalt dat voor x,y,z =no niet mag worden overschreven door borden die een uitzondering daarop maken, zoals bij motorway en trunk+motorway=yes (zie BABW)
bij welke waarden de wettelijke default uit de verkeersregel op de weg meestal wel wordt overschreven door een verkeersteken (bicycle=yes/no op primary / secondary etc ) , dus routing default kan beter afwijken van wettelijke default
bij welke waarden de wettelijke default wel een goede voorspeller is voor een nuttige routing0-default
Het principe dat je een motor nodig hebt op een motorway (autosnelweg) of een road for motor vehicles (autoweg) overstijgt echter deze tabellen.
Ook eens, maar de default access tagging werd in de start wel gegeven als legitimatie voor een mogelijke verwijdering, met ook vooruitzicht van uitbreiding naar andere wegtypen. Vandaar dat je dat argument eerst moet nagaan, en daar is dus geen consensus dat dit een reden is om data te verwijderen.
Bij motorroad=yes spelen zoals ik ook al schreef dus (ook) andere vragen en die moet je vervolgens op hun eigen waarde beoordelen. Het internationale beeld daarover lijkt wat minder eenduidig dan ik eerder dacht en hoopte, zie bijvoorbeeld hier en hier.
En als je correcte data verwijderd uit OSM dan moet je wel heel zeker zijn dat de voordelen daarvan groter zijn dan de nadelen.
foot=no op motorway wordt vreemd gevonden maar surface=asphalt op motorway is niet vreemd…
Maar nadenkend is dat ook wel logisch want hier in Nederland hebben we ook snelwegen met grind, zand & water oppervlakken, stom van me !
Als je aan je grind, water en zand wat cement toevoegt heb je gelijk. Snelwegen kunnen ook van beton zijn.
Verder hebben surface= en foot= niets met elkaar te maken, de eerste is een keuze, de tweede bij wet geregeld.
Bedankt voor de snelle reactie’s iemand nog snelle reactie’s op: Voorstel: Arearules ?
Want zou mijn inziens ook de oplossing kunnen zijn op ook dit ontwerp.
