Uitzonderingen voor veiligheidsdiensten (emergency=yes, etc.)

In Leeuwarden liep deze week de Veiligheidsregio Fryslân tegen een interessant probleem aan met routering voor brandweerwagens (changeset en analyse hier). De routeplanner LiveNav maakt gebruik van OpenStreetMap. Voor een melding op Boksumerdyk 5, werden ze via een omweg de weilanden ingestuurd:

De gewenste route is echter deze:

Nu vermoeden we dat dit komt omdat de Boksumerdyk een wettelijke, beborde beperking heeft op breedte en asdruk:


maxaxleload=2.2
maxwidth=2

A. Postma van de Veiligheidsregio Fryslân meldt daarop:

Dus LiveNav kan de wettelijke beperkingen zo te zien ‘overriden’.

Nu wordt dit probleem her en der opgelost door emergency=yes toe te voegen aan de stukken weg waar veiligheidsdiensten de wettelijke beperking kunnen negeren. Bijvoorbeeld zoals dat hier gedaan is. Deze optie werd ook voor de Boksumerdyk geopperd, maar ik zie daar wel problemen mee op een aantal punten. Het lijkt me daarom goed om hier de technische bezwaren en de gevolgen van deze tagwijze te bespreken.

Ik benoem hieronder de bezwaren die ik zo zie.

emergency=yes is een access-waarde

Dit punt is van technische aard. Wanneer je emergency=yes toepast op een wegsegment, dan doet die tag vanuit de gangbare definitie ervan niets meer dan toegang geven aan veiligheidsdiensten, als een bovenliggende access-categorie deze uitsluit.

Dat betekent dat je daarmee dit kan doen:


highway=service
access=no
psv=yes
emergency=yes

Een wegstuk waar bussen, taxi’s, en veiligheidsdiensten langs mogen, maar de rest niet.

Wat emergency=yes niet doet, is andere beperkingen uitzetten. Dus als maxwidth=* is ingesteld, dan zou emergency=yes daar niets aan mogen veranderen. Doet de routeplanner dat wel, dan is dat een bug in die routeplanner.

Dit geeft uiteraard alleen maar aan dat een wegsegment door veiligheidsdiensten gebruikt kan worden zonder dat ze daarvoor van hun speciale bevoegdheid om ook privéwegen en anderzijds afgesloten wegen te gebruiken — dat mogen ze indien nodig sowieso, maar een routeplanner zal dat proberen te vermijden. Een wegstuk met emergency=yes krijgt die boete in de berekening als het goed is niet; de tag heeft dus wel degelijk nut.

Hoe moet dit dan wel?

Als het inderdaad wenselijk is dat we de mogelijkheid hebben om wettelijke beperkingen uit te zetten voor veiligheidsdiensten, dan is dit hoe dat qua tagging hoort volgens de documentatie en gewoontes van OpenStreetMap:


maxaxleload=2.2
maxwidth=2
maxaxleload:emergency=none
maxwidth:emergency=none

Als LiveNav dat niet ondersteunt, dan lijkt me dat allereerst een bug in die routeplanner.

Mijn grootste bezwaar tegen dit gebruik van emergency=yes in dit geval is dus dat dit oneigenlijk gebruik is van deze tag. Het risico bestaat dat mappers en analysetools die tag van wegsegmenten afhalen waar ze volgens de OSM-documentatie overbodig zijn, terwijl een routeplanner als LiveNav daar onterecht van afhankelijk is!

emergency=yes en hgv=no

Dit is een ander voorbeeld waarin emergency=yes in principe past, maar waar ik me afvraag hoe deze regels toegepast moeten worden qua logica:


emergency      yes
hgv            no
motor_vehicle  yes

Wat men hier wil stellen is dat ook de zware voertuigen van de brandweer (die onder hgv=* vallen) er langs mogen. Het probleem: emergency=* valt niet onder hgv=* in de access-boom. Daarmee is voor mij even niet duidelijk welke tag hier voorrang krijgt voor een voertuig die onder beiden valt: emergency=yes of hgv=no. Is daar een regel voor?

Subjectiviteit van deze uitzonderingen

Het laatste bezwaar is niet onoverkomelijk, maar vergt denk ik wel wat meer afstemming en een richtlijn.

In het geval van de Boksumerdyk valt het opheffen van de wettelijke limieten op breedte en asdruk voor veiligheidsdiensten te verdedigen. Die beperking is namelijk niet opgelegd door de wegbeheerder vanwege fysieke beperkingen op de hele Boksumerdyk, maar op de brug over de Zwette. De wegbeheerder had dat met een onderbord kunnen aangeven („na 2km”), maar deed dat niet omdat hier ook het tegengaan van sluipverkeer een doel was. Deze brug is echter vervangen door een (brom)fietsbrug, waardoor dit argument vervalt (je kan er helemaal niet meer overeen met een auto, ook veiligheidsdiensten niet naar mijn weten). Het is aannemelijk dat de wegbeheerder deze beperkingen opheft in de loop van tijd naarmate de Redbadwei verder aangelegd wordt, maar dat terzijde.

Hier kunnen wij als mappers en de veiligheidsdiensten beiden dus goed inschatten dat de uitzondering voor veiligheidsdiensten veilig kan, maar dat zal niet overal het geval zijn. Als die brug er nog lag, dan was er op de brug zelf namelijk niet alleen een wettelijke beperking, maar ook een fysieke. Ook een brandweerwagen van 2,20m breed past niet over een brug die 2,00m breed is van betonnen rand tot betonnen rand. Dus wanneer passen we zulke uitzonderingen toe?

Een optie is om alleen de veiligheidsdiensten zulke uitzonderingen aan te laten geven (zelf of via mappers die hun ondersteunen) en dat wij ons als ‘normale’ mappers beperken tot bebording. Hadden we hier al een richtlijn voor?

Voor het geval van emergency=yes samen met hgv=no zou de volgende tagging ook een oplossing kunnen zijn:


hgv=no
hgv:conditional=yes @ emergency

Dit omdat emergency ook als waarde voor de user-group in een restriction opgevat kan worden. De documentatie noemt deze als voorbeeld daarvan.

Voordeel hiervan is dat ook gelijk duidelijk is waarom veiligheidsdiensten een uitzondering hebben. Bij enkel emergency=yes legt niet iedereen ook het verband met brandweerwagens die ook onder hgv=* vallen. Ook voorkom je dat je de interpretatie van de botsende access-categorieën aan de routeplanners overlaat; sterker nog, als deze de regel toe passen dat de meeste beperkende regel voorgaat, dan heeft een voertuig wat onder zowel hgv als ermergency valt geen toegang bij hgv=no, ongeacht de emergency=*-waarde.

Dit kan naar mijn mening beter in het veld opgelost worden door een verkeersbord “Hulpdiensten uitgezonderd” onder maxaxleload=* / maxwidth=* te plaatsen. Dan kunnen we namelijk de tags met restricties aanhouden en er emergency=designated bij zetten. Dan is het zowel in het veld als op de kaart duidelijk dat brandweerwagens veilig over de bruggetjes kunnen rijden.

Daarnaast pleit ik ervoor om voor het logisch houden van de tags “emergency” en “hgv” zoveel mogelijk gescheiden te houden, dus liever geen hgv:conditional=yes @ (emergency)

Interessante casus en volgens mij een goede analyse en raakt aan soortgelijke vraagstukken.
Paar opmerkingen bij eerste lezing:

**Parallellen met andere vragen in OSM
**
Dit heeft parallellen met problemen die we vaker zien in het data-model van OSM ,et betrekking tot het door elkaar heen lopen van verschillende niveau’s / soorten van beperkingen, bijvoorbeeld:

  • de -in tijd algemene- openstelling voor een specifieke vervoerswijze (horse=permissive) overschrijft de -in tijd specifieke- sluiting voor alle vervoerswijzen [ *access:conditional= no @ (sunset-sunrise) *]

Gevolg: wegen blijven onbedoeld toegankelijk na zonsondergang in OSM of grote toename van aantal overlappende tags ( *horse = / horse:conditional / foot= / foot:conditional *etc. ) . Oplossing hier zou zijn om alleen *opening_hours *te gebruiken als weg voor alle vervoerwijzen op bepaalde tijden gesloten is, maar dat is niet ingestemd en daardoor niet zo goed ondersteund als access:conditional

-Slordige opbouw van values in belangrijke keys: de vastgestelde waarden van key: access zijn niet uitsluitend, hierdoor geeft de key niet antwoord op 1 vraag maar op meerdere vragen (1: wel/niet toegankelijk voor deze vervoerswijze 2: wel geen bestuursrechtelijk borging van toegang -*yes vs permissive *3: wel/niet specifiek aangeduid/bestemd voor de betreffende vervoerswijze (*designated vs yes/permissive *) en onlangs nog erger geworden met 4: wel/geen vergunning nodig : permit)

Gevolg: op een path kunnen bij deze slordige key-definitie tegelijk meerdere access-tags voor bijvoorbeeld bicycle gelden (permissive; designated; permit), terwijl enkele values hier gebruikelijk zijn. Hierdoor wijzigen mappers vaak de voorgaande access-waarde, ook als die correct was. Al het andere buiten *ja/nee/onbekend *had bij voorkeur in een eigen subkey moeten staan

Emergency
Met dit in het achterhoofd een paar opmerkingen :

Ik denk dat dat net niet helemaal zo is, zoals ook in de Wiki omschreven
https://wiki.openstreetmap.org/wiki/Key:emergency

Artikel 91 van het RVV bevestigt die ook voor de Nederlandse situatie, in ieder geval op openbare wegen en voor ge-/verboden op basis van verkeerstekens op opengestelde eigen wegen:
https://wetten.overheid.nl/BWBR0004825/2021-07-01#HoofdstukVI_Paragraaf5

emergency=yes heeft voegt dus ook in Nederland hier niets toe over vrijstelling van juridische beperkingen, maar geeft vooral een indicatie dat er geen praktische beperkingen zijn.

Ik weet niet hoe dat in Nederland is geregeld op niet openbare wegen met access=private, het lijkt me dat de problemen daar eerder praktisch van aard zijn (gesloten hek) dan dan er een juridisch probleem is als een nooddienst over een weg van partij A met verbodsbord naar het huis van partij B wil rijden dat in de brand staat.

Maar wellicht leest er iemand van een hulpdienst mee die dit kan toelichten?

Strikt genomen lijkt me dat geen bug, maar een correcte toepassing van de letterlijke betekenis van tags. maxwidth is immers de juridische beperking en niet de fysieke:
https://wiki.openstreetmap.org/wiki/Key:maxwidth

De fysieke breedte zal vaak wat groter zijn dan de juridisch toegestane breedte (marge om klemrijden te voorkomen) en kan worden opgenomen in maxwidth:physical , zie https://wiki.openstreetmap.org/wiki/Key:maxwidth:physical

Beoogde mapping
Gelet op het bovenstaande zou naar mijn idee de beoogde mapping zijn, hier even obv width, maar geldt net zo goed voor heigth etc

-maxwidth = de waarde zoals aangegeven op de verbodsborden ; kan door elke mapper worden vastgesteld obv bord

-maxwidth:physical = de fysieke maximumbreedte , op zich kan iedereen dit opnemen, maar doe dit alleen als je heel erg zeker weet dat dit ook past op het gehele wegsegment, bijvoorbeeld met goede meting in veld, anders niet opnemen. Voor navolgbaarheid liefst samen met
source:maxwidth:physical

En omdat hulpdiensten op basis van hun specifieke ervaring een bepaalde marge onder de fysieke breedte etc zullen aanhouden voor het breedste voertuig dat ze daar willen gebruiken, kan ik me goed voorstellen dat ze ook een tag als

-maxwidth:practical willen toevoegen, samen met source:maxwidth:practical.

Maar dat laatste ( :practical) lijkt me op zich welkom in OSM, maar het invoeren daarvan lijkt me echt iets dat is voorbehouden voor hulpdiensten, de rest van de mensen moet zich gewoon aan de verkeersregels houden (maar wellicht komt die informatie wel van pas als een gewone weggebruiker een incidentele ontheffing wil vragen obr RVV artikel 87)

-emergency=yes kan nog steeds dienen als een expliciete aanduiding / samenvatting dat er voor hulpdiensten geen beperkingen zijn op het segment

“houd rekening met hulpdienstroutes”, wat wordt daarmee bedoeld, de emergency=yes tags?
“uit zet” uitzetten, houd dat dan in, geen gebruik maken door te ‘overriden’ met emergency=yes

Dit lijkt dus omgekeerd dan wat de bedoeling is "kan de wettelijke beperkingen zo te zien ‘overriden’.

Juist het aanzetten zou een andere, emergency route moeten geven.

Is het de maxwidth of de maxaxleload, die het doet?

Verschillende voertuigen, auto en vrachtwagen, bij navigatie zit daar verschil tussen?

Maxwidth
Bebording: Wettelijk, maxwidth of als het op een bordje staat > 2m < maxwidth:physical
width tag gebruiken op de rijbaan.

geen, onbeperkt, dat kan niet.

maxaxleload
Is niet te meten, daar kan het niet voor op gaan.

Werkelijkheid de breedte van de rijbaan, width. (bestaande tag)
Meetbaar, ter plekke, is dat de beperkende factor, die men nodig heeft.
Afweging, maxwidth, staat er ook een width, die in de berekening route kan worden meegenomen voor emergency.

Dan heb je geen emergency=yes tag nodig voor dit mogelijke maxwidth probleem.

Het blijft access, niet wat of je er werkelijk langs kan.
Je zal het met width en load moeten oplossen.

Het probleem, zichtbaar, dat vaak wordt aangehaald onder de noemer “ground truth”, speelt bij emergency tags.

Voor emergency is een special access boom, naast de standaard access boom.
Je kan je eigen access boom gebruiken indien gewenst.
Hang onder elk transportmethode een emergency. Indien gewenst.

Is er ook een probleem naar Boksumerdyk 3. test.

Op dat wegdeel staat ook maxwidth maxaxleload. Boksumerdyk, kan dat er af? Er zal daar toch een onderbord onder hangen met over 1 km (dan kan het later, verversing data, nog eens worden getest, of het daadwekelijk maxwidth of maxaxleload is, die het probleem geeft, zonder de brug data te veranderen).
Of is daar ook de smoothness=bad op de track naar woning een item, naast access=no.

route

Wellicht:
Dan nog een ander punt. Bij Boksumerdyk 5

Wordt er voorrang gegeven aan track_type=grade 1 ( met nog 450 meter door weiland) t.o.v. van de track naar het huis toe grade 2.(300 m)
Wat is de kosten factor tussen deze twee grades?

Horen wegen naar woning toe highway service te zijn? Geen track.

Er zit nogal wat onduidelijkheid in gezien de conflicterende documentatie. Je zou hiermee emergency=yes op kunnen vatten als iets wat verder gaat dan een access-sleutel (buiten het gedocumenteerde gebruik voor bij amenity=hospital), maar dat is niet helemaal risicoloos. Hiermee leggen we wel heel veel neer bij de data-consumer, en je houdt de onduidelijkheid naar andere mappers toe: de tag documenteert niet wat deze beoogt te doen (daar is het hgv overriden, elders maxwidth).

In 2019 heeft Mateusz die tekst toegevoegd waar je naar verwijst. Je kan dat lezen als een highway=track of highway=path die geen obstakels heeft voor veiligheidsdiensten, maar het maakt niet expliciet dat hiermee van alles uitgezet wordt.

Ook is niet duidelijk of alles ook daadwerkelijk uit móét:


maxwidth=2.2
maxaxleload=2
hgv=no
emergency=yes

Wat wordt hier uitgezonderd? Alles? Of komt maxaxleload toevallig ook in de buurt van wat een brug daadwerkelijk aan kan?


maxwidth=2.2
maxwidth:emergency=none
maxaxleload=2
hgv=no
hgv:conditional=yes @ emergency

Nu zeg je duidelijk wat je uit zet. Een brandweerwagen kan hier langs, tenzij de asdruk boven de 2 ton ligt. Andere mappers zien ook wat je uit zet en vatten emergency=yes niet op als een tagfout („Oh, iedereen mag hier nu langs, dan is emergency=yes ook niet meer nodig. Dit zat er vast op van toen het nog een weg voor alleen bussen was.”).

Ja, maar geen access-waarde. Dat emergency=yes ook maxwidth=* uitschakelt rekt die tag wel erg op. Dat is niet zonder risico.

Nagenoeg alle wegen in Nederland zijn dat. None betekent niet onbeperkt, maar dat er geen expliciete maxwidth is ingesteld door de wegbeheerder (de wet heeft verder wel bepalingen voor wat er op de openbare mag en kan rijden). Dat is meestal zo, alleen hier maken we dat expliciet om de beperking voor veiligheidsdiensten uit te zetten.

Het lijkt me onverstandig om zelf allemaal praktische maximumbreedtes te gaan bedenken voor een weg door de weilanden. Je zit er makkelijk naast.

Je haalt twee punten uit mijn post door elkaar.

Dat gaat niet gebeuren. Wegbeheerders zien dit niet als hun probleem, en zeker niet iets wat ze gaan beborden. Voor de veiligheidsdiensten ligt de oplossing of in een andere manier van instellen van hun routeplanner (maar dan is het probleem van wel toegankelijk maar met beperkingen bebord niet opgelost; ze kunnen dan geen onderscheid maken tussen daadwerkelijke en juridische beperkingen), of een duidelijkere manier van tagging waarin zulke uitzonderingen staan. De uitzonderingen aanwijzen en definiëren laat ik het liefst aan de veiligheidsregio’s over.

Geen onderbord. Ik heb mijn rijbewijs en kan borden lezen, dank je.

Nee. Een routeplanner geeft sterk de voorkeur aan dichter bij de eindbestemming. Het scheelt hier 300m, daar gaat hij niet een tracktype2 voor ontwijken om kilometers om te rijden over tracktype1.

Het is een boerenerf. Die kan naar service, maar het maakt hier niet uit voor dit probleem.

Mooie discussie, veel woorden.
Hetgeen besproken is met een aantal veiligheids regio’s:

  • Liven-nav moet haar routering aanpassen aan OSM tags, en hier is emergency=yes niet een standaard!

  • Er moet zoveel mogelijk ground truth getagd worden, hier is echt een nadruk op geleggd in de workshop.

  • De tag emergency=yes mag alleen in uiterste gevallen gebruikt worden. (en meestal van tijdelijke aard zodat Live Nav haar routerings algoritmes kan aanpassen omdat het nog niet voorzien was

  • Bij niet functionerende routering kan contact gezocht worden met het forum, of op Direct message van een persoon. Dan zal bekeken worden of het een nalatigheid van Live-Nav is, of dat de mapper iets onjuist heeft getagd dat hij over het hoofd heeft gezien.

  • Terugkoppeling van de veiligheidsregio naar Live-Nav is een vereiste om de navigatie van Live-Nav op een hoger level te krijgen, en Live-Nav dient dan de algoritmes aan te passen, conform de OSM tagging (en niet andersom door emergency=yes veelvuldig te gebruiken!)

Er is een wiki pagina gemaakt die bijgewerkt kan worden, als er nieuwe inzichten komen, waar Live-Nav natuurlijk gebruik van kan maken.

https://wiki.openstreetmap.org/wiki/NL:Hulpdiensten

Verder wil ik niet in details treden, maar vind wel dat Live-Nav en de veiligheids regio medewerkers een verantwoordelijke taak hebben om het project voor Live-Nav te doen slagen! En daar kan OSM zeker een bijdrage in leveren!

Ik mis persoonlijk wel het persoonlijke contact met Live-Nav (daar moet gezegd dat 1 persoon van de workshop groep het contact wel heeft, en dit moet voldoende zijn)

Omdat de vragen nog steeds aanwezig zijn, en nu ook vanuit de community vind ik het zorg dat de richtlijnen voor alle partijen duidelijk moeten gaan worden.

Analoog aan wat bij de maxheight-sleutel gebruikelijk is zou ik hier kiezen voor de waarde default in plaats van none, precies om deze verwarring te voorkomen.

Al kan ik me specifiek voor emergency voorstellen dat je zegt: op grond van RVV is er geen beperking, dus het is écht none.

In het algemeen zou ik er vanuit gaan dat wat onder “by use” staat voorrang heeft op de rest, omdat ze specifieker zijn (emergency is specifieker dan hgv).

Dat lijkt inderdaad ook een geschikte waarde.

@Allroads:

Nog even een fietstochtje gedaan vandaag:

Ik ben ook wel benieuwd naar de reactie van LiveNav (met of zonder koppelstreepje?) over deze casus van de Boksumerdyk. Hebben we een contactpersoon die we kunnen aantikken?

Zou mooi als dat zo is, maar hoe lees je dat uit de boom af? Is dat een gedocumenteerde conventie? Zo staan ze in de boom met verhouding tot elkaar:


- Motorized vehicle
    - Double-tracked
        - hgv
    - By use
        - emergency


De beide categorieën hebben overlap (ladderwagens bijvoorbeeld zijn beide), maar de een omsluit de ander niet en v.v.

Ook misschien een puntje: een breedte zou ik hypothetisch kunnen opmeten, (uitgaande van een normale hoogte van het voertuig), maar als er niks op (onder)borden staat, zie ik niet in hoe ik kan vertellen welke verkeersborden daadwerkelijk de fysieke gewichts/aslast limieten aangeven van bijvoorbeeld een brug of ondergrondse garage, en welke overschrijdbaar zijn omdat ze bijvoorbeeld puur sluipverkeer willen ontmoedigen of slijtage willen beperken. Dus hoe bepalen we bijvoorbeeld of hulpdiensten wel over een brug heen mogen als ze buiten de door bebording aangegeven limieten vallen? Een brandweerauto die omrijdt is nog minder erg dan een brandweerauto die door een brug zakt, schat ik.

Dit is nu inderdaad niet gedocumenteerd, maar het algemene principe “specifiek gaat boven algemeen” is natuurlijk wel de achterliggende gedachte van hoe de boom is ingericht (en staat in dergelijke woorden beschreven bij Conditional restrictions). Wellicht is niet in alle gevallen duidelijk welke specifieker is, maar bij emergency versus hgv lijkt me redelijk triviaal dat emergency specifieker is.

Zoals al genoemd kan dit natuurlijk omzeild worden door emergency als condition in een conditional in plaats van als mode te gebruiken.

Teruglezend denk ik dat een melding bij gemeente in deze ook niet verkeerd is met het verzoek tot intrekken van de breedtebeperking en maximale asdruk en het verwijderen van de desbetreffende C18 en C20 borden.

Na controle of de gemeente heeft verzuimd deze borden te verwijderen na een verkeersbesluit kwam ik een ouder besluit tegen over de Boksumerdyk bij de aansluiting op de Newtonlaan:
https://zoek.officielebekendmakingen.nl/stcrt-2017-37278.html

Deze heeft bij uitvoering ook invloed op het adres van de melding.
Hierin staat als besluit onder andere:

Mogelijk is er bezwaar aangetekend en goedgekeurd (wordt dit ook gepubliceerd? want deze kan ik niet vinden), maar dit besluit is nooit uitgevoerd en deze borden zijn naar mijn weten nooit geplaatst.

Over emergency=* ben ik ook niet helemaal tevreden.
Wat doen we als in de toekomst andere hulpdiensten ook gebruik van de database willen maken?
Dit is los van de bezwaren die hier in het verleden al kenbaar zijn gemaakt door meerdere mede-mappers niet uit te sluiten.
Met emergency=yes zal dit wel loslopen omdat de brandweer de grootste wagens bestuurd.
Maar wanneer iets als emergency=no wordt aangeduid dan is niet duidelijk dat het alleen de grotere wagens betreft en kan de ambulance er wellicht wel langs (of misschien wel niet).

Zeker! Die borden kloppen nu ook al niet meer, omdat de Redbadwei nu aansluit op de Boksumerdyk. Hun bereik is dus onduidelijk nu. Heb je een melding gedaan toevallig?

Ja dat is gedaan, de borden staan er, maar dat gaat om dit stukje Boksumerdyk.

Dat is wat raar verwoord daar, maar dat komt omdat het om slechts een klein deel gaat van een weg, 50m of zo, die als Nylânsdyk verder gaat in gemeente Waadhoeke. Dat hele stuk is een G12a sinds een paar jaar, met onderbord met uitzonderingen:

(Verder gaat deze draad natuurlijk breder dan de Boksumerdyk.)

Daarom lijkt me een duidelijk stukje beleid handig. Ik wil/kan zelf als mapper helemaal niet in schatten of een wettelijke beperking door veiligheidsdiensten veilig opzij gezet kan worden; een goed uitgangspunt lijkt me dat de veiligheidsdiensten dat (via de veiligheidsregio’s) zelf aangeven zoals ze dat nu al doen. Wij assisteren daarbij.

Qua tags lijkt het me dan wel belangrijk om voor de bovengenoemde punten een richtlijn te documenteren op die pagina. Misschien maar even een concept opstellen met de bevindingen uit deze draad?

Wat ik me nog bedacht is dat source-tags ook verstandig kunnen zijn:


maxaxleload=2.2
maxaxleload:emergency=default
maxwidth=2
maxwidth:physical=2.8
maxwidth:emergency=default
source:emergency=Veiligheidsregio Fryslân
source:emergency:date=2022-06-25

Dat is wel complexer, maar omdat dit uitzonderingen zijn lijkt het me wel verstandig om ze ook ter plekke te documenteren. Als ze in belang toenemen, dan moet de tagging niet ambigu zijn, de herkomst duidelijk, en de signaalfunctie naar mappers sterk (dat wil zeggen, ze stralen uit dat ze er niet zomaar staan).

Ook bij een eenvoudig voorbeeld beperkt tot enkel toegangstags kan dat zo:


access=no
psv=yes
emergency=yes
source:emergency=Veiligheidsregio Fryslân
source:emergency:date=2022-06-25

(Voor een busdoorgang zonder fysieke beperkingen.)

Voor de goede orde: wat we hier bespreken zorgt ervoor dat wegsegmenten door de routeplanner van veiligheidsdiensten als ‘normaal routeerbaar’ behandeld worden. Zij hebben ten alle tijde de mogelijkheid om wettelijke beperkingen naar eigen inzicht ter plekke te negeren. Een ander standpunt kan zijn dat wij dit helemaal niet willen faciliteren, maar met duidelijke tagging vind ik het niet bezwaarlijk en ook wel interessant om te zien hoe onze data geschikt kan zijn voor veiligheidsdiensten.

Dit heb ik niet gedaan

Ik reageer even via PM om on-topic te blijven.

Het maakt het bewerken voor mappers van de veiligheidsregio’s wel complexer.
Ondanks deze complexiteit vind ik het een goede manier om het weer te geven.

Ik vind die *:emergency=default ook een mooie vondst:
het maakt specifiek per soort beperking (breedte, lengte etc.) expliciet dat er geen bijzondere beperkingen gelden,
en vaak is het makkelijker om te bepalen dat een niet-exceptioneel voertuig geen belemmeringen tegenkomt dan om de exacte maximale breedte etc. te bepalen.
Zelfs met meetappartuur is dat laatste lastiger dan je denkt omdat je dan iets driedimensionaals in 1 getal moet gaan vatten, heb best wat doorvaarthoogtes aan bruggen gemeten, maar die kunnen zowel in het dwars- als in het langsprofiel verlopen en zowel de laagste als hoogste waarde zijn lang niet altijd maatgevend (laagste waarde an de zijkant waar je toch niet komt, hoogste waarde slechts op een te smal stuk om onderdoor de kunnen…)

En het =default lijkt ook preciezer dan =none, want het aangehaalde RVV-artikel geeft nooddiensten wel ontheffing voor de verboden die volgen uit RVV-borden, maar nog niet voor de eisen aan maximale afmetingen voor voertuigen in de Regeling Voertuigen, dat gebeurt met ontheffingen voor exceptioneel transport.

Ik ben hier op de wiki aan een uitbreiding van NL:Hulpdiensten begonnen met de punten uit deze draad. Je kan de diff hier bekijken.

Ik vermijd in eerste instantie links naar Nederlandstalig versies van andere wikipagina’s, want deze lopen momenteel soms jaren achter.

Mis ik in dit rijtje nog andere fysieke beperkingstags die voor hulpdiensten soms overschrijfbaar kunnen zijn?


Omschrijving         Wettelijk         Effectief 
-------------------------------------------------------------
Maximumasdruk        maxaxleload=*     (zelden gebruikt)
Maximumgewicht       maxweight=*       (zelden gebruikt)
Maximumbreedte       maxwidth=*        maxwidth:physical=*
Maximumlengte        maxlength=*       (zelden gebruikt)
Maximumhoogte        maxheight=*       maxheight:physical=*