Bevoorradingsverkeer.

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.

Nee, de wereldwijde standaard voor highway=pedestrian (default) is al bicycle=no, daar houden de route programma’s al rekening mee. ( al vertalen ze dat nogal eens naar bicycle=dismount, bij het berekenen van een route)

Zo is op de wegen, wereldwijd, access=yes van toepassing, daar gaan de routeerders van uit.
Dan zet je ook nog niet nog een keer access=yes als je acccess:conditional=no @ (tijden) gaat toepassen.

Ik zie liever dat er geklaagt wordt op een routeerder, dan dat er geklaagt wordt, OSM is verkeerd.
Meer een stokje om de niet conditonal routeerder, wel conditional te laten toepassen.

In een verkeersbesluit hierboven zie je een Gemeente aangeven.

Elke situatie is weer anders, door een Gemeente uitgelegde motivatie, waarbij nogal eens niet alles wordt benoemd als argument voor de motivatie.

OSM motor_vehicle is inclusief mofa en moped

RVV
verkeer: alle weggebruikers;
motorvoertuigen: alle gemotoriseerde voertuigen behalve bromfietsen, fietsen met trapondersteuning en gehandicaptenvoertuigen, bestemd om anders dan langs rails te worden voortbewogen;

Hier aangegeven welke gemotoriseerde voertuigen tot deze categorie motorvoertuigen behoort, gelijk geeft men aan dat bromfietsen, fietsen met trapondersteuning en gehandicaptenvoertuigen, gemotoriseerd zijn.

gemotoriseerd verkeer is dan inclusief bromfietsen, fietsen met trapondersteuning en gehandicaptenvoertuigen.

Ik vind dat niet echt een goed voorbeeld. Het enige wat ik lees is dat bevoorradingsverkeer uitgezonderd wordt van de geslotenverklaring motorvoertuigen.
Als ergens een verbod wordt ingesteld voor motorvoertuigen met daaronder “uitgezonderd bestemmingsverkeer” betekent dat toch ook niet dat fietsen niet gezien worden als bestemmingsverkeer.

Mierenneuken opzijgezet, ben ik het eens dat we soms best wat coulant met access tags om kunnen gaan als dat het veel simpeler maakt, maar het moet wel blijven kloppen. In dit geval lijken beide opties me niet verkeerd.

Bestemmingsverkeer heeft ook een andere betekenis dan bevoorradingsverkeer. De twee zijn niet aan elkaar verwant.

Dit is gewoon de gedocumenteerde conventie voor het gebruik conditional. Het geeft de mapper die hem aantreft en mogelijk bijwerkt gelijk de context. Bij access=yes is dat vaak niet nodig, maar bij specifiekere accesstags is dat niet verkeerd; het maakt het beheer van conditionals eenvoudiger. Als je daar mee wil breken kun je die discussie op de betreffende talk-page voeren of op de Tagging ML, maar wat is de winst?