Bicycle:No fout

Twee zomers geleden stonden bij een buurtfeest borden met de tekst “verboden voor fietsen”.
Ik vroeg de security of het bord juist was of dat ze misschien bedoelden : “verboden voor fietsers”.
De security vertelde dat ik beslist met de fiets aan de hand het terrein over mocht. Dat betekent dus dat de tekst op de borden fout was.
Dat is waar het ook hier over gaat. Nu een manier vinden om dat in OSM te verwerken :wink:

edit: nu ik er over nadenk; ik denk dat de borden juist waren en dat de security het fout had.

Bicycle yes, no of dismount?

Ringvaartpad, Haarlem :smiley:

mount_mower of mount_harvester natuurlijk :smiley:

Ik kwam ook eens wat vroeger in het seizoen, als de brandnetel welig tiert, aan het begin van het pad een dame in korte broek tegen, die me vroeg of het pad befietsbaar was, haar routeplanner beweerde van wel…

Pieter…Zeker iemand bicycle=dismount getagd. :slight_smile:

Ik zie het probleem even niet.
Een wandelpad in een natuurgebied begint met access=no. Dan volgt een foot=yes.
Zet je op een pad alleen bicycle=no dan verbied je alleen fietsen. Paarden en alle andere ongemotoriseerde voertuigen mogen er dan nog steeds op. Dat is een situatie die in de praktijk nauwelijks voorkomt, dus path met bicycle=no in een natuurgebied zou erg zeldzaam moeten zijn.

Dan is er de vraag: hoeveel fietsers zullen in de praktijk in een bos of natuurgebied gaan wandelen met hun fiets aan de hand ?
Is het daarvoor nodig de tagging om te gooien ?

Zie mijn post #6 waar ik een praktijksituatie aangeef waar een wandelaar met de fiets aan de hand ‘wandelt’ in een natuurgebied :slight_smile:
Ik geef ogenblikkelijk toe dat dit een dergelijk specifieke situatie is dat we daar niet voor moeten taggen.

Maar: in plaats van te starten met access=no en dan x=yes toevoegen voor de categorieën die wel op het pad mogen? Waarom niet hw=path taggen en bicycle|horse=no, of hw=footway?

vehicle=no Dan ben je van alle voertuigen af dat werkt gewoon. Starters geef ik altijd het advies om nooit met access=no te beginnen, want dan wordt de lijst met uitzonderingen die je moet gaan bijtaggen erg lang. ( elephant=yes :slight_smile: )

Vanwege de defaults :wink:
Path is voor alle niet gemotoriseerde vormen van vervoer. Als in een bos alleen wandelaars zijn toegestaan is access=no met foot=yes accurater dan bicycle|horse=no. De laatste tagging laat andere voertuigen open.

@Eggie
Grappig. Precies om dezelfde reden hanteer ik in een bos dus access=no. Dan hoef je alleen de toegestane toegang te taggen. Anders moet je ook elephant=no er op zetten … :smiley:

(Horse=no is trouwens een beetje onduidelijke tag: als je de wiki leest gaat het om bereden paarden. En niet om aangespannen paarden. Die onduidelijkheid is er ook bij het NL bord, want dat bord bestaat officieel niet , zie deze eens: https://www.omroepgelderland.nl/nieuws/2136142/Bijna-niemand-weet-wat-deze-borden-betekenen .

Vlak bij mij is er een pad afgesloten met een onderbord waar daarom alle varianten zijn vermeld: paard, vee, bereden, aangespannen, begeleid. Landbouwvoertuigen met bestemming mogen daar dan wel weer in. )

Nog even terug naar een verbod op de aanwezigheid van de (brom)fiets zelf.
Hoe moet men dat dan doen voor een winkelstraat, die buiten winkeluren wel open staat voor (brom)fietsers?

En geeft vehicle=no niet tevens een verbod op de scootmobiel en de rolstoel?

In ons land zijn die uitgezonderd van dat verbod.

Eens!

Er zitten meerdere nadelen aan de methode access=no + xx =yes op een pad in een natuurgebied dat onder voorwaarden geopend is voor het algemene publiek

  1. Het past niet goed binnen de definitie van access=no in de voornaamste wiki’s
  1. Het is voor eindgebruikers onduidelijk welke groepen de mapper allemaal beoogt uit te sluiten:
    betekent accesss=no + foot =yes ook dog=no, of heeft de mapper daarover niets geconstateert (zoals de meeste mappers dog=* niet taggen)? Zie ook de duizenden cycleways zonder tag voor mofa, idem bij use_sidepath.

  2. Het leidt tot tagging die intern tegenstrijdig is: tegelijk een yes voor overlappende groepen die de datagebruiker maar weer moet zien te interpreteren. Dat is lastiger dan tagging die niet tegenstrijdig is

Je ziet ook in de praktijk ook dat door bovenstaande punten datagebruikers door access=no-tagging in de knel komen en zaken ten onrechte op slot zetten.

Zie dit dit voorbeeld


highway=footway
access=no
access:conditional=permissive @ (sunrise-sunset)

-*access=no *zet de default die de datagebruiker hanteert op een footway (ongetwijfeld foot=yes :)) buiten werking

-De access:conditional beoogt daarna voor bepaalde gevallen wel weer toegang te geven, alleen zulke waarden worden door slechts weinig dataverwerkers gebruikt / herkend (best complex met locatie datum / tijdstip zonsondergang)

Het resultaat: alleen de getagde algemene access=no wordt verwerkt, de default van de datagebruiker is buiten werking gezet en het pad is op slot voor iedereen. Het pad wordt vermeden door routers en gerenderd als verboden toegang:

OSM.org / Graphopper -Te voet
Brouter Hiking
Rendering Standard Carto

En dat terwijl de hier gebruikte tagging eigenlijk zelfs meer groepen toelaat dan je verwacht op een footway (overdag zouden *alle modaliteiten *permissive toegang hebben, niet alleen foot).

Het werkt dus inderdaad beter om expliciet aan te geven wat wel mag en wat niet mag, zoveel mogelijk samengevat (dus vehicle=* en niet bicycle=+moped=+…), maar zolang het kan zonder tegenstrijdigheden in de tags.

Bij de categorieën waarvoor geen tag is opgenomen (of bij tags die niet worden begrepen, zoals de conditionals bij veel gebruikers ) kan elke dataverwerker op basis van zijn eigen defaults bepalen wat daarmee gebeurt. Daar zijn ze heel handig voor :slight_smile:

Als ik je goed begrijp,.moet je dus een conditional op een footway aangeven met foot:conditional en niet met access:conditional. Right? Dit is voor mij nogal een worstelpuntje.
En dan consequent bij bicycle toegestaan op dat voetpad, ook bicycle:conditional

Precies wat ik doe dus. Niks mis mee. Op zo’n bordje van de boseigenaar staat ook 'verboden toegang ( access=no ) met uitgezonderd xx ( xx=yes ) .


highway=footway
access=no
access:conditional=permissive @ (sunrise-sunset)

kan gewoon aangepast:


highway=footway
access:foot:conditional=yes @ (sunrise-sunset) ( hier met volledige specificatie voor het gemak )

Als routers de access:conditional niet verwerken is dat hun probleem, niet van de mapper. Punt is immers dat de router met footway en conditional anders ook de fout in gaat als het nacht is. Het probleem blijft dus nog steeds bestaan.
Dat heb je nu ook met vrijwel alle routers voor fietsen die me over een pontje willen sturen met opening_hours of conditional terwijl in december het pontje is afgesloten.

Ik heb het al eerder gezegd: als je voor de methode van expliciete toegang kiest kan en mag dat: maar dan moet je dat consequent op alle wegen en voor alle vervoersmethoden doen. Dat moet dan binnen de internationale gemeenschap gedragen worden, dus maak een proposal ervoor en zie hoe de stemming uitpakt.

Nu krijg je dit soort halfbakken oplossingen:


highway=path
foot=yes

Maar is het nu wel of niet verboden voor andere gebruikers? Je zou denken van wel, anders hoef je er geen expliciete foot=yes op te zetten immers. Maar paarden en ongemotoriseerde voertuigen en anderen mogen ook op een path. Dus dan moet je volledig taggen:


highway=path
foot=yes/no
vehicle=yes/no
horse=yes/no
cattle=yes/no ( want mag ook niet met vee in bossen )
etc

Die hele lijst kort je lekker af met


highway=path
access=no
foot=yes

Wil je dat aanvullen met dog=yes, prima. Maar doe dan pet=yes want ik wil met mijn kat of geit ook wandelen :wink:
En meteen dog_leash=yes want die loslopende honden zijn een doorn in veel ogen.

Enkel x=yes op een path zetten omdat je graag wil dat een router er overheen gaat is echt een halfbakken oplossing die vanuit het oogpunt van consquent taggen een crime is.

wat dacht je van:
highway=path
access=yes@ sunrise-sunset (liever niet no@)
foot=yes
bicycle=dismount
motor_vehicle=no
rest=unknown
:laughing:

Als je de conditional niet alleen negatief wilt mappen (no @ sunset-sunrise), maar de inverse daarvan ook positief per modaliteit, dan wel inderdaad :slight_smile:

En het is helaas inderdaad ingewikkeld, waardoor er snel dingen onbedoeld misgaan, verkeerd worden geïnterpreteerd of een verschil van benadering opleveren.

Het access-schema van OSM is helaas ingewikkeld, vooral omdat er meerdere variabelen in een enkele key zijn gepropt:
(1) mag het algemene publiek hier wel/niet komen met een bepaald vervoersmiddel?
(2) wat is de wettelijke grondslag voor een eventuele toegang (yes=openbaar / permissive = bij gedogen)
(3) is de toegang voor een specifieke modaliteit impliciet (bij ontbreken van bord voor die categorie, of mofa op G11) of met expliciete borden voor die modaliteit aangegeven (designated, afhankelijk van je interpretatie van deze key…)
(4) is de toegang onvoorwaardelijk of voorwaardelijk (xx:conditional :slight_smile:

Het had heel veel gedoe en discussie gescheeld als elk van die variabelen netjes in een eigen key had gezeten, dan zaten ze elkaar niet in de weg.

Als we nu bijvoorbeeld *=designated invullen, dan ontnemen we -omdat we op access maar 1 value invullen- daarmee ook het zicht op de grondslag van de toegang : ‘yes’ (openbaar) of ‘permissive’ (bij gedogen).
Dit allebei de opties mogelijk zijn: ook op niet-openbare wegen worden RVV-borden geplaatst (soms zelf RVV-bord met daaronder ‘Eigen weg’).

De sluiting van paden in het buitengebied tussen zonsondergang is dusdanig algemeen (en de praktische gevolgen daarvan vaak beperkt), dat je op een afweging komt of je die eigenlijk wel in de bicycle:conditional moet zetten, als ook bekend -en praktisch onvermijdelijk- is dat de meeste datagebruikers daarmee niet overweg kunnen. Dit terwijl een waarde als bicycle=permissive wel algemeen wordt begrepen en kan worden verwerkt en eigenlijk al heel veel informatie geeft over bijvoorbeeld een highway=path.

Je moet dus een keuze maken.

Zelf kies ik (uit pragmatisme) ervoor om vanwege de begrijpelijkheid sluiting in de avonduren alleen te zetten in de algemene *access:conditional= no @ … * en de bicycle= *positief te taggen met bijvoorbeeld bicycle=permissive.
Maar eigenlijk laat dat dan wel de vraag open hoe het zit met specfiek *fietsen *na zonsondergang…

Ik vind persoonlijk de grotere kans op goede verwerking van de 99% van de gevallen overdag belangrijker dan de beperkte toegevoegde waarde van de sluiting in de avond, zeker omdat die toch ook al *-in algemene zin- *is af te leiden uit de access:contitional = no @ .

Een seizoenssluiting van een pad zet ik dan wel weer in de foot:conditional en bicycle:conditonal, dan is er echt iets bijzonders aan de hand. Dat is misschien niet helemaal consequent, maar werkt wel.

Zoals dvdhoven al zei, moet dit niet gewoon foot:conditional zijn? Je gebruikt toch ook geen access:foot=yes?

Waarbij ‘permissive’ nog een probleem op zich is: ik ken maar weinig wegen waar dat echt toepasselijk is.
Dus waar access=no zou moeten zijn omdat dat op de borden van een privé-weg staat. Maar de boer
heeft dat er alleen neergezet vanweg overlast gevende idioten om een wettelijke grondslag te hebben.
Als je je normaal gedraagt spreekt ie je er niet op aan.
Wat zelfs de vraag oproept of je dat eigenlijk wel moet taggen … meestal is het resultaat dat lokale bewoners
er gebruik van maken en ‘vreemdelingen’ niet durven. Precies wat de boer wou!

De wiki geeft als algemene syntax


<restriction-type>[:<transportation mode>][:<direction>]:conditional = <restriction-value> @ <condition>[;<restriction-value> @ <condition>]

Tegelijk staat er ook dat vaak restriction-type wordt weggelaten. Beide zijn dus goed. Ik zelf gebruik liever de volledige syntax bij conditional.

Doorgaans is dat op basis van artikel 461 WvS, en dat is -in termen van de algemene key:access private (grondeigenaar geeft als rechthebbende aan dat je zijn grond niet mag betreden), en niet access=no (op basis van aparte, strengere regelgeving, zoals bij militaire installaties of waterstaatswerken):

Zie de Wiki van de algemene -en niet voertuigspecifieke-ag access=no :

Dat vindt ik wat te kort door de bocht. We moeten zeker geen foute data invoeren omdat het goed rendert of routeert, maar het moet wel op zo’n manier zijn dat het ook redelijkerwijs goed verwerkt kan worden.
Als vanwege het inkorten van de tagging met een paar tags opeens alle verwerkers tabellen moeten gaan gebruiken met zonsondergang per locatie en jou ook om een datum van je reis moeten gaan vragen, dan zijn we niet heel goed bezig.
Het is een interactie tussen mapper en datagebruiker waarbij we een werkbare middenoplossing moeten zien te vinden, gelet op de mogelijkheden en onmogelijkheden.
We taggen immers ook in machine-readable tags om verwerking mogelijk te maken, en niet in vrije tekst zoals op de bordjes staat.

Waarom alles toch steeds zo in het extreme trekken?
En als je ziet naar wat er nu feitelijk aan geaccepteerde tagging wordt voorgesteld, dan blijkt dat juist de methode met de tegenstrijdige tagging (access=no; *=yes) te worden afgeraden in de access-wiki:

En ook in de praktische voorbeelden van tagging in de wiki zie je steeds *wel *de consistente specifieke tagging per modaliteit en niet de door jou voorgestelde intern tegenstrijdige tagging met access=no en xx=yes (of omgekeerd) :

Highway tagging samples/out of town

Geen proposal nodig dus voor dergelijke expliciete en consistente tagging.
Tegenstrijdige tagging met access=no + xx=yes is dan weer niet breed gedragen in de wiki’s.

En ja, er zijn altijd modaliteiten te bedenken die erbuiten vallen, maar dat is in de praktijk eigenlijk nooit een probleem: ik heb weinig verbodsborden voor olifanten gezien in de bossen en ze zijn in OSM ook nog niet zo relevant dat ze het tot de access-categorieën hebben geschopt. En in het bijzondere geval dat er wel iets staat vermeld op een bordje over een obscure vorm van verkeersdeelname, dan tag je dat gewoon :slight_smile: