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?)
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
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.