Verkeerstekens/-borden: verwijderen "needless" tags vaak onterecht

Langzaam verkeer is een populaire term voor verkeer dat niet van een autoweg en/of autosnelweg gebruik mag maken.[1] Het was tot 2001 een wettelijke term in Nederland en werd in de praktijk gelijkgesteld aan vervoermiddelen waarvoor een rijbewijs verplicht was.

Het ‘langzaam verkeer’ omvat de voetganger, de fiets, fiets met trapondersteuning, snorfiets, bromfiets, inclusief bredere varianten zoals een bakfiets, het gehandicaptenvoertuig, en de geleider/berijder van bijvoorbeeld een paard. Onder het langzaam verkeer vallen verder motorvoertuigen met een snelheidsbeperking, zoals landbouwvoertuigen. Langzaam verkeer haalt niet de zestig kilometer per uur die vereist is om van Nederlandse snelwegen gebruik te mogen maken.

https://nl.wikipedia.org/wiki/Langzaam_verkeer

Zo’n sloot moet toch uitgebaggerd worden …

Ik zie ook geen verbodsbord, en het komt uit op klinkerstraat. Als er een reden voor was om daar met de motor op te gaan zou ik dat gewoon doen, lijkt me niet verboden.

Nee, dat zijn twee verschillende wetten die naast elkaar staan:
de Wegenwet (1930) bepaalt welke wegen openbaar zijn, en dat is een weg niet bij voorbaat , daarvoor moet aan een aantal voorwaarden zijn voldaan. Access=yes als *wettelijke * default is dus niet correct -dat is permissive- , wellicht wel als praktische).

De Wegenverkeerswet (1994) bepaalt hoe je je hebt te gedragen op die openbare wegen.
Het RVV hangt als AMvB (lagere regelgeving dan een wet in formele zin) onder de Wegenverkeerswet.

Inderdaad is de Wegenwet van 1930 nog steeds geldig. Zie hier.
We zullen het eens lezen.

Inderdaad, echte fouten in de tagging bestaan natuurlijk ook (yes terwijl het no moet zijn etc.), net als situaties die ooit correct zijn getagd en daarna zijn gewijzigd, waardoor de tags niet meer kloppen. Maar dat is net iets anders. En het laatste is te ondervangen door als je ergens bent geweest en de tagging hebt gevreifieerd de key:survey_date te gebruiken https://wiki.openstreetmap.org/wiki/Key:survey:date

Zo krijg je in beeld wanneer iets voor het laatst is nagekeken en kan je als datagebruiker zelf je afweging maken hoe je de informatie weegt. Als mapper kan je hiermee kiezen om juist die paden te gaan bekijken die lang niet zijn gecontroleerd.

Dat werkt vele malen beter dan de laatste wijzigingsdatum: dat kan ook komen door het verslepen van een node door iemand die een bron zoals BGT gebruikt. En omgekeerd zie je zonder survey_date niet dat iemand onlangs nog ter plekke heeft geconstateerd dat de tags nog steeds correct zijn.

Ways zonder access-info moeten op zich zeker worden geaccepteerd, want anders wordt het lastig om een begin te maken en kunnen mensen daar niet op voortbouwen.

Waar ik alleen voor pleit is:
*1. besef dat als een pad geen access-tags heeft, dat die waarde in eerste instantie onbekend * is; je weet niet of de mapper in kwestie:
(a) niet wist hoe het zit, zoals met intekenen van luchtfoto of vanwege haast
(b) het wel wist, maar details over bijvoorbeeld wandelen op path of fietsen buiten cycleways niet de moeite van het invoeren waard vindt
(c) het wel weet en de moeite waard vindt, maar bewust niet invoert omdat de waarde overeenkomt met de waarde in een specifieke default-tabel, die geacht wordt een soort universele onzichtbare hand te zijn, die voor alle gebruikers en alle applicaties onzekerheden omtovert in zekerheden
(d) wel wist hoe het zat en heeft dat getagd, maar een andere (al dan niet armchair-)mapper dacht het beter te weten en heeft de access-tags verwijderd om “verwarrende situaties voorkomen”, vanuit een onwrikbaar geloof in de mysterieuze kenelijke universele default-tabellen

**2. Als gebruiker (en dataverwerker) kan je vervolgens zelf een keuze maken over de omgang met paden met ontbrekende access-tags die past bij jouw gebruiksdoel en randvoorwaarden, en het beeld van de situatie in het betreffende geval. **

Zo weet ik bijvoorbeeld uit ervaring dat paths over polderdijken zonder access-tags vaak feitelijk niet toegankelijk zijn, en alleen maar vanuit luchtfoto’s zijn ingetekend. Midden op de Veluwe heb je juist weer een grote kans dat het wel toegankelijk is (en een kleine kans dat het een rustgebied is).

Als ik alleen op pad ga, dan vind ik het doorgaans geen probleem om een route over paden zonder access-tags te plannen, vind het niet erg om terug te gaan en plan aan te passen, ik zoek vanuit het streven van verbeteren van de kaart juist die stukken op waar het onbekend is.

Maar als ik bijvoorbeeld een wandeling voor mijn ouders plan, dan zal ik voor een pad zonder access-tags (en waar geen wandelroute overheen loopt) toch eerder access=no als default gebruiken.

Met fietsen op paths (vind ik leuk) net zo: in Zuid-Holland kan je dat in het buitengebied (buiten mtb-routes) zonder access-tags wel vergeten, maar er zijn in het oosten wel gebieden waar je buiten de G11/G12a/G13 fietspaden mag fietsen, zoals de Kroondomeinen en sommige gemeentelijke bossen. Vaak wel weer met specifieke voorwaarden, meestal permissive, sunrise-sunset (geen probleem) en soms met datumvenster (jacht) of specifiek tijdsvenster (ochtend in Noord-Hollands Duinreservaat)

3. Als je je medegebruikers niet met al die bovenstaande onzekerheden wilt opzadelen: wees alsjeblieft expliciet in je tagging en stuur ze alleen het bos in als dat ook echt mag :slight_smile:
Je kan je medemens een groot plezier met tagging die
(a) volledig is : alle reguliere modaliteiten omvat
(b) consistent is: zo min mogelijk tegenstrijdigheden bevat die lastig te verwerken zijn, dus liever geen access=no + foot =yes, maar vehicle=no + foot=yes
(c) geen onnodige dubbelingen omvat: als je al vehicle=yes hebt, dan hoeft bicycle=yes niet nog een keer apart

Dat is juist geweldig werk en blijf dat alsjeblieft vooral doen!
Als je geen info beschikbaar hebt over de precieze access-tags, dan heeft de aanwezigheid van een wandelroute een sterke voorspellende waarde van toegankelijkheid.

Expliete tags zijn natuurlijk nog mooier, omdat je dan weet of het pad wel/niet het hele jaar toegankelijk is (foot=yes / permissive) of slechts een deel van het jaar (foot:conditional), en wat het regime is (openbaar of bij gedogen met extra regels), maar voor de mneste gevallen kan je hiermee wel een voorspelling maken die goed uitpakt. Mappers die vervolgens de route gaan lopen die jij hebt ingevoerd kunnen dan weer de bordjes kieken en de access-details aanvullen. Zo bouwen we voort op elkaars werk met een steeds betere kaart als resultaat.

Ik zie geen overwegende bezwaren in de praktische haalbaarheid van bovenstaande werkwijze. Problemen met de haalbaarheid lijken eerder te liggen bij de wil tot reflectie over bij sommigen over diepgewortelde, maar inhoudelijk nauwelijks onderbouwde overtuigingen. Om samen vooruit te komen om OSM de beste bron te maken voor fietsen en wandelen juist op die plekken die je niet in alle boekjes met routes en knooppunten vindt, is het ook het volgende nodig:

4. Verwijder geen data “omdat het default is”

5. Repareer data die je hebt verwijderd “omdat het default is”,
en dan niet alleen zodat het weer routeert in bepaalde routers (niet alleen access=no verwijderen ), maar zet ook alle informatie terug die je hebt gewist, zodat elke gebruiker weer zijn eigen afweging kan maken op basis van de informatie van de mapper

**6. Laten we alsjeblieft stoppen met andere mappers te vertellen dat ze iets niet hoeven taggen of niet moeten taggen *omdat * het default is. **
Als iemand *geen zin * heeft access expliciet te taggen, dan vind ik dat persoonlijk jammer maar het is je goed recht, niets is verplicht ( ik tag ook niet overal width etc.). Maar laten we de default-mythe die tot zoveel ontbrekende en verdwenen data leidt alsjeblieft niet blijven voeden.

Alleen zo kunnen we de nutteloze cyclus voorkomen waarbij
(a) mapper 1 terecht een pad intekent dat hij vanaf een luchtfoto, vanaf de fiets etc heeft gezien, zonder kennis van access-tags
(b) mapper 2 na survey foot=yes toevoegt op dit path
(c) mapper 3 dit vanuit de luie stoel (of na survey) weer verijdert (“omdat het default is”)
(d) mapper 4 op pad gaat om te kijken hoe het zit met dit pad zonder access-tags en foot=yes toevoegt
(e) mapper 3…

Het heeft een paar eeuwen geduurd, maar zelfs in de processie van Echternach doet men sinds enige tijd geen twee stappen meer terug, dat zou voor ons toch ook haalbaar moeten zijn? :slight_smile:

Dat is een duidelijke afspraak.

Maar hoe zit het nu met de motorfiets op een ‘path’.
Wat hebben hebben we afgesproken? Default NO en dus yes taggen als het wel mag, of anders om.

De Wegenwet van 1930 zegt:
Het bestaan van eene beperking in het gebruik, anders dan krachtens een wettelijk voorschrift tot regeling van het verkeer, mag mede worden aangenomen op grond van de gesteldheid van den weg en van het gebruik, dat van den weg pleegt gemaakt te worden.

Die redenering gaat om verschillende, zelfstandige, redenen mank:

**1. De relatie tussen OSM-highway-categorieën en RVV-wegcategorieën is vrij belabberd:
**Motorway en Trunk gaan nog wel (hoewel daar soms ook nog discussie in is), maar verder is dat bepaald niet 1-op-1 gekoppeld, zelfs niet bij footway (met de verschillende wiki’s in de hand zijn enerzijds paden in de privétuin van de koning als footway getagd en zou je anderzijds dit G7-pad van Staatsbosbeheer NIET als footway moeten taggen , omdat het niet openbaar is (criterium NL-wiki), maar bij gedogen (foot=permissive ipv yes)

-In OSM is cycleway 1 categorie, terwijl dat in het RVV 3 verschillende zijn (G11, G12a, G13) , met elk hun eigen gevolgen voor OSM-access-tags

**2. De kunsten van default slopers laten helaas zien dat je met JOSM en een overpass-query de database net zo snel hebt “verbeterd” als met de aanpassing van een default tabel
**

3. Vraagt aanpassing default tabel ook niet om aanpassing database bij default-denken?
-Neem het omgekeerde geval: iemand besluit die ene default-tabel in de wiki -die meent de *wettelijke * defaults weer te geven- feitelijk te verbeteren. Bijvoorbeeld door in de NL-tabel alle "yes"in “permissive” te veranderen bij path motorcycle -net als moped en mofa- ook toe te staan, ga je dan in de database alle *=permissive verwijderen “omdat dat default is geworden” en gaan worden dan ook de -zeldzame- tags verwijderd op path waarin expliciet werd gemaakt dat je er met een motorcycle mag komen? En wat worden we daar wijzer van ?

**4. In hoeverre er daadwerkelijk wijzigingen te verwachten die zich goed laten vertalen in verandering van defaults?
**-Welke wijzigingen zie je redelijkerwijs voor je die wel daadwerkelijk consequente gevolgen zouden hebben voor het OSM-schema ? Dat je met je speedpedelec op een highway=trunk mag?

-Voor zover er wel een fundamentele verandering te verwachten is, dan is de kans het grootst dat dat in de verschillende soorten voertuigen en de verschillende soorten fietspaden is, maar daar heb je dus niets aan alleen de OSM-classifactie van cycleway, daarvoor moet het traffic_sign goed zijn gemapt. Bovendien zie je die G13’s etc. niet in de bewierookte default-tabellen, dat gebeurt hoogstens in slimme aanvullingen in specialistische bronnen zoals in de OFM, maar dat zal zeker niet elke dataverwerker doen.

**5. Als verkeersregels veranderen, dan veranderen ook de borden in het veld en mogen wij als mappers hoe dan ook aan de bak **
-Het meest evidente punt, dat je misschien ook zelf had kunnen bedenken als je het eens van de andere kant probeert te bekijken, is dat uit de feitelijk doorgevoerde ervaringen met wijzigingen van de verkeersregels (zoals “Bromfiets op de Rijbaan”) blijkt dat dergelijke veranderingen ook gepaard gaan met veranderingen van de situatie in het veld veld (introductie G12a bord, bromfietsdoorsteekjes), waardoor je toch moet surveyen en opnieuw moet gaan mappen.

Ook in gevallen waar er met de nieuwe verkeersregel geen nieuw verkeersteken is geïntroduceerd, wordt ook vaak de bebording in het veld aangepast. Zie bijvoorbeeld invoering “voorrang fietsers van rechts” (lees: alle voertuigen van rechts) :
ook toen hebben wegbeheerders op veel plekken alsnog voorrangsborden geplaatst op situaties waar ze het verstandiger vonden om fieters geen voorrang te geven op ander verkeer van links. Dat is ook de rol van de wegbeheerder: met kennis van de lokale stand van zaken kijken waar de default-gevolgen van verkeersregels moeten wijken door het plaatsen van een verkeersteken

6. Het is een illusie dat er maar één defaulttabel is en dat die door iedereen wordt gebruikt, daar kan je dus geen tagging op baseren
En het voorbeeld van de verhoging van de maximumsnelheid op autosnelwegen illustreert ook gelijk dat het veronderstellen van één enkele defaulttabel voor alle gebruiksdoelen in OSM een heilloze illusie is, en al helemaal als die alleen is gebasserd op de juridische default ipv op een praktische:

-Toen de feitelijke juridische default in het RVV omhoog ging van 120 naar 130 km/u, betekende dat op de weg niet dat elk wegvak dat dat 120 was daarmee ook 130 werd: ook hier is verandering van de verkeersregel gepaard gegaan met verandering van de verkeerstekens in het veld

-Ook was de juridische default niet de feitelijk meest voorkomende waarde: in het merendeel van de gevallen was het niet maxspeed=130, maar iets anders (net als met path: dat is feitelijk ook maar in een minderheid bicycle=yes, laat staan moped=yes)

En maxspeed=130 taggen we -als je snelheden tagt- toch ook gewoon, ondanks dat dat in een OSM-default tabel staat en ook juridisch gezien hard is verbonden als default aan het OSM wegtype van motorway? Of zou jij die weg willen halen “omdat het default is” ?

Persoonlijk ben ik blij dat (a) mensen dat wel taggen (b) dat mijn navigatiesysteem het aangeeft als het niet weet wat de limiet is op een weg, en dus niet maar stoïcijns “130” weergeeft, ook al is dat de juridische default.

Als je zelf ook niet uit je doppen hebt gekeken naar de borden (of er zat een vrachtwagen voor), dan kan je zelf kiezen wat je doet. Ik zou 100 rijden (default=100) om niet het risico te lopen onbewust te hard te rijden, lager is niet nodig, want als het 80 zou zijn, dan is dat is dat echt niet te missen.

Ik kan me voorstellen dat het navigatiesysteem als default bij de reistijdberekening gebruik maakt van de meest voorkomende of gemiddelde waarde (default 115/120?) . En als een agent die in zo’n geval 100 rijdt, bepaalt of hij wel of niet met zwaailicht achter iemand aangaat die hem voorbijrijdt, dan kan het juist verstandig zijn om uit te gaan van de situatie dat de limiet wel eens 130 zou kunnen zijn, en iemand *niet * te hard (default=130).

Het is daarom niet gek dat je ziet dat er geen universele defaults zijn die door iedereen en elke applicatie worden gebruikt. Verwijzing naar de ene default tabel in de wiki is alleen al om die reden zinloos en contraproductief, nog los van de onzin die in die tabel staat.

[edit: kopjes]

Precies!
Daarom moet je als mapper bij het taggen helemaal geen acht slaan op wat er in een of andere router-default tabel staat, maar gewoon zo correct, volledig en consistent mogelijk de access-bepalingen taggen die volgen uit toepassing van de verkeersregels op de specifieke situatie die je in het veld aantreft.

Tja… dat is precies waar de meningen altijd weer verschillen: wat is gewoon; wat is correct; wat is volledig en consistent; en wat is correct, volledig en consistent genoeg.

Als mapper moet je je niet druk maken om defaults (dat is voor routers in de onfortuinlijke gevallen waar mappers geen expliciete informatie hebben gegeven) , maar geef je gewoon aan wie al wel en niet mogen komen, zo volledig, consistent en samenvattend mogelijk.

Dus op een path:

-dat openbaar is zonder beperkingen: access=yes
(routers voor auto’s mogen zelf bedenken of ze path bij voorbaat negeren, kijken naar een eventuele width-tag of het gewoon proberen, laatste zou ik doen als ik profiel voor Boswachters zou schrijven, kan uit eigen ervaring vertellen dat ze een heel eind komen…). En als het bij gedogen is (voor alle voertuigen opengesteld onder voorwaarden, anders art 461) , dan access=permissive

-op een openbaar pad waar wel voetgangers en fietsers, maar geen andere voertuigen mogen komen:
foot=yes
bicycle=yes
motor_vehicle=no
(motor_vehicle in OSM komt niet overeen met het NL-motorvoertuig, maar met motor*rijtuig * (art 1 WVW, dus inclusief moped en mofa)

Dat lijkt me ook een duidelijk uitgangspunt.

Allemaal aardige initiatieven, maar als je je voorstel goed leest moet je, bijvoorbeeld, op highway=motorway taggen:
motorcar=designated
motorcycle-designated
goods=designated
hgv=designated
psv=designated
moped=no
horse=no
foot=no
bicycle=no
mofa=no
ski=no
inline_skates=no
carriage=no
caravan=yes
trailer=yes
motorhome=yes
bus=yes,

en ik zal er nog wel een paar vergeten zijn.

Want dat default-access scheme is voor de kat zijn viool.

dus cats=NO :smiley:

Insgelijks, en ik zal ook mijn best doen ! (-:

Mooi dat je scenario’s schetst en de voors en tegens in beeld wil hebben.

Dat is naar mijn idee om verschillende redenen niet het geval. Ik zal ze langslopen, maar dat kost wel wat tekst.

Ik haal omdat het zo illustratief is toch maar het praktische voorbeeld erbij waarmee het punt van “verwarring voorkomen” door correcte informatie uit de database verwijderen begon:

Deze dwingende redenering is echter duidelijk op een aantal misvattingen is gebaseerd, waardoor je het niet als dwingende maatstaf voor het weglaten van correcte informatie gebruiken:

-de mogelijkheid dat een bord wordt geplaatst voor extra duidelijkheid (bijvoorbeeld omdat veel weggebruikers de regels niet goed kennen of ze graag selectief vergeten) wordt op voorhand buiten beschouwing gelaten, terwijl die mogelijkheid zelfs expliciet in de verkeersregels is opgenomen (RVV art 67, lid 1, onder a: onderbord kan naast beperking van werkingssfeer ook nadere uitleg van verkeersbord inhouden)

-belangrijker nog is dat hierboven ook niet wordt overwogen dat het ontbreken van een waarde in eerste instantie betekent dat de waarde **onbekend **is, en dat dat verschillende oorzaken kan hebben, met als een van de vele dat is geconstateerd dat de waarde samenhangt met die van een default in een bepaalde tabel

Erg goed dus dat je in je vragen uitgaat van iemand die wel beseft dat iets onbekend is, en dat het in werkelijkheid verschillende waarden kan hebben, dat maakt de discussie een stuk zinvoller.

Daar zit 'm al de eerste kneep: er is geen duidelijk gescheiden oude en nieuwe situatie: er zijn zowel beginnende mappers (vanwege sjabloon web-editors) als ervaren mappers die al lang en breed access expliciet taggen. Dat is ook conform werkwijze OSM, bij zo’n beetje elke highway=* in de wiki staat bij de eerste "Usefull combinations" genoemd: access=*

Wat je nu wel ziet -en dat vertekent het beeld van *“de huidige situatie”-, *is dat er een groep mappers is die anderen ontmoedigen om geen expliciete access-tags te plaatsen en die zulke tags zelfs actief -en in extreme gevallen met undiscussed mechanical edits- verwijderen uit de database. Je ziet nu dus minder expliciete tags dan er oorspronkelijk in zijn gezet.

Dit kan je denk ik niet los zien van het feit dat hier veel fietsers actief zijn (daarom is OSM ook zo geweldig goed voor algemene fiets-info), en veruit de meeste fietsers kunnen in de praktijk prima toe als de fietspaden alleen de tag highway=cycleway hebben (en mtb-routes in een relatie zitten), overige tags daarbij hebben voor de meeste gebruikers slechts marginale meerwaarde.

Voor wandelen is dat echter anders, net als voor fietsers die graag legaal buiten de reguliere fietspaden willen fietsen.

Ook dat weet je niet, er IS geen standaard normale toegang (sommige mensen veronderstellen dat ten onrechte) en het niet hebben van een tag kan verschillende redenen hebben, zoals de vier genoemd onder punt 1 in dit bericht, waaronder de mogelijkheid dat een pad is geïmporteerd of overgenomen van een luchtfoto zonder informatie (doe ik zelf ook vooruitlopend op survey om werk zinvol te kunnen plannen)

Die verwachting is ook nu heel sterk afhankelijk van (a) het gebied en de context (b) jouw specifieke kennis over die gebieden en context, zoals ook toegelicht onder punt 2 van dezelfde post. In sommige gebieden is de kans groot dat het foot=yes (meestal permissive…) is, i andere gebieden is het vaker foot=no. Dat kom je te weten uit ervaring en OSM is juist bedoeld om de kennis van lokale mappers beschikbaar te maken voor iedereneen.

Zo weet ik, door veel struinen en interesse in access, toevallig dat je in een gebied van Natuurmonumenten er echt niet op hoeft te rekenen dat je mag fietsen op een path, terwijl dat voor een ander weer veel minder vanzelfsprekend is. En in duingebieden weet ik toevallig dat er een enorme variëteit is in access voor voetgangers : van alleen maar op G7-paadjes tussen de hekjes, tot op alle paden, tot zelfs vrij struinen buiten de paden. Ook dat is voor een niet-local niet vanzelfsprekend.

Nog complexer wordt het al het verwijderen van expliciete tags onder het mom van defaults; als ik een path zonder access-tags zie buiten Limburg, met als laatste mapper Martin, dan zou je kunnen redeneren dat de kans dat het eigenlijk foot=yes *bovengemiddeld *groot is, omdat het pad juist vanwege de oorspronkelijke aanwezigheid van die tag is gewijzigd…

Er spelen dus allerlei onzekerheden op een complexe manier door elkaar, er is nu niet een zekerheid bij het ontbreken van de tag, alleen een inschatting van de feitelijke toegankelijkheid die van persoon tot persoon en van situatie tot situatie verschillend zal zijn.

Nee, het is net omgekeerd: hoe vaker er expliciet wordt getagd, hoe minder vaak je je überhaupt onzekerheid hebt over de vraag of een mapper nou wel of niet heeft geconstateerd of je daar nou wel of niet mag lopen.

Onzekerheid over de toegang bij afwezigheid van een foot=* is er sowieso al, ook in de situatie waarin alle foot=yes door weglaten/verwijderen vanwege “default” op een hoop worden gegooid met onbekende situaties.

Wel is het zo dat er door de nu veel voorkomende selectieve manier van taggen (wel “no”, maar niet “yes” taggen) het aandeel paths zonder foot=* dat *feitelijk toegankelijk *is, hoger dan het aandeel paden feitelijk toegankelijke paden in ons land. Dat geeft echter geen zekerheid, maar een vertekende kans, waardoor je zelfs met goede lokale kennis geen behoorlijke inschatting meer kan maken.

Bovendien is het zo dat door het wegnemen van de onzekerheid op het ene path (yes of no taggen afhankelijk van situatie in het veld), de verhouding van yes/no binnen de resterende paden in beginsel NIET zal veranderen: die zijn onafhankelijk van elkaar.

Het is dus geen Russisch roulette; daarbij wordt bij elke keer overhalen van de trekker -zonder daarna de cilinder spinnen- de kans op een “hit” bij de volgende keer groter : van 1/6e naar 1/5e naar 1/4e etc. Het is meer als dobbelen : op zich is het gooien van 5 zessen achter elkaar minder waarschijnlijk dan 4 zessen achter elkaar, maar de kans op een zes is bij de 5e worp op zich net zo groot als dat ie bij de 4e worp was.

Juist als mensen blijven doorgaan met selectief taggen (wel "no, maar niet “yes”) of zelfs selectief slopen, dan zal de verhouding van feitelijk wel/niet toegankelijke paden binnen de groep “geen foot=*” gaan veranderen en steeds meer afwijken van de werkelijke verhouding van wel/niet toegankelijke paden.

De toenemende onzekerheid van doorgaan met selectief taggen op basis van defaults wordt het meest duidelijk als je de theoretische en *verder ideale situatie probeert voor te stellen waarin alle paden zijn gecheckt, correct getagd (alleen dus zonder foot=yes…) en actueel zijn.
In dat geval zijn er nog steeds paden met oa foot=no, foot=permissive en zonder foot=

Als gebruiker heb je echter geen overzicht over de vraag of alles gechekt en actueel is (anders had je geen OSM nodig…) en resteert er nog nog steeds een onzekerheid of je ergens nu wel of niet mag lopen, het ontbreken van foot=* nog steeds twee verschillende dingen kan betekenen: (a) het is onbekend, dus yes of no of (b) we hebben foot weggelaten omdat het yes is…

Het verschil met nu is dat in deze ideale situatie -met resterende onzekerheid vooraf- in het veld steeds zal blijken dat je toch op het pad mag lopen, terwijl je nu dus regelmatig op verbodsbord of hek ofstuit op een path zonder foot=*
Maar het voorspellend vermogen van de kaart is veel minder toegenomen dan in de situatie dat *foot=yes *gewoon als *foot=yes *zou zijn getagd.

Als de betreffende wandelaar eerst minder twijfel voelde, dan was dat een erg vals gevoel van zekerheid, ook omdat deze voorbij zou gaan een het andere type fout dat ook voorkomt bij onzekerheid: niet alleen vals negatieven, maar ook vals positieven
https://en.wikipedia.org/wiki/Type_I_and_type_II_errors

En juist bij selectieve default-tagging werk je vals positieven in de hand waarmee je in het veld onverwachts tegen verboden oploopt als je moet vertrouwen op paths zonder foot=*

En dat soort fouten (aangenomen =yes, feitelijk =no) is voor de meeste mensen veel storender dan dat je een pad vanwege onzekerheid over de toegang -onterecht- links laat liggen bij het plannen van je route (aangenomen =no, feitelijk =yes). Bij een onverwachts verbod moet je terug of omlopen, en daar heb je niet voor gekozen. Als je kiest om een pad links te laten liggen vanwege onzekerheid, dan weet je in ieder geval dat jouw alternatieve omweg een grotere kans heeft op succes, en misschien heb je mazzel en blijkt de doorsteek zonder foot=* toch toegankelijk als je er onderweg toch langs komt.

En het zijn juist de vals positieven (een onverwachts verbodsbord of hek) die mensen doen twijfelen aan de kwaliteit van een kaart.

Zoals aangegeven leidt meer expliciete tagging naar mijn mening niet tot nadelen met betrekking tot onzekerheid, verwarring of minder vertrouwen in OSM, integendeel.

Ja, dat is het nadeel van al dan niet eerder toegepaste “default-tagging”: je weet het niet…
En je kan dan zeggen dat dat simpel is opgelost door dan maar iets aan te nemen, maar dat neemt de onzekerheid niet weg.
Dus als je hecht aan het verbeteren van de databse, dan stond zo’n pad toch al op de lijst voor een survey, los van de vraag of veel andere mensen nu ook interesse krijgen in expliciete tagging.

Ik zie, ook gelet op het bovenstaande, niet direct in hoe dat noodzakelijkerwijs volgt uit het meer toepassen van expliciete tags.
Het hele idee van expliciet taggen is juist om het in te vullen als je het echt weet, aangezien een lege waarde betekent dat je het niet weet. Het ten onrechte invullen van foot=yes is in strijd met bestaande taggingafspraken en zal ook snel genoeg worden opgemerkt door de eerste gebruiker die stuit op een verbodsbord op een pad dat door zo’n fictieve snodaard op foot=yes is gezet.

Bedoelde je je mijn onderstaande voorstel?
Kan je me uitleggen hoe je, met je -naar eigen zeggen- sterke gevoel voor logica, tot die conclusie komt ?

Welk?

deze:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

Stel ik ben een router-algoritme en mij wordt opgedragen een fietser van A naar B te brengen.

Ik ga nog even niet uit van verfijningen als vermijd onverharde wegen en veerponten.

Als mijn opdracht is: de snelste route, die voor fietsers meestal ook de kortste route betekent, dan zal ik de fietser van A naar B over de kortste route leiden.

Hierbij gaat de router uit van impliciete access-rechten en vermijdt autosnelwegen en footways.

De router maakt geen onderscheid tussen een path en een unclassified en ook niet als daar bicycle=yes op staat. Pas als er bicycle=no op staat zal hij die highway vermijden. Het ontbreken van de expliciete bicycle=yes maakt voor de routeerder dus niet uit. M.a.w. additive tagging (default +) geeft de router geen informatie en het algoritme is niet geschreven om sympathiepunten te geven voor de additionele default ±tagging die uit bevestigingen uit het veld komen. Je krijgt als mapper wel credits als je op default access een uitzondering tagt als bicycle=no of oneway op een path of unclassified. Daar heeft de router wat aan!

Die default accessrechten zitten in de router-algoritmes ingebakken, land-afhankelijk.

Het wordt pas interessant als een wat geavanceerder router je de keuze geeft voor een gladde snelle (racefiets) route of een uitdagende ATB-route.

Dan zijn tags die het oppervlak, de smoothness en de helling beschrijven van belang en die stijgen uit boven yes/no.

Dus de uit het noeste veldwerk voortvloeiende bevestiging van default access geeft uitsluitend de informatie dat de default bevestigd is. In zekere zin meerwaarde, maar voor de routeerder niet relevant.

Als op een path foot=yes staat of access=yes dan is het aan geeneen mapper om die tags zonder veldwerk te verwijderen en er foot=no van te maken. Net zo min als hij foot=no aan een path mag toevoegen zonder veldwerk, waar de tags foot=access=yes ontbreken. (hij hoeft trouwens ook niet foot=no aan een motorway toe te voegen…)

Ik snap dat veldverificatie toegevoegde waarde heeft, maar niet voor de routeerder of de gebruiker die de kaart raadpleegt.

De suggestie - door enigen in dit topic geuit - dat we de default toegestaande access-categorieën expliciet naar bevinden zouden moeten toevoegen aan dus alle highways acht ik onnodig, ik zou bijna zeggen *needless *werk.

Ik laat het meeste maar even liggen, het wordt me te vermoeiend. Maar deze toch even: Je stelt een hele handeling met servers en queries plus foutenrisico gelijk aan het typen van 1 regel in een script? En je beseft dat je zo’n querie ook nog moet kunnen reverten, wat iets meer werk is dan ‘#’ in het script typen.

Voor de rest: wat Martin schrijft.

Dit is een grote misvatting.

Dus als er geen bicycle=yes op een unclassified staat dan routeert hij niet?

Dan is het een bijzonder slechte router - moeten we daar ook voor gaan taggen?