Denk idd dat delivery de meest praktische waarde is.
Maar er is in mijn ogen is er wel een verschil tussen bevoorrading en bezorging, zoals waarschijnlijk bedoeld wordt op zulke bebording.
Die ene koelkast die bij jou afgeleverd wordt, wordt bezorgd (jammer dan, loop maar wat verder met je steekwagentje). De vrachtwagen die 20 koelkasten aflevert bij de winkel is aan het bevoorraden. En de koffie voor voor de kantine van die winkel wordt daar dan bezorgd.
Dus:
bevoorrading: winkelvoorraad aanvullen voor verkoop, halffabrikaat om andere producten te maken
bezorging: pakketdiensten, pizza’s, … voor gebruik/consumptie
Met daartussen vast nog een grijs gebied met zaken die je kunt indelen bij beide afhankelijk van hoe je ernaar kijkt.
Onderborden mogen wel uitbreiden maar niet beperken. Het toestaan van fietsen op bepaalde tijden is toegestaan.
moped en mofa waren al verboden, voetgangers zonebord, maar niet als bevoorradingsverkeer.
Dat hef je niet op door onderstaande regel, snor- en bromfietsen NIET toegestaan. Het is louter informatief, verbieden op onderbord mag niet.
Een ongelukkig voorbeeld voor in de wiki. Ik twijfelde of hier mofa=no en moped=no wel correct is.
mofa:conditonal=delivery @ … moped:conditonal=delivery @ …
delivery is dan nog wel breed begrip
wiki
Er is zelfs een moment dat fietsen niet is toegestaan, ZA zaterdag, maar wel delivery, die tijden bicycle:conditional=delivery @ …?
Wat Sander schrijft, ik had dit:
Bij bevoorrading, voorraad voor, verkoop, een dienst, het maken van een product, inventaris voor uitoefenen van, een personeel kantine.
Levering aan een bedrijfslocatie, business to business.
Misschien is dat wel de criteria.
Die elektrische brom- en fietsbakken. Zulke varianten.
access:conditional = delivery @ … [want je mag zelfs ter paarde bevoorraden]
foot=designated (default maar overschreven door access)
bicycle=yes
bicycle:conditional=delivery @ … (op die manier mag ook bevoorradingsverkeer op de bakfiets)
Mofa en moped hoeven niet expliciet, die vallen onder access.
Edit: ik zie net op de Wiki een motor_vehicle:conditional. Dat is natuurlijk onzin. OTG staat daar niks van motorvoertuigen. Dat is je punt, AllRoads, toch?
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.
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.
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,
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.
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.
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.
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 ?
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.
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.)
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.
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
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?)