Foot=no op autowegen

Hebben we het dan nog over een plein met een webverwijzing naar een gedragsregel over hoe je je fiets moet neerzetten? Of over een hiërarchie van alle mogelijke gebiedsgebonden aanwijzingen en regels? Of over een aan administratief niveau gebonden hierarchie van defaultwaarden van maxspeed tags? Of over gebieden die van alles kunnen zijn, waar je een lus overheen gooit en daar de gemeenschappelijk eigenschappen per objectklasse / value inzet?
Of alleen een gebied met een URL waar de data user de toepasselijke eigenschappen kan gaan zoeken?

Moet OSM dat als algemeen systeem gaan ondersteunen?

Je zou dit kunnen vragen in het bewuste andere draadje, maar het antwoord is: nee.
Wat het wel is: lees het andere draadje bottom up als je echt geïnteresseerd bent.

Het expliciet taggen van impliciete toegangsregels kun je eigenlijk alleen gaan doen als je alle categorieën tagt. Doe je dat niet dan ontstaat er een nieuwe onzekerheid: een extra tag als aanvulling op de impliciete regels doet immers vermoeden dat er sprake is van afwijkende regels voor die weg. Bij een ‘no’ waarde is dat ook duidelijk, bij een ‘yes’ waarde niet.

Gek genoeg zie ik die extra ‘yes’ tags hoofdzakelijk voor 2 categorieën verschijnen: foot en bicycle. Tags die ik de laatste tijd steeds meer op unclassified tegen kom, en dan nog vaak op een enkel segment van een weg. En daar dan kennelijk alleen maar staan voor een specifieke router. Want als je bicycle=yes toevoegt aan zo’n weg waarom dan niet motorvehicle=yes ? Het is niet consequent als je maar een beperkt aantal gebruikers op yes zet.

Nu is OSM geen volledig relationele database, maar je zou met impliciete toegangsregels het wel zo kunnen zien: aan ieder wegtype is een ‘record’ met toegangsregels gekoppeld. Dat maakt het gemakkelijk om bij een wijziging de regels aan te passen. Stel dat fat-bikes van het fietspad verbannen worden dan hoef je dat maar op 1 plaats te doen. Bij expliciete regels moet je dan alle fietspaden gaan aanpassen. Idem wanneer er een nieuwe vervoersvorm wordt bedacht.

Het is dus maar de vraag of dat expliciete taggen op termijn wel zo slim is.

Waarom zou je dat überhaupt willen?

Ik zou dat ook niet willen. Maar dit topic en de praktijk tonen dat het steeds gebruikelijker wordt. Zelf vind ik dat ook geen positieve ontwikkeling.

1 Like

Ik denk niet dat dat zo is, als het om de traditionele gebruikelijk categorieën voertuigen gaat en wegen gaat. Wel wordt alles steeds gedetailleerder, zodat er meer gemapt en getagd wordt.
Verder zijn er steeds meer aparte voertuigtypes, die wettelijk bij ons dan weer half-om-half bij bestaande voertuigtypes worden geschaard, wat in OSM alleen met expliciete tagging is op te lossen. Zowizo hebben we voor fietspaden uitzonderlijk veel aparte types met aparte regels voor verschillende voertuigtypes (daarvoor is dus geen impliciete access, en ook geen wereldwijde default access), waarop dan ook nog te hooi en te gras uitzonderingen gegooid worden door plaatselijke overheden).

Dus je komt het wel steeds vaker tegen, dat klopt, maar juist in de specialiteiten en de uitzonderingen, en juist dan denk ik dat je dat niet kan oplossen met een slim bedacht informatiemodel. Dat zou alleen werken als het algemeen ondersteund en toegepast wordt, en duidelijk genoeg is voor alle mappers. Zo niet, dan sterft het in schoonheid nog in het kraambed.

Ik denk dat we voor nu voluit moeten inzetten op

  1. OSM-brede impliciete tags (bv highway=cycleway houdt automatisch in bicycle=designated)
  2. OSM-brede world wide defaults (bv highway=path zonder verdere access tags reken je als foot=yes en bicycle=yes)

Als de world-wide defaults OSM-breed ondersteund worden, valt het verschil met impliciete tags trouwens weg. Je hoeft dan alleen de uitzonderingen te taggen, waaronder afwijkende landgebonden specialiteiten en defaults, en dingen waar geen wereldwijde impliciete tags en defaults voor zijn.

Vandaar voor fietsen ons hele pakket van mofa en moped, gevarieerd naar soorten cycleway die wereldwijd gewoon niet bekend of geregeld zijn.

Zo denkend vind ik dat het wel heel handig zou zijn om in de landelijke access default tabel in de access wiki, duidelijk aan te geven welke speciale defaults wij hebben die afwijken (of extra zijn) t.o.v. de wereldwijde access defaults. Je zou de waarden die overeenkomen groen kunnen maken, wat er apart bijkomt oranje (goeie kleurkeuze, al zeg ik het zelf) en wat echt anders is rood. Voor mofa hebben we dan een hele kolom rood, oftewel mofa moet je altijd expliciet taggen om osm-breed duidelijk te maken hoe het zit.

PS1 En altijd blijft het zaak: bij twijfel, expliciet taggen.
PS2 Expliciet taggen voor de workflow, om te markeren dat het echt bekeken is, vind ik geen goed idee. Omgekeerd kan een data user er niet op vertrouwen dat zo’n expliciete tag die gelijk is aan een impliciete tag of een wereldwijde default, de betekenis heeft dat het gecheckt is (op welke datum en is dat nog steeds zo?).

Dat speelt wel in meer landen, kijk eens naar het oosten.
De kern is eigenlijk dat de toepassing van OSM meer en meer van een kaart naar een database voor navigatie lijkt te gaan. Nou was er lang geleden zo’n regel ‘niet taggen voor de router’ maar dat is een beetje ondergesneeuwd geloof ik.

Of een wereldwijde osm-brede default gaat werken weet ik niet. Er zijn zoveel verschillen per land dat er waarschijnlijk erg weinig default overblijft. Met name omdat het ‘westelijk’ deel erg verschilt in infrastructuur als je kijkt naar het totale aantal wegen op de wereld.

PS1: ik kwam hier trouwens terecht omdat ik de laatste tijd veel NL wegen aantrof met bicycle/foot=yes waar dat al impliciet is toegestaan. Voordat ik ingewikkelde selectieregels ga bouwen voor mijn fietskaarten wou ik eerst eens kijken of dit nu gebruikelijk is of nog steeds een uitzondering.

PS2: sommige uitzonderingen zijn ook wel erg moeilijk te taggen: op een onverplicht fietspad moped:motor_off_pedalling=yes bijvoorbeeld :wink:

Maak je die speciaal voor Nederlanders, of voor iedereen in de wereld die wil zien hoe Nederland er voor fietsers uitziet?

Maw als er een tag ontbreekt, ga je dan een NL default invullen of een algemene landonafhankelijk default? Dat is de beslissing van de data user.
Als er wel een tag staat, dan heb je per definitie geen default waarde nodig, dus dat lijkt me geen probleem. Als-ie fout is, dan lost de data user het niet op, dan moet “de mapper” het oplossen.

TTH, taggen voor een specifieke router vind ik niet juist, maar taggen op een manier dat routers het gemakkelijk kunnen gebruiken vind ik juist noodzakelijk, niet bij alles maar wel als het om eigenschappen van wegen gaat.

Je mag toch het afgeleide van een C16
60px-Nederlands_verkeersbord_C16.svg
verkeersborden mappen in OSM met foot=no.

Wat als ze staan bij trunk, trunk_link met:
motorroad=yes met berekening afstand 15 meter



motorroad=no ,met berekening afstand 15 meter.

Die staan waarschijnlijk alleen maar bij de afritten i.c.m. een C2 (die niet voor voetgangers geldt), waarbij er bij de oprit een G1 of een G3 staat wat impliciet aangeeft dat voetgangers er verboden zijn. Aangezien de motorroad stopt bij de G2 en de G4 heeft het geen zin om op de motorroad foot=no te zetten.
Een heleboel primary’s, die overgaan in een motorroad, hebben vaak een C9. Toch verdwijnt de bycicle=no etc. als de primary overgaat in en motorroad.

Klopt, veelal.

Maar de insteek van dit topic is verwijdering.
Wat als ze getagd staan, mag je ze dan verwijderen.
C16 neergezet als informatief/verbiedend, gevolg mappen.

Mijn conclusie is dat je in zo’n situatie ze niet mag verwijderen bij een C16.
Dus ook niet automatisch.

Zo kan er volgende week weer een mapper zijn, die ziet het bord en zet de tag. Dat zal altijd zo blijven. Het mappen, dat is dan begrijpelijk.

2 Likes

Waar klopt dit niet dan?

En verder " The tag motorroad=yes is used to describe highways that have motorway-like traffic rules and access restrictions"

De acces restrictions zittenal in de tag motorroad en hoeven daarom niet nog een keer genoemd te worden.
highway=footway taggen we ook niet met foot=yes

1 Like

In principe render ik overlays voor kaarten voor eigen gebruik maar de basis daarvoor is de BTM die ik samen met PeeWee32 en Ligfietser lang geleden opgezet heb en door Ligfietser gehost/onderhouden wordt.
Tegenwoordig zijn er erg veel apps die het ook niet-mappers mogelijk maken informatie toe te voegen. Maar die apps zelf zijn dan weer opgezet met regels die de maker van die app heeft opgezet en dat is niet altijd hetzelfde als de regels die in communities per land zijn afgesproken.

Fouten mag ook een data-user in zijn hoedanigheid van mapper best oplossen. Neem bijvoorbeeld eens de tag bicycle=permissive. Die staat vaak op doorsteekjes waar je helemaal niet mag fietsen. Dat een hele buurt dat uit gemak wel doet maakt het nog niet waar. Die verwijder ik gewoon.