Reduced speed limit on Dutch motorways/Vote

Hieronder zie je verschillende mogelijkheden om tijdsafhankelijke snelheidslimieten op Nederlandse snelwegen te taggen. Onderaan deze wikipagina kun je stemmen op jouw voorkeur, door deze wikipagina te bewerken en jouw stem volgens instructies toe te voegen.

Opties om uit te kiezen

Gebaseerd op de discussie in dit forumtopic: https://forum.openstreetmap.org/viewtopic.php?id=68803

	6-19h	6-19h 19-6h	Motivatie
Optie A	maxspeed=100 maxspeed:conditional=130 @ (19:00-06:00)	maxspeed=100 maxspeed:conditional=120 @ (19:00-06:00)	In maxspeed=* staat de maximumsnelheid die de meeste weggebruikers tegenkomen en die het grootste deel van de tijd geldt (13 uur per etmaal versus 11 uur). Als jouw software maxspeed:conditional=* niet ondersteunt, heb je de grootste kans dat je toch de juiste maximumsnelheid ziet. Tevens veilig in de zin dat je software nooit een te hoge maximumsnelheid aan kan geven.
Optie B	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00)	maxspeed=100 maxspeed:conditional=120 @ (19:00-06:00)	In principe staan tijdsafhankelijke maximumsnelheden in maxspeed:conditional=*, tenzij àlle maximumsnelheden tijdsafhankelijk zijn. In dat laatste geval wordt de maximumsnelheid die de meeste weggebruikers tegenkomen en die het grootste deel van de tijd geldt, getagd als maxspeed=*.
Optie C	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00)	maxspeed=120 maxspeed:conditional=100 @ (06:00-19:00)	Tagging sluit aan bij hoe de verlaging van de maximumsnelheid overdag destijds in het verkeersbesluit van Rijkswaterstaat is geformuleerd. Het laatste onderbord "19-6h" onder de "120" heeft een meer informatief karakter - het wijzigt niets meer aan de drie borden erboven, maar verduidelijkt slechts - en komt daarom niet terug in de tagging.
Optie D	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00)	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00); 120 @ (19:00-06:00)	Tag what's on the ground. Tagging komt overeen met wat er letterlijk op de verkeersborden staat: snelheidsborden met tijdsonderbord zijn altijd getagd als maxspeed:conditional=*. Dit is de gebruikelijke manier van taggen binnen OSM en consistent. Tagging die overeenkomt met de verkeersborden is ook makkelijker te onderhouden. Als je in jouw software tijdsafhankelijke limieten hebt uitegschakeld (is instelbaar in bijv. OsmAnd), dan krijg je de formeel correcte niet-tijdsafhankelijke maximumsnelheid te zien. Enige verschil tussen opties D en E is of maxspeed=130, als die nooit geldt, wel of niet wordt weggelaten.
Optie E	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00)	maxspeed:conditional=100 @ (06:00-19:00); 120 @ (19:00-06:00)
Optie F	maxspeed=130 maxspeed:conditional=100 @ (06:00-19:00)	maxspeed=variable maxspeed:conditional=100 @ (06:00-19:00); 120 @ (19:00-06:00)	Zelfde als optie E, met een oplossing om toch altijd maxspeed=* in te kunnen vullen.

Noot: Voor de keuze 100/130 zijn opties B t/m F equivalent. Voor de keuze 100/120 zijn opties A en B equivalent.

Stemming

Graag de opties A t/m F op volgorde van eerste voorkeur naar laatste voorkeur plaatsen. Hiermee doen we een instant-runoffstemming: zo wordt één voor één de minst populaire optie geschrapt totdat we de winnaar hebben, zonder telkens opnieuw te hoeven stemmen. Als je opties niet noemt, gaan we ervanuit dat deze opties je gedeelde laatste voorkeur zijn.

Please order the options A through F from first preference to last preference. We will use this for an instant-runoff vote: this way, the least popular options are eliminated one by one until we have a winner, without having to vote again all the time. If you do not mention options, we assume these options are your shared last preference.

Plaats hieronder jouw stem

C > E > D > F > A > B --Herrieman (talk) 21:50, 10 January 2022 (UTC)

B > C > E > A > D > F -- Famlam (talk) 09:16, 11 January 2022 (UTC)

C > B > E -- IIVQ (talk) 10:29, 11 January 2022 (UTC) Stemverklaring: overige opties vind ik belachelijk, optie F is niet waar maxspeed=variable voor bedoeld is.

A > C > F > D > E > B A67-A67 (talk) 14:16, 11 January 2022 (UTC) Stemverklaring: Ik vind de argumenten voor 100 km/h als primaire snelheid sterker dan die voor 120/130. Daarnaast vind ik consistentie belangrijk, waardoor B afvalt. Opties D, E en F lijken me nogal gekunsteld, vooral het gebruik van maxspeed=130 als deze snelheid nooit geldt.

A > E > D > F > C > B Emvee (talk) 18:35, 11 January 2022 (UTC) Stemverklaring: Argumenten onder A vindt ik het sterkst, daarna Tag what's on the ground.

A > B > C > E SmootheFiets (talk) 14:32, 12 January 2022 (UTC)

A > C > B-D-E-FCJTmmr( 17:21, 12 January 2022 (UTC)

A > geen alternatiefCommodoortje( 18:00, 12 January 2022 (UTC) Ik ben geheel geen voorstander om hogere snelheid als standaard waarde te hanteren, reden: Je bent dan afhankelijk van de navigatie software, hoe deze het interpreteert/visualiseert.

C > E > F > D > A > B --JeroenvanderGun (talk) 17:56, 12 January 2022 (UTC) Stemverklaring: belangrijk om strict onderscheid te houden tussen conditionele maximumsnelheden en maximumsnelheden die altijd gelden, en tevens de tagging niet te ingewikkeld te maken.

A > C > B > E > D > F 85Bas (talk) 19:48, 12 January 2022 (UTC) Stemverklaring: Optie F is foutief. Optie A, B en C zijn voor mij qua betekenis acceptabel. Optie A heeft de voorkeur vanwege veiligheid, eenvoud en consistentie.

A > B > C > D > E > F maxspeed=variable is simply wrong here, this tag has a different meaning. Skipping maxspeed=* just makes harder to process that data. A, B, C, D are all correct, with main difference how this data will be used by a simple data consumers, not supporting conditional restrictions. One may prefer either (1) exact signing form, in very literal "Tag what's on the ground" (2) more typical value (3) more restrictive value. Applying (2), (3) makes easier to process the data. I do not consider literally treating rules as a good idea, and in this case both more typical and more restrictive value is the same. Mateusz Konieczny (talk) 17:49, 13 January 2022 (UTC)

A > geen alternatief Leo Slager 20:55 13 January 2022 (UTC) Al was het alleen maar om te voorkomen dat weggebruikers zich gaan beroepen op hun router om hun snelheidsovertreding te rechtvaardigen.

A > HenkL (talk) 22:38, 13 January 2022 (UTC)

C > B > E --Roef (talk) 12:55, 20 January 2022 (UTC)

B > C > A richardbrinkman ([User talk:richardbrinkman|talk]]) 07:19, 21 January 2022 (UTC)

A > geen voorkeur voor alternatief Omdat 100 km/h zowel de meest gangbare (qua uren en qua dagritme) en de meest veilige optie is op wegen waar deze beperking geld, lijkt me dat de meest geschikte standaardwaarde. De letterlijke 'tag what's on the ground' optie die 130 km/h als standaardwaarde neemt voelt als een verkeerde interpretatie van die regel, met name omdat deze hogere maximumsnelheid voornamelijk een politiek symbool is wat vanuit het oogpunt van verkeersveiligheid, doorstroming, en milieueisen onzinnig is gebleken. De facto is 100 km/h veelal de standaard op zulke wegen met kleine uitzonderingen bedongen die deze beperking minder pijnlijk maken voor VVD en CDA. We hoeven in de tagging (naast het m.i. zwaarwegende veiligheidsaspect) niet te doen alsof 130 km/h eigenlijk de standaardwaarde is. --JeroenHoek (talk) 10:04, 21 January 2022 (UTC)

C Kogacarlo 10:52, 21 January 2022 (UTC)

A > C Laagste snelheid eerst (ja!) of hoogste snelheid eerst, de andere opties zijn verwarrend. --Kin Sapalot 23 January 2022 (UTC)

D > C > E > B > A > F --Mdeen (talk) 10:46, 24 January 2022 (UTC)

A > geen alternatief, --user:Jvdmeer behalve de eenvoudige software die de maximum snelheid aan de veilige kant aangeeft, zal de eenvoudige routers ook een conservatieve schatting doen van de aankomsttijd. En software doe wat geavanceerder is en de conditionals wel begrijpt, zal gewoon de juiste tijden/snelheden doorgeven. Dus win-win.

C > E > D > F > B > A --Cartographer10 (talk) 19:35, 25 January 2022 (UTC)

B > A > F Als er alleen een voorwaardelijke uitzondering staat, dan dat als voorwaardelijke uitzondering geven. Als er twee uitzonderingen staan die elkaar uitsluiten en samen alles afdekken, dan de veiligste optie als maxspeed geven. Beide als voorwaardelijke uitzondering kan ook, maar lijkt mij onnodig onhandig in de verwerking. --Peter Elderson (talk)

C > E > D > F > A > B --Skinkie (talk) 22:45, 1 February 2022 (UTC)

A > C > B > F > E > D Optie A lijkt de meest veilige en praktische. Ideologie over leefregels doen we in building=religious wel, het makkelijkst om mee te werken is een fallback (maxspeed) die de meeste bestuurders treft (stel je maakt een kaartje voor r/mapporn met snelwegsnelheden in europa, of je hebt inderdaad software die geen conditionals kent, dan is dit het accuraatst zonder moeilijk te doen) en tevens ook het veiligst is om weer te geven (de lagere snelheid). Optie D is het minst zinnig: 130 komt nooit voor (we schrijven geen wiskundig proefschrift over een imaginaire situatie die, een of andere logica volgend, wel klopt maar ook evident praktisch nutteloos is). Behalve D ben ik niet echt expliciet tégen bepaalde opties: het zijn allemaal andere, juiste (ofja, maxspeed=variable is niet helemaal juist) weergaven van de werkelijkheid volgens verschillende logica. In zo'n geval kunnen we net zo goed iets pakken dat voor de gebruikers (data consumers) het beste uitpakt, in het bijzonder als er ook (in uitzonderingsgevallen) veiligheidsimplicaties zijn (alleen optie A gebruikt lagere=veiligere fallbacks). / rough agree with Mateusz Konieczny, Jvdmeer, JeroenHoek, enz. Lucgm (talk)

D > - > - > - > - > E Optie D het meest correct, een zo direct mogelijk vertaling van de verkeersborden, onderborden is beide conditionals vermelden. Dan blijft D en E als optie over. Dit is ook beter te controleren, hoef je minder over na te denken. --AllroadsNL 12:00, 2 February 2022 (UTC)

D > E Optie D, puur omdat het Map what's on the ground is. Optie E zou ik kunnen overwegen omdat deze er erg dicht bij ligt. --Geim

A > D Map whats on the ground is het uitgangspunt. Af en toe is daarvan afwijken noodzakelijk. Zoals in dit geval. De meest logische max snelheid is dan optie A die goed uitlegbaar is. De overige opties zijn niet uit te leggen, de ene keer max speed X, dan max speed Y, slaat kant nog wal. Tweede optie zou dan ook optie D zijn "map whats on the ground". De overige voorstellen zijn geen optie voor mij dus neem ik niet mee. --Roelieboelie

A > D > F Multichill (talk) 22:09, 5 February 2022 (UTC)

D > E Map what's on the ground. Hans Erren (op verzoek toegevoegd, bron: https://forum.openstreetmap.org/viewtopic.php?pid=854503#p854503 )

A>B>C>E>F>D Optie A is zowel inhoudelijk correct, voldoet aan OSM standaarden, meest betekenisvolle duiding van situatie in [key:maxspeed] 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 meerdere opties voor coderen van [maxspeed=*] in OSM spelen ook andere OSM-vormvoorschriften en afwegingen -zoals duidelijkheid en betekenisvol categoriseren- een rol.

Verdere toelichting op https://forum.openstreetmap.org/viewtopic.php?pid=854534#p854534 Multimodaal (talk) 15:23, 6 February 2022 (UTC)

A > D Er valt wat te zeggen voor het strikt volgen van de 'map whats on the ground' conform bebording. Voor mij is dit in deze situatie niet het enigste uitgangspunt of het zwaarst wegende en dragen we ook zorg voor de meer representatieve weergave van de werkelijkheid. Met A geven gebruikers van de database die niet met maxspeed:conditional=* om kunnen gaan een betere weergave van de snelheden zonder dat we de situatie incorrect weergeven. E de Wit (talk) 20:56, 6 February 2022 (UTC)

A > geen voorkeur voor alternatief Vanwege het veiligheidsaspect en (t.o.v. van D-F) simpliciteit. OSM is een kaart (geo-database) om praktisch te gebruiken, geen wetboek. Dat die lagere snelheid dan ook nog eens kantje boord vaker geldig is, is voor mij een bonus, maar niet doorslaggevend. Dat laatste zou een factor kunnen worden als het bijv. zou gaan om een lagere snelheid alleen op zondagochtend. Byckel (talk) 05:50, 7 February 2022 (UTC)

Uitslag

Optie	Aantal eerste keus	Percentage eerste keus
A	18	56%
B	3	9%
C	7	22%
D	4	13%
E	0	0%
F	0	0%
Totaal	32	100%

Optie A heeft in de eerste ronde van de instant run-off direct een meerderheid van 56%, en is daarmee de winnaar.