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.
