Bevoorradingsverkeer.

Hoe zou deze conditional dan moeten zijn? Als “gewone” doorrijdende fietser mag ik er ook komen tijdens bevoorradingstijden, maar de conditional overruled de bicycle=yes

Is het niet gewoon:
access:conditional=delivery @ …
foot=designated
bicycle=yes

Fietsen toegestaan heeft een tijdsbeperking dus een conditional, bicycle=yes is verkeerd (tenzij je een andere vertaal methodiek toepast, geen yes maar no voor conditional) discussie werking, zie onderstaande post AndriesWijma

Meer gewenst is de regels op het bord zo direct mogelijk te vertalen, geen omkeer constructie toe te passen, wat het vaak onbegrijpelijker maakt.

niet op zaterdag van 8-16h

bicycle:conditional=yes @ (Mo-Fr 00:00-24:00;Sa 00:00-08:00,16:00-24:00;Su 00:00-24:00)

ofwel

bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su)

Wat een access:conditional overrulled.

en

bevoorradingsverkeer heeft op zaterdag van 03.30-19.00 de mogelijkheid, maar bicycle heeft dan van 08:00-16:00 geen toegang en staat voor dat tijdslot niet op yes:conditional maar kan wel gebruik maken van bevoorrading, delivery.
daarom wegens overulling, het fietstijdslot delivery te openen
bicycle:conditional=delivery @ (Sa 08:00-16:00)

Er kan maar 1 key bicycle:conditional op een way staan, het bovenstaande moet dan worden samengevoegd.

bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su);delivery @ (Sa 08:00-16:00)

Dit wat betreft de bicycle, als de fiets gerekend mag worden tot bevoorradingsverkeer.
Dat is de cruciale vraag.

Het gaat om een wiki voorbeeld.

Dan moet het wel kloppen.

Het wiki voorbeeld heeft meer van regel voor regel vertaling methodiek, zonder te kijken naar de overulling gevolgen. Niet rekening houden met de Evaluation of conflicting restrictions.
Of toch wel een beetje, het omdraaien van, in,

bicycle=yes
bicycle:conditional=no @ (Sa 08:00-16:00)

Wat voor delivery dan verkeerd uit pakt.
Ook kijkend naar de moped=no mofa=no regels.

Je constateert iets wat een vraag opwerpt en ondertussen komen meerdere zaken naar voren …het blijft niet bij 1 punt.

Ik begrijp dat fietsen altijd mag – bicycle=yes; overruled access:conditional = delivery @ (…) (want bicycle is specifieker dan access) – behalve zaterdag 8-16u, dan alleen bevoorradingsverkeer – bicycle:conditional=delivery @ (Sa 08:00-16:00), overruled bicycle=yes tijdens die tijd.

Maar misschien begrijp ik het verkeerd. Conditional access blijft ingewikkeld.

Bicycle:conditional overruled bicycle=yes als toegangsinfo voor bicycle.
De inhoud wordt niet met elkaar verrekend. Bicycle=yes wordt dus volledig overschreven.
Bicycle:conditional=delivery @ (Sa 08:00-16:00) zegt dan: voor fietsers alleen toegang als bevoorrader op zaterdag tussen 8 en 16 uur.
En dat maakt het vrijwel tot een bicycle=no.

Vandaar dat in dit geval alle toegangsinfo over fietsers in de bicycle:conditional moet, zoals Allroads liet zien.
Behoud van bicycle=yes kan wel van nut voor programma’s die zulke conditionals niet goed kunnen interpreteren en via de basistag in elk geval de meest geldende toegangswaarde kunnen verkrijgen.

Is dit echt zo? (niet dat ik je niet geloof hoor) Dan lijkt me dat het probleem wat aangepakt moet worden.
Voor maxspeed werkt maxspeed=130, maxspeed:conditional=100 @ (6:00-19:00) toch ook? De conditional vormt toch juist de aanvulling op de ‘unconditional’ tag.

Toevoeging: Wat ik dus probeer te zeggen; het lijkt er nu op alsof wij ons in allerlei bochten proberen te wringen om dit soort restricties goed te laten werken, terwijl het probleem volgens mij ligt bij het interpreteren van de tags. Lijkt mij dus dat dat aangepast moet worden, ook al is dat waarschijnlijk geen makkelijk opgave.

Er lijkt wat verwarring te ontstaan. Voor de duidelijkheid:


bicycle=yes
bicycle:conditional=delivery @ (Sa 08:00-16:00)

De conditional is alleen van toepassing op de genoemde tijden, daarbuiten valt hij terug op bicycle=yes.


bicycle=yes
access:conditional=delivery @ (Sa 08:00-16:00)

Fietsen mag altijd. De reden hiervoor is dat specifiekere tags uit de access-boom boven conditionals op generieke tags uit die boom gaan.

Zie ook dit vergelijkbare voorbeeld uit de wiki:


highway=tertiary
motor_vehicle=no
motor_vehicle:conditional=yes @ (18:30-07:30)
psv=yes 

De bus mag er dus altijd langs.

(Deze regel is regel 1 uit het stukje Evaluation of conflicting restrictions.)

Zoals Jeroen begrijp ik de syntax van access:conditional dus ook.
Maar één ding moge duidelijk zijn: als we hier met een stelletje ervaren mapper’s over een access-waarde twijfelen, dan is het voor beginners helemaal niet te doen. Dus die documentatie moet duidelijker.

Duidelijk… ik heb een denkfout gemaakt en trek de beweringen van mijn vorige bericht in.
Zo word ik ook weer geconfronteerd met de valkuilen als het gaat om interpreteren van conditionals.
Gelukkig zijn er altijd mappers die scherp genoeg zijn om het meteen op te merken.

Niet voor iedereen, voor mij is dan de vraag is dat een goed uitgangspunt.
Ook omdat highway=pedestrian default bicycle=no is.

Er zijn vaak meerdere oplossingen om een tagging neer te zetten.

Door mij aangegeven,

bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su);delivery @ (Sa 08:00-16:00)

of
door jouw aangegeven,

bicycle=yes
bicycle:conditional=yes @ delivery @ (Sa 08:00-16:00)

Beide werken, maar wat is het beste, meest correct, meest begrijpelijk, meest informatief, etc. ?

Dat kan je bekijken door het te toetsen aan argumenten.
Welke van de argrumenten wegen zwaarder. Persoonlijke voorkeur verschillen.
Zo kort mogelijke tagging.
Minder keys is beter.
Maak zo veel mogelijk gebruik van verzamel transportmode.
Voorkom negatieve tagging.
Geen omgekeerde tagging, bijvoorbeeld is het verboden dan gebruik je =no toegestaan =yes =permissive
Tagging sluit aan bij wat men leest op het bord. Omzet begrijpelijkheid.
Tijdvak is conditional tagging.
Zetten we default tags.
etc.

Wiki voorbeeld:

highway=pedestrian
access:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su);delivery @ (Sa 08:00-16:00)

Wiki voorbeeld:

highway=pedestrian
access:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
bicycle=yes
bicycle:conditional=yes @ delivery @ (Sa 08:00-16:00)

Wiki voorbeeld (mofa moped, omdat het op het bord staat):

highway=pedestrian
access:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su);delivery @ (Sa 08:00-16:00)
moped=no
moped:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
mofa=no
mofa:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)

Oeps, …
highway=pedestrian foot=yes default

foot=yes

/designated opvoeren. Je moet de access:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00) overrulen.

Als je dat niet doet moet je vehicle en horse gebruiken.

Wiki voorbeeld (mofa moped, omdat het op het bord staat):

highway=pedestrian
vehicle:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
horse:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
bicycle:conditional=yes @ (Mo-Fr;Sa 00:00-08:00,16:00-24:00;Su);delivery @ (Sa 08:00-16:00)
moped=no
moped:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
mofa=no
mofa:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)

Hoe passen we de wiki tagging aan?
Uitgaande van dat er vele vervoersvormen zijn die tot bevoorradingsverkeer moeten worden gerekend.

Allroads, stond dit access:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00) in de OSM Wiki. Dat lijkt mij bevreemdend. Zaterdag de gehele dag bevoorraden tijdens winkeluren ? En op alle andere dagen tussen 11.00 en 17.00 uur wel ?

Kijk bij het plaatje post #4 deze komt uit de wiki.
Daar staat toch echt Sa 03:30-19:00 bevoorraden.

Tussen 11.00 en 17.00 uur juist niet bevoorraden

Op zich vond ik dat ook al vreemd en het ook nog eens als voorbeeld gebruiken.

Weet iemand waar dat is?

Nee, je voert altijd een standaardwaarde in zonder conditional (wanneer je een conditional gebruikt) zodat renderers en routers die geen conditional-ondersteuning hebben daar mee kunnen werken.

Dus:


bicycle=yes
bicycle:conditional=delivery @ (Sa 08:00-16:00)

Maar, of delivery voor fietsen ook echt nodig is in de praktijk betwijfel ik. De pakketbezorger met een bakfiets heeft vaak of een ontheffing of een gedoogconstructie in overleg met handhaving. Qua routing is vooral motor_vehicle=delivery nuttig voor bevoorraddingsverkeer.

(Tip: gebruik de [ code ]-tags om tagging-voorbeelden duidelijker te maken op het forum.)

Deze dus:


highway=pedestrian
motor_vehicle:conditional=delivery @ (Mo-Fr 06:00-11:00,17:00-19:00;Sa 03:30-19:00)
bicycle=yes
bicycle:conditional=no @ (Sa 08:00-16:00)
mofa=no
moped=no

Dit is wat op de wiki staat, en dat is echt prima. Complexer dan dat hoeft niet. Met paard en wagen bevoorraden we al decennia geen winkels meer, en op een brommer doe je dat ook niet (speciale uitzonderingen daargelaten). Door de extra complexiteit die je introduceert door in de tagging alle edge-cases af te vangen wordt het onderhouden van zulke wegen ondoenlijk en de tagging veel te lastig te begrijpen.

Met de tags uit het voorbeeld vang je de essentie van de situatie, en is 99,9% van het verkeer gedekt.

Ik ben het geheel met Jeroen eens; m.i. is tagging geen sudoku voor gevorderden, noch een etalage van spitsvondigheden.
Iets wat 99,9% in eenvoudige tagging de lading dekt, werkt in mijn ogen voor iedereen, de mapper en de routeerders beter dan een draak van een constructie die mathematisch wellicht juist mag zijn - wat overigens maar de vraag is - maar geen navolging zal vinden noch edit-bestendig is.

Dit los van het feit dat de praktijk leert dat velen zich op straatniveau zich niet aan deze regels houden, als ze het al in 10 seconde kunnen lezen en interpreteren.

Ik heb wel een probleem met

motor_vehicle:conditional

OTG staat er niks van motorvoertuigen. Het is ook niet makkelijker dan

access:conditional

Alleen minder precies. Dus een heel slecht voorbeeld op de Wiki. Ik stel voor dat we dat aanpassen.

De toevoeging van smootheFiets lijkt mij nog helderder. Volgens mij is het dan inderdaad dat het al het verkeer, ook paard en wagen, toegestaan is te bevoorraden :smiley:

In het geval van access:conditional zou ik er wel foot=designated bijzetten. Of vehicle:conditional gebruiken (jammer voor de paardenflitskoeriers). Anders heb je zo’n vage combinatie met een geimpliceerde default-waarde (net als: highway=pedestrian access=private, mogen voetgangers hier komen?)

Nee, maar effectief komt die uitzondering daar wel op neer. Je kan bijna wel stellen dat bevoorradingsverkeer (hiermee wordt de bevoorrading van aanliggende winkels bedoeld, wat eigenlijk altijd met vrachtwagens en busjes gebeurd) in de praktijk neerkomt op gemotoriseerd verkeer, en het grote voordeel is dat de motor_vehicle access-tag subboom geen van de andere betrokken categorieën onderliggend bevat (foot, bicycle, mofa, moped). Dat maakt het interpreteren van de tags een stuk eenvoudiger.

Jeroen, je hebt in de praktijk waarschijnlijk gelijk. Maar toch is het onze interpretatie. OTG staat het anders. Als die interpretatie een hoop gedoe scheelt: prima. Wij hoeven niet katholieker te doen dan de paus. Maar als het kan, hou ik het toch liever bij “map what’s on the ground”. Zeker als het om een voorbeeld op de wiki gaat. En hier kan het gewoon. Op dat bord staat


foot=designated
access:conditional = delivery @ (rare tijden)
bicycle=yes
bicycle:conditional = no @ (Sa 08:00-16:00)

Nauwkeuriger kan het niet.

En wie weet, misschien wordt het volgend jaar een ding dat de kaasboer van twee dorpjes verderop zijn biologische kaas heel duurzaam met paard en wagen naar de hippe kaaswinkel op het Marktplein brengt. Leuke PR-stunt. En het mag best volgens de bebording. Maar daarom gaat het niet eens. Map what’s on the ground.

Het lastige is dat de definitie van bevoorradingsverkeer hiermee wordt opgerekt tot buiten dat wat handhaving en gemeente (en de meeste bezitters van een rijbewijs) er onder verstaan. Bijvoorbeeld in een gemeentelijke publicatie als deze; daar wordt vrachtverkeer (in de zin van verkeersbord C7) zelfs bijna als synoniem aan bevoorradingsverkeer gezien. Dat gaat wat ver want ook bestelbusjes vallen hieronder, maar ruimer dan dat lijkt niet echt voor te komen. Dit zie je in veel van dit soort stukken terug.

Dit is een mooi voorbeeld, waar je ziet dat voor deze gemeente bevoorradingsverkeer een subcategorie van motorvoertuigen is:

Door access te pakken in plaats van motor_vehicle doen wij juist ook een erg ruime interpretatie van wat met bevoorradingsverkeer bedoeld wordt. Nu zal iedereen daar bij gebrek aan een heldere definitie in de wet een andere betekenis aan kunnen hangen, maar meestal lijkt de OSM motor_vehicle categorie het dichtst in de buurt te komen.