Verlaging maximumsnelheid per 12-16 (?) maart

Je kunt iets doen als maxspeed:conditional = 100 @ (06:00-19:00;plusstrook open).
Maar dit kun je niet echt in een navigatie gebruiken, want die weet niet of de plusstrook open is. En een dubbele snelheidsaanduiding in een navigatie tonen zal ook niet snel gedaan worden.

Die consensus is nooit uitgesproken nee. Volgens de wetgeving (RVV artikel 21) is de maximum snelheid op de autosnelweg 130 km/h. Daaruit volgt logischerwijze maxspeed=130 en maxspeed:conditional = .
Uiteraard kom je dan met de vraag wat je moet doen als het overdag 100 en 's nachts 120 is. In het kader van gelijkvormigheid van taggen zou ik dan zeggen maxspeed=120 en maxspeed:conditonal = 100 @…

Met dynamische snelheidslimieten kun je in principe weinig op een statische kaart als OSM, de bron voor de maxspeed-tags is daarom meestal de vaste bebording langs de weg. Wil je aangeven dat dit onder bepaalde omstandigheden anders kan zijn, dan is de wikipagina maxspeed:variable (en dus níet conditional) een tip.

Voor beide manieren waren (en zijn) er argumenten, maar die discussie kun je eindeloos voeren. In maart was er een lichte voorkeur voor de eerstgenoemde manier en inmiddels is dit al ruim 9 maanden de geldende praktijk op OSM in Nederland. Ik zie dat jij dit hebt omgedraaid op de A1, het zou dus fijn zijn als je dit weer terug kunt veranderen om het weer in lijn te brengen met de rest van het snelwegennet. Al is de uiteindelijke betekenis natuurlijk hetzelfde.

Grootste deel van de dag is een lagere snelheid.
maxspeed:conditional wordt lang niet altijd ondersteund door routeplanners.
Daarom heeft een lage maxspeed de voorkeur (safety first).

Weet je zeker dat het niet (deels?) 120 km/h is? Dat lijkt Rijkswaterstaat wel te denken, voor zover ik online terug kan vinden.

Aangezien dit voorstel https://forum.openstreetmap.org/viewtopic.php?pid=780049#p780049 eerder in dit draadje niet gelijk werd weersproken, zou je consensus kunnen vermoeden. Traditiegetrouw kwamen er daarna weer nieuwe stemmen, die de keuze opnieuw ter discussie stelden…

P.S. Linkje naar de betroffen locatie: https://www.openstreetmap.org/?mlat=52.2103&mlon=6.0974#map=13/52.2103/6.0974

Tsja. Als er even 4 dagen geen reactie is in een discussie en vervolgens komen er een aantal mensen die iets anders vinden, is hun mening daarmee niet invalide.
Ik mis op Openstreetmap-NL echt het formele stemproces van Wikipedia, waarbij van te voren duidelijk is wat er te stemmen is, hoe lang de stemronde duurt en bij welk resultaat wat de uitkomst is. Altijd die oeverloze discussies hier.

Thx, die lijkt mij promising (Sterker nog, ik heb hem wel eens gebruikt, maar was dit vergeten)

Dus je stelt voor te taggen voor de (incapabele) renderers?

Er stond 130 op OSM. Ik durf het je niet te zeggen, als ik er weer eens na 19:00 langs kom laat ik het je weten.

Je kan overwegen de proposal-structuur die internationaal op de Tagging-Malinglist gehanteerd wordt te gebruiken, maar dan met de kanttekening dat stemming alleen voor mappers actief in Nederland bedoeld is. Daarmee kom je dichterbij wat Wikipedia doet en kunnen argumenten voor en tegen duidelijk opgesomd worden.

Een voorbeeld van de stemming die daar bij hoort zie je bijvoorbeeld hier.

Onder andere hier stond 120; dit heb jij gewijzigd in 130.

Excuses. Juist dat stuk was de aanleiding om met editen te beginnen: Daar heb ik zelf namelijk gezien dat de toegestane snelheid 130 was.

Nou ja, 5 dagen later heb ik daar bezwaar tegen gemaakt. Als je me verwijt dat ik niet elke dag op het forum kom dan klopt dat, maar “niet gelijk weersproken” vind ik toch bezijden de waarheid.

Ik ben het met IIVQ eens dat het zoeken naar consensus op een nogal ongestructureerde manier gaat. Bij veel onderwerpen is er niet echt sprake van een meningsverschil en komen een paar mappers die daadwerkelijk die met een bepaald onderwerp bezig zijn snel tot een consensus. Als er echter wel een meningsverschil is, dan werkt het niet goed en belanden we snel in oeverloze discussies. Dat zie je hier en ik zie het nu ook bij de discussie over het Koninkrijk der Nederlanden vs Nederland. Een meer gestructureerd voorstel kan in dat geval een goede oplossing zijn.

In het formele stemmingsproces wordt wel gebruik gemaakt van maillijsten waarop de discussie plaatsvindt. Veel Nederlandse mappers zijn niet actief op die mailinglijsten, maar op het forum. Ik zou die stap daarom anders doen als je zo’n Nederlands voorstel wil maken.

Uiteraard; we passen het aan de Nederlandse community. Discussie kan gewoon hier. Het is vooral de gestructureerde vorm van de sjablonen op de wiki die kunnen helpen bij het nemen van langetermijnbesluiten. Het scheelt dat je dan het beslissingsproces op een centrale plaats kan terugvinden (de gearchiveerde proposalpagina) in plaats van die te moeten samen puzzelen uit tientallen forumposts in een of meerdere lange forumthreads. Ook kan een voorstel uitgewerkt en verbeterd worden totdat er consensus over ontstaat.

Ik ben afgelopen zaterdag van Amsterdam naar België (via Antwerpen) en terug gereden. De terugreis was na 19:00 's avonds, maar OSMand gaf vrijwel de hele route aan dat ik 100 mocht rijden op de snelweg. Als ik via Overpass een query draai over waar in Nederland


way
["highway"="motorway"]
[maxspeed=100]
["maxspeed:conditional"="130 @ (19:00-06:00)"]

is, dan zie ik vrijwel het hele Nederlandse snelwegnet, uitgezonderd de grote steden waar de vmax 24/7 100 is.

Osmand lijkt dus niet goed om te gaan met de maxspeed:conditional=130 als die hoger is dan de maxspeed.
Nou is op basis van mijn melding zaken wijzigen taggen voor de renderer (of navigatie natuurlijk) maar ergens is het logisch dat OSMand zo interpreteert, namelijk als je alle tags als unitair en altijd waar zit. 's avonds is het dan ook én maxspeed 130 (vanwege de condition) én 100 (vanwege de maxspeed) en wordt dan 100 weergegeven.
Ook wat de wet betreft lijkt het me handig de tagging om te draaien: op de snelweg mag je 130 (wet) en op de meeste snelwegen geldt ook een verkeersbesluit dat je er overdag (6:00-19:00) maar 100 mag. (Ik schrijf meeste, niet op opritten en uiteraard niet op wegen waar je ook 's nachts maar 100 mag, of zelfs altijd <100 mag)

Dus daarom zou mijn voorstel zijn dit toch echt om te draaien naar


maxspeed=130
maxspeed:conditional = 100 @ (06:00-19:00)

Voordelen:
*De semantische betekenis blijft hetzelfde
*De betekenis is meer in lijn met het verkeersbesluit (uitzondering 6-19, niet uitzondering 19-6)
*Navigatiesoftware die beiden ziet als “waar” gaat niet in de fout

Nadeel:
*Navigatiesoftware die alleen de maxspeed en neit de maxspeed:conditional weergeeft, geeft overdag een te hoge snelheid aan (maar sowieso is niet overal de snelheid getagd, en zelfs als wel heb je als bestuurder je te houden aan de wet, niet aan wat je navigatie zegt. Zelfs Google Maps geeft het regelmatig fout)

Omdat deze discussie vorige keer niet tot een overduidelijk besluit leidde, lijkt het mij handig het volgende te doen:

  • Eerst een periode (zeg tot 14-6) discussie - eventueel verlengd als er nog nieuwe argumenten uitkomen
  • Daarna (tenzij er al overduidelijke concesus is) een duidelijk voorstel tussen 2 (of meer) opties, met een stemperiode met duidelijke einddatum van minstens 10 dagen, waarin iedereen duidelijk zijn stem voor één van de opties laat horen.
  • Na het stemmen een telling en dus uitslag (wijziging alleen bij meerderheid van stemmen) en daarna alleen discussie over hoe tot uitvoer gebracht moet worden, aanpassing van de wiki etc.

Het lijkt me eerder dat OSMAnd niet kan omgaan met maxspeed:conditional. Als ze niet kunnen omgaan met een maxspeed:conditional die hoger is dan de maxspeed, dan hebben ze zelf gekozen om hun programma te schrijven op een manier die verkeerde snelheidslimieten kan aangeven.

Ik heb op deze pagina de afspraken uit dit topic over de verlaging van de maximumsnelheid samengevat. Daar heb ik ook de argumenten over deze keuze opgeschreven.

Voordelen maxspeed=100, maxspeed:conditional=130

  1. De snelheidslimiet van 100 km/h is van toepassing op 54% van de dag en ongeveer 90% van de weggebruikers. Dus het kan gezien worden als de primaire snelheidslimiet.
  2. Dit is de manier hoe de snelheidsverlaging is gecommuniceerd en bekend is bij de meeste Nederlanders: 100 km/h behalve 's avonds en 's nachts.
  3. Als de fout in navigatiesoftware als OSMAnd komt door het negeren van maxspeed:conditional, dan wordt bij deze keuze altijd de lagere snelheid aangegeven, wat veiliger is en boetes voorkomt. Deze snelheid is ook vaker van toepassing (zie argument 1).

Voordelen maxspeed=130, maxspeed:conditional=100

  1. Dit volgt het beste hoe de wet en de verkeersborden werken.

Het argument ‘De semantische betekenis blijft hetzelfde’ kan voor beide opties worden gebruikt.

Als Osmand zo geprogrammeerd is, lijkt me dat een fout van Osmand. De wiki-inleiding van conditional restrictions geeft een expliciet voorbeeld waarbij maxspeed:conditional boven maxspeed gaat.

Het meeste verkeer rijdt overdag. Vanuit het principe van graceful degradation ligt het dan voor de hand om de snelheid overdag in maxspeed te zetten en de snelheid 's nachts in maxspeed:conditional, zodat het bij software die maxspeed:conditional niet snapt in de meeste gevallen goed gaat. Waarschijnlijk krijgen we méér klachten door brakke navigatiesoftware als we de tags omdraaien.

Er is hier al een issue voor in github: https://github.com/osmandapp/OsmAnd/issues/11419

Een tip die gegeven wordt is om iig “Consider temporary limitations” (houd rekening met tijdelijke beperkingen) op Aan te hebben staan.
Misschien handig om daar een screenshot te plaatsen van een plek waar het fout gaat.

Er is een ander draadje uit 2016 op de OSMAnd google groups waar gesteld wordt dat conditional access restrictions niet werken. Nu is dat dus al 5 jaar geleden, maar misschien is het een algemeen dingetje. Als iemand ergens zo’n restrictie in de buurt heeft is het misschien ook wel handig om dat te testen.

Die laatste optie was nieuw voor mij en stond inderdaad uit. Een beetje stom van OSMAnd die default uit te zetten want “vroeger” deed 'ie het wel automatisch. Daarnaast is het icoontje (werkzaamheden) erbij niet echt duidelijk dat het ook om time-conditionals gaat.

Ik heb een suggestie gemaakt dit duidelijker te maken in de OsmAnd-bug

Inderdaad, nu na 19:00 geeft de snelweg netjes 130 aan als ik een route simuleer (en weer 100 als ik temp limitations uitzet). Mooi, Thx!

Ik ben nog steeds van mening dat de tagging omgedraaid zou moeten zijn (dus maxspeed=130 en conditional=100 @ 6-19) met als hoofdreden “tag what’s on the ground” - niet “tag what we expect the user wants to see”. Exact om deze reden taggen we namelijk de opritten wél met 130.

“De afspraken”… :open_mouth: Er was alleen niet echt concensus.

Dat is natuurlijk een non-argument. Als er ineens zou staan 100 van 6-9 dan is het ineens niet meer de primaire snelheidslimiet.

Tsja. Nederlanders hebben wel meer verkeerde ideeën over het verkeer. Zoals dat je voorrang zou hebben op de rotonde. Zonder verdere aanwijzingen heeft verkeer van rechts toch echt voorrang. Alleen is het op >98% van de rotondes met borden en tekens zo geregeld, dat verkeer op de rotonde voorrang heeft. Dus je zou ook niet als default een rotonde voorrang moeten geven.

Tsja. Waarom taggen we opritten dan niet met 100, of met 30 omdat dat een veilige snelheid is? Omdat dat niet de snelheid is die er geldt.

Precies. En vooral dat het verkeersbord “100” + onderbord “6-19” de conditional is. Terwijl hoe het nu opgeschreven is (een conditional van 19-6) een interpretatie is van wat er op de borden staat.

Overigens ben ik zwaar aan het advocaatvandeduivelen hoor.

Uit de discussie van vorig jaar kwam naar voren dat er een voorkeur was om het de taggen zoals het nu gebeurd is.
Concensus? Ja zeg het maar. Als de meerderheid er in de discussie net zo over denkt mag je van consensus spreken.

Consensus, “algemene gelijkheid van opvatting”.
Nee, dat was het niet. Ik wilde er stil over blijven want mijn opvatting die ik al een paar keer geuit heb is anders als wat nu in de wiki is gezet en hoe het gemapt wordt, maar ik wil dan toch maar even heel duidelijk zeggen dat hier geen consensus over is.