Knuppel, hoenderhok:
Bron: https://www.wegenforum.nl/viewtopic.php?f=49&p=1198838#p1198838
Misschien terug gaan naar de basis van OSM? Groundtruth? RVV artikel 12:
“Buiten de bebouwde kom gelden de volgende maximumsnelheden:
a. voor motorvoertuigen op autosnelwegen 130 km per uur, ….”
Er bestaat gewoon geen conditional 130, alleen een conditional 120 en 100.
In de praktijk bestaat die conditional wel, je mag namelijk maar 11 uur van de dag 130 rijden. Dezelfde argumenten worden constant herhaald en zijn door Jeroen goed samengevat.
Laten we gewoon stemmen op die pagina en het volgens de uitkomst van die stemming taggen.
Ter referentie ook nog de standaard snelheden in NL als je de grens over komt: https://www.google.com/maps/@50.7553127,5.6968451,3a,75y,48.5h,85.49t/data=!3m6!1e1!3m4!1sZS22WjsL-wO8Lt9CXXxwJQ!2e0!7i16384!8i8192
Hoe kun je de standaard volgens de wet nu conditional noemen? 130 kmh is de standaard, de rest zijn tijdsgebaseerde afwijkingen daarvan, dus conditional.
Beetje offtopic, maar voor de mensen die het interessante materie vinden:
De reden dat er geen 120 + 100 [6-19h] wordt toegepast is omdat het RVV geen situaties toelaat met meerdere A1 borden. Dus als het wel zo geplaatst zou worden zou de 100 waarschijnlijk niet handhaafbaar zijn. Daarnaast wordt dit ook duidelijker geacht.
Volgens de wiki: "The maxspeed:conditional=* tag is used on ways to define the maximum legal speed limit which depends on certain situations, such as the time of day, weather, or another particular condition, for a highway=, railway= or waterway=. This tag is used in addition to maxspeed=, which specifies the normal maximum speed limit when the condition does not apply. "
Conditional gaat erover dat deze snelheid afhankelijk is van in dit geval een bepaalde tijd. Dat klopt dus net zo goed voor de 100 overdag als de 130 's nachts.
Wat is nu de normale maximumsnelheid? Is dat de maximumsnelheid volgens het RVV of de maximumsnelheid die het grootste gedeelte van de dag geldt? Hierover zijn de meningen verdeeld, zoals je kan zien aan deze discussie die al bijna twee jaar duurt, en hierover kunnen we dus stemmen.
Bij voortschrijdend inzicht, ben ik het helemaal met je eens.
(mijn excuus voor deze stemming)
Toch is het wel goed te zien welke de stemmen verkregen worden door een “lagere drempel”
Volgens mij is de telling niet anders dan het voorstel hoe het op dit moment is.
Zet in dat geval even op de wikipagina wanneer de stemming afloopt.
Daar waarvoor de conditie niet geldt.
Wat is dan de conditie? Die wordt namelijk aangegeven met een onderbord. Alleen het aanwezig zijn van een onderbord, bepaalt dat, waar het onderbord betrekking op heeft, de exceptie is. Wat dan overblijft is de normale snelheid.
Dat is inderdaad het argument voor maxspeed=130, maxspeed:conditional=100. Hier is niet iedereen het mee eens, waardoor we deze discussie hebben. Anderen vinden namelijk dat de maximumsnelheid die 54% van de dag en voor zo’n 80% van de weggebruikers geldt, de normale snelheid.
Met het oog op dit, is er bezwaar als ik de einddatum op 4 weken na 10 januari zet (7 februari 23:59)?
Ik hoop niet dat we die argumentatie dan ook consequent gaan doorvoeren. 
Gesloten van zonsondergang t/m zonsopkomst in de zomer:
foot=yes
access:conditional=no @ (sunset-sunrise)
Gesloten van zonsondergang t/m zonsopkomst in de winter:
foot=no
foot:conditional = yes @ (sunrise-sunset)
edit: typo
Ik zal voor D E kiezen, als mogelijke keuze.
Dat heeft met de prioriteits keuze te maken, gradatie wat men het meest belangrijkst vind.
Het rechtstreeks vertalen van de onderborden naar conditonals, een directe vertaling.
Voor mij hoort er altijd maxspeed:conditional=100 @ (06:00-19:00); 120 @ (19:00-06:00) te staan.
Dan blijft de keuze D E over.
Goed idee denk ik, iets als IRV.
Ik heb nog geen voorstel voor software langs zien komen, dus heb even een scriptje geschreven. Kon zo 1-2-3 niet iets vinden dat ons formaat pakt en ik vind het ook leuk: https://gist.github.com/lgommans/e235dec8a19df3d4d317affa1cc39029
De enige andere die ik snel kon vinden waar je niet moet registreren en hun platform voor het stemmen gebruiken, is deze: https://petertheone.github.io/IRV/ maar die is wat meer finnicky en wil een compleet ander formaat, dus dat wordt eerst omschrijven.
Sowieso zou ik niet direct mijn eigen code vertrouwen, ook gelet op het uur van de dag, dus het is wel zaak om het met beide implementaties te draaien en kijken of ze het eens zijn. Of handmatig natellen en het script gebruiken om te kijken of er geen telfouten gemaakt zijn. Of alleen met die van PeterTheOne, maar je moet het formaat omkatten en die van mij werkt met het formaat van onze wiki dus dan kunnen we ook net zo goed beide implementaties draaien.
Om campagning te voorkomen denk ik dat een tussenstand plaatsen geen goed idee is, overigens, ook al is dat nu makkelijk te genereren met mijn code. Ik plaats dit nu alvast om te voorkomen dat iemand anders dubbel werk doet (tenzij jij, lezer, het ook leuk vindt natuurlijk).
Wiki optie D Tag what’s on the ground
Dit staat op de borden:
maxspeed=130
maxspeed:conditional=100 @ (06:00-19:00)
maxspeed=130
maxspeed:conditional=100 @ (06:00-19:00); 120 @ (19:00-06:00)
@Luc: Ik zal het gewoon met de hand tellen, dat is prima te doen in dit geval. (Mocht je interesse hebben in stemtelsoftware voor diverse soorten stemmingen, kun je naar OpenSTV kijken.) Er is overigens geen reden om de tussenstand geheim te houden, immers, IRV is juist zeer bestendig tegen strategisch stemmen.
@Hans: Je kunt onderaan de wikipagina je stem toevoegen.
Toch maar even de langere toelichting verwijderd uit de stemwiki en hiernaartoe verplaatst, zat daar toch een beetje in de weg…
Ik houd me in OSM vooral bezig met tijdgebonden conditionals in natuurgebieden (zowel tijd van de dag als datum), heb daarom eerst gekeken wat andere mensen aandroegen en daarna mijn eigen afwegingen gemaakt, ook vanwege de raakvlakken tussen deze onderwerpen en bredere keuzen voor wijze van taggen.
Toelichting op voorkeur (A>B>C>E>F>D )
**Kort: **Optie A is zowel inhoudelijk correct, voldoet aan OSM standaarden, meest zinvolle duiding van situatie in [key] en is in praktijk meest bruikbaar in gevallen waarin conditionals niet worden ondersteund.
Het 1-op-1 coderen van combinaties van verkeersborden doen we obv map what’s on the ground in [traffic_sign=]. Bij coderen van [maxspeed=] in OSM spelen ook andere OSM-vormvoorschriften en afwegingen -zoals duidelijkheid en betekenisvol categoriseren- een rol.
Lang: Criteria / Waarom niet de andere waarden?
(1) Geen incorrecte tags, Map what’s on the ground:
ook individuele tags moeten een situatie aangeven die daadwerkelijk voorkomt op de betreffende weg (op z’n minst een deel van de dag). Daarmee vallen D en F af:
-Op het 2e type weg geldt nooit 130, dus dat kan niet in [maxspeed=] staan (hoogstens in een andere nieuwe key zoals [legal_default:maxspeed:highway_type:overruled_by_traffic_sign=]
-maxspeed=variable is hier incorrect, want dat is volgens Key:maxspeed#Values : “[…] displayed on electronic variable signs”
(2) voldoen aan OSM- vormvoorschriften conditional restrictions en gebruik betekenisvolle categorieën
https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Default_restrictions:
(let wel: "default " is hier niet de juridische default -130 op autosnelweg-, maar de default in de OSM-tag-combinatie, oftewel: wat geldt in OSM als de conditional waarde niet geldt, en dat kan iets anders zijn zoals 100 of 120, afhankelijk van de bebording)
Dit is extra van belang omdat niet alle datagebruikers conditional restrictions ondersteunen en voor sommige toepassingen dit concept ook gewoon niet goed past (routers geven een advies voor een specifieke tijd op de dag, maar gedrukte kaarten geven een beeld dat voor de hele dag geldt).
Karteren is ook in belangrijke mate categoriseren. Daarbij hoort een betekenisvolle waarde in [maxspeed=*].
Als er verschillende bebordingsopties zijn die op de weg leiden tot exact het zelfde regime dan krijgen ze in OSM bij voorkeur allebei dezelfde tag in [maxspeed=*].
De verschillende configuraties van borden die aan die identieke regimes ten grondslag liggen kunnen worden onderscheiden in [traffic_sign=x;y] vs [traffic_sign=z] (Map what’s on the ground)
E valt af omdat dit niet voldoet aan het vormvoorschrift voor conditionals en ook aanpassing van dit voorschrift obv bovenstaande niet aan te raden lijkt. Desondanks lijkt het niet hoeven kiezen van de ene correcte waarde boven de andere bij de weg met 100/120 ook weer aantrekkelijk vanuit oogpunt van zoveel mogelijk neutraliteit bij het mappen.
(3) rekening houden met effecten voor gebruikers als conditional-waarden niet worden ondersteund
In verlengde van (2): De lagere snelheden gelden het grootste deel van de dag en -belangrijker- voor een nog groter deel van het verkeer. Daarnaast geeft een foutieve lagere snelheid door router voor de gebruiker uiteindelijk een meevaller in de aankomsttijd (feitelijk vs voorspeld). Dat terwijl een foutief hogere snelheid uiteindelijk een tegenvaller in de feitelijke aankomsttijd geeft (als je de snelheid op de borden aanhoudt) of een verhoogde kans op boetes als je de snelheid van de router aanhoudt. Dat nog los van de kwestie van veiligheid.
Van de overgebleven opties komt C hier het minst aan tegemoet, dan B. Daarmee resteert A.
Weet niet waarom ik hier geen e-mailnotificatie van kreeg (had op het topic gesubscribed maar slechts éénmaal een e-mail gekregen, de verdere reacties zie ik nu pas).
Over strategisch stemmen: als iedereen die wil stemmen, stemt, dan wellicht ja. Maar als een tussenstand gepost wordt en X op winst staat, en anderen hier denken “oh maar dáár ben ik specifiek tegen!” en dan alsnog gaan stemmen en anders niet de moeite genomen hadden… en dan krijg je de volgende golf die het tegenovergestelde zou willen doen wanneer Y op winst staat, maar dan is de election alweer voorbij. Ik vermoed dat de analyse die jij gelezen hebt van bestendigheid tegen strategisch stemmen, van een normale stemprocedure uit gaat waarbij iedereen vrijwel tegelijkertijd naar het hokje gaat, en niet later alsnog besluit om de moeite te nemen te gaan wanneer hun voorkeur niet bovenaan staat in een tussenstand. Misschien. Anyhow, dit is zover ik weet toch niet gebeurd 
Anyhow ik heb de resultaten ook door m’n script gehaald en die komt op exact dezelfde waarden uit. Het werkt!
In de kop van de e-mail die je krijgt, staat een waarschuwing dat er geen verdere e-mails volgen !