Emergency=yes op wegen

Beste medemappers,

Graag zou ik de huidige situatie met betrekking tot emergency=yes op wegen willen discussiëren. Het zou aan mij kunnen liggen maar ik stoor mij aan de manier waarop emergency=yes wordt toegevoegd aan wegen.

Zover als ik het zie zijn alle wegen toegankelijk voor hulpdiensten. Tenzij, er iets in de weg zit of de weg niet geschikt is, dat kan natuurlijk van alles zijn, zoals paaltjes, trappen of een brug die het gewicht niet aankan.

Naar mijn menig dienen deze attributen als eerst in kaart gebracht te worden. Pas als het niet meer mogelijk is om attributen toe te voegen zou er bijgestuurd kunnen worden met emergency=*.

Wat ik nu zie gebeuren is precies het tegenover gestelde, als een fietspad breed genoeg is voor hulpdiensten dan wordt emergency=yes toegevoegd. En de breedte wordt vergeten. Is een fietspad smal dan wordt er niks toegevoegd. In winkelstraten met highway=pedestrian, word soms ook emergency=yes toegevoegd, terwijl highway=pedestrian al aangeeft dat het mogelijk is om er te kunnen komen met een autovoertuig.

Uiteraard zeg ik hier niet mee dat alle emergency=yes op wegen incorrect zijn, er zijn zeker wegen met onderbord: uitgezonderd ambulance. Dan zie ik het wel als correct. Verder heb ik er op paatjes ook niet z’n probleem mee.

Graag zou ik van jullie willen weten: Hoe staan jullie hierin? En wat voor ideeën hebben jullie om dit aan te pakken?

1 Like

Niet helemaal. Een pedestrianized straat is een straat waar auto’s ooit reden, maar waar dat teruggebracht is tot alleen bevoorrading met venstertijden bijvoorbeeld, maar soms ook helemaal autovrij door het plaatsen van (al dan niet verplaatsbare) barrières. Bij die wegklasse snap ik emergency=yes wel enigszins, hoewel het niet ideaal is. Liever inderdaad de fysieke beperkingen in kaart brengen.

Ik vermoed dat de behoefte van emergency=yes zo toegepast is om positief te kunnen stellen dat een weg geschikt is voor nooddiensten. Terwijl barrières en fysieke beperkingen juist wegen uitsluiten. Kunnen we een alternatief bieden voor die emergency=yes op basis van de fysieke tags? Wat missen de mappers (veiligheidsregio’s?) die dit toepassen nu?

Bij fietspaden is het wat suspect. Daar zie ik inderdaad liever dat de route gewoon duidelijk is aan de hand van de fysieke attributen (width zeker!). Je hebt wat dat betreft zeker een punt.

Is het gebruik niet een beetje overgewaaid, van gebruik op bospaden, veelal achter een hek, naar de openbare weg.

Bospad, geschikt om er gebruik van te maken.

Paaltjes, met het zetten van een access tag, geef je het fysieke passeren aan, passeerbaarheid. Voor een paaltje is dat, het er langs gaan, zonder het paaltje te verwijderen. Bij een gate kan je verwachten dat het dicht zit en moet worden geopend. Bij emergency=yes zou je geen andere handelingen verwachten als bij andere vervoersvormen, emergency=yes zou dan inhouden je hoeft het paaltje niet te verwijderen je kan er zo langs, dezelfde werking als bij andere access vormen.

Er wordt zo een andere werking gegeven aan het *=yes gebruik.

key emergency wiki

Waar ik me aan stoor, zijn mappers, die bereid zijn zand in de machine van de navigatie software van hulpdiensten te strooien.
Nota bene, de meest nuttige toepassing van OSM, gebruikt worden door de navigatiesoftware van de hulpdiensten, en dan wil jij obstructie plegen.
Er zijn bepaalde tools, die OSM volstorten met onzintags, geheel in de zin van de voormalige adviseur van Trump, “flooding the zone with shit” en daar wordt niet over gepraat. Maar cycleway:both=no om maar een voorbeeld te noemen, is een complete onzintag.
En als er al iets aangepakt kan worden, dan is het die onzintags.
Emergency=yes wordt oa, zo heb ik het begrepen, door medewerkers van de hulpdiensten gebruikt, om aan de navigatiesoftware te vlaggen, dat die weg geschikt is voor navigatie. En dat gaat ook op basis van zaken, die niet vastliggen in OSM, zoals bochten, weginrichting, etc.
Nu is er een tag, emergency=yes, waarmee de navigatiesoftware vlot kan bepalen of die weg wel of niet gebruikt kan worden en jij wil die software het bos in sturen, kijk naar parameter dit, parameter dat, etc. Dat kost extra tijd voor die software.
En verder, er is tag vrijheid.
De wiki is niet een bijbel, waar exact vastligt van zo en zo moet het.
De wiki legt de common practice vast, zo doen de meeste mappers het op het moment van vastleggen.
Dus wat de wiki over emergency=yes zegt, kan ook aangepast worden.

En mij stoort emergency=yes niet, ik weet dat het voor een hele nuttige toepassing is.

Het kost nagenoeg geen extra tijd voor software om meerdere attributen te vergelijken. Dat is geen goed argument hier.

@Tjuro merkt terecht op dat emergency=yes geen duidelijke betekenis heeft buiten toestemming en basale geschiktheid voor hulpdiensten. Daar valt niet op lange termijn stabiel mee om te gaan, zeker omdat het nu op verschillende manieren gebruikt lijkt te worden. Zo krijg je een situatie waar niemand meer aan een emergency=yes durft te komen bij een herinrichting of aanpassing van de situatie. Het moet altijd mogelijk zijn om te begrijpen waarom bepaalde tags ergens staan.

Dit is een voorbeeld van het wel moet:

highway=unclassified
maxwidth=2.0
maxwidth:emergency=3.0
source:maxwidth:emergency=Veiligheidsregio Fryslân

Netjes aangegeven dat bredere brandweerwagens daar fysiek wel langs kunnen, ondanks de wettelijke beperking. Bron erbij, zodat je ook goed kan inschatten wat daar speelde.

1 Like

@dvdhoven Ik had aangegeven graag het onderwerp te willen discussiëren. Maar in jou reactie staat geen enkel fatsoenlijk argument, alleen maar drogredenen, meningen en aannames.

Aanname en ad hominem

Menig, ad hominem en aanname

Drogreden appeal to worse problems, totaal irrelevant.

Is het dan in scope van OSM of niet en zo ja, wat is de reden dat deze attributen niet in OSM kunnen bestaan.

Een deel van het werk wordt verplaatst van de voorkant, (het beslissen of iets wel of niet emergency=yes is) naar de achterkant (de routering).

Zoals ik al had aangegeven ben ik niet tegen emergency=* maar wel tegen de huidige manier waarbij er niet eerst gekeken wordt naar andere attributen zoals, doorrijhoogte, maximaal gewicht, breedte, etc.

Een goed voorbeeld zijn fietstunnels, vaak is het mogelijk om met een dienstauto door de tunnel heen te rijden. Maar er is niet altijd genoeg hoogte voor een ambulance. Het los aangeven van de maximale hoogte geeft dan aan welk voertuig wel en niet door de tunnel kan.

Een ander voorbeeld is routering voor skeeleren, dan taggen we ook niet rollerblade=yes op elke weg/pad wat geschikt is. We taggen de smoothness=, surface= en op basis daarvan kan je concluderen of een pad/weg wel of niet geschikt is.

3 Likes

Ik was redelijk nauw betrokken bij de gesprekken met/over de toepassing van OSM voor de software voor veiligheidsregio’s. Ik ben het ermee eens dat dit een voorbeeld is van een impactvolle toepassing waarbij OSM daadwerkelijk serieuze meerwaarde heeft.

De tagging moest heel goed afgesproken worden, rekening houdend met de mogelijkheden van de ingeschakelde medewerkers van de veiligheidsregio’s, en rekening houdend met de ietwat chaotische natuur van hoe OSM gevuld en bijgehoden wordt.
Dat gaf een gemengd beeld. De invoer (mappen en taggen) van de gegevens die nodig zijn om het helemaal zonder emergency-access-tagging te doen was mogelijk, maar niet eenduidig of gemakkelijk, ook bedenkend dat mappers niet allemaal hetzelfde over dingen denken.

Wat de veiligheidsregiomensen doen, is tijdens het werk en tijdens controlerondes op straat beoordelen of een doorgang mogelijk is of niet, gegeven allerlei dingen die daarop van invloed kunnen zijn. Vervolgens moeten ze dat op een snelle eenvoudige manier in OSM kunnen vastleggen. Dat is dus een totaalbeoordeling, een inschatting. Naar mijn mening had daar een speciaal hierop gericht kenmerk voor gemaakt moeten worden, met de betekenis: gecheckt en geschikt bevonden voor hulpdiensten, met een datum erbij.

En dan zo, dat niet alleen deze service erdoor ondersteund wordt, maar ook andere services. Want je wil OSM niet taggen voor één bedrijf of toepassing, maar wel om bepaalde toepassingen mogelijk te maken.

Dat is niet gebeurd. Het toevoegen en in de software gebruiken van alleerlei fysieke kenmerken waaruit de doorgankelijkheid on the fly bepaald kan worden is niet heel scherp tot stand gekomen. De emergency tag wordt toenemend gebruikt om aan te geven dat objecten toegankelijk én geschikt zijn voor hulpdiensten - overigens was dat vóór dit project ook al aan het gebeuren, en ook andere access tags kennen dit verschijnsel.

Is dat erg?

Het klopt dat emergency=yes eigenlijk als een (juridische) access tag ingeschaald is. Als je daar strikt aan vasthoudt, heb je hem nooit nodig, omdat hulpdiensten in noodgevallen zich niet aan de juridische accessregels hoeven te houden. Het enige geval waar je het zou kunnen gebruiken is als uitzondering op access=no op een object waar je fysiek wel in/door/over zou kunnen rijden.

Ik vind het daarom niet gek en niet erg om de toepassing van deze tag te verruimen naar toegankelijk én geschikt voor voertuigen van nooddiensten, als daar het systeem van zelf checken en bijhouden voor deze belangrijke toepassing tegenover staat. Dat maakt het hanteerbaar en zonder beslisbomen eenduidig bruikbaar voor alle direkt betrokkenen, zonder OSM-savvy te hoeven zijn.

Met andere woorden: het is het waard. Strikt vasthouden aan pure juriscische access en vereisen van invoer en bijhouden van precieze fysieke kenmerken helpt zo’n toepassing om zeep, want spontaan gebeurt het niet met zekerheid en OSM vereist dat doorlopend mensen getraind worden, ten koste van de kerntaken. Een goedkeuringscheck en per object een vink zetten is begrijpelijk, nuttig en haalbaar, en vergt weinig training.

2 Likes

Emergency=yes is een nutig en eenvoudig te gebruiken tag.
Met name de veiligheidsregio kan daarmee aangeven dat een brandweerauto of een ambulance deze highway wel kan gebruiken in afwijking van de tags die een belemmering vormen.

Het gebruik ervan op een way die al toegankelijk is voor alle verkeersdeelnemers is natuurlijk overbodig.

Het aanbrengen van allerlei fysieke kenmerken als hoogte, breedte, wel of niet haalbare afslag is veel te ingewikkeld om ooit een succes te kunnen worden.
Hier geldt met veel nadruk: keep it simple.

Verwijderen van de tag emergency=yes is alleen correct als er duidelijk sprake is van misbruik.
En dat ben ik nog maar zeer zelden tegengekomen.

1 Like

Ik heb deze tag nooit gebruikt. Niet omdat ik het niet nuttig vind maar meer omdat ik me er niet erg in heb verdiept en dat ik net als Tjuro dacht dat het toevoegen van fysieke kenmerken zoals maxheight, maxwidth, maxweight etc. wel voldoende zou zijn. Ik heb net even de wiki gelezen maar zo eenvoudig vind ik het niet. Het komt mij heel erg subjectief over wat kan leiden tot nogal was verschillen in interpretaties.

Of een weg in algemene zin toegankelijk is hangt m.i. af van juridische en fysieke beperkingen. Met juridische beperkingen hebben hulpdiensten niets te maken en dus blijven m.i. alleen de fysieke over. Zou iemand mij dan een voorbeeld kunnen geven waar ground truth fysieke access tags niet toereikend zijn?

Ik lees dat het gaat om “emergency vehicles”. Ik neem even aan dat hier politie, brandweer, ambulance mee bedoeld wordt. Met welk gewicht, breedte, hoogte van zo’n vehicle moet ik dan rekening houden voor het wel/niet toevoegen van een emergency=yes op een weg? Of wordt er altijd rekening gehouden met de maximum waardes? Misschien een brede /zware en hoge brandweer wagen?

In OSM taggen we o.b.v. ground truth. Dus kan ik tags toevoegen. Maar ook verwijderen. Als ik o.b.v. ground truth emergency=yes wil checken waar moet zo’n situatie dan aan voldoen wil ik met een gerust hart deze tag verwijderen of toevoegen?

Stel ik heb een weg waar ik over een brug moet en meteen daarna door een tunnel. De brug is x meter breed, mag y ton dragen en de tunnel is z meter hoog. Bij welke combinatie van tags zou er dan een emergency=yes/no getagd worden?

Ik snap heel goed dat routing voor hulpdiensten belangrijk is en dat OSM daar aan bij kan dragen maar ben wel benieuwd hoe nuttig deze tag nu in werkelijkheid is. Misschien dat iemand van de hulpdiensten daar nog iets over kan zeggen.

2 Likes

Onbekend, ongedocumenteerd, en mapper-afhankelijk.

Dit is een belangrijk punt. emergency=yes kan op zichzelf nooit zeggen of ergens de zwaarste en breedste brandweerwagen langs kan. Als het zo wel gebruikt wordt, krijg je op een gegeven moment vervelende situaties.

Dit gaat helemaal mis wanneer emergency=yes ergens gebruikt wordt als toegangstag. Rondom ziekenhuizen bijvoorbeeld. Daar zegt emergency=yes niets over geschiktheid voor alle voertuigtypes.

Een kale emergency=yes is een quick-fix. Een workaround om een technisch probleem voor nu even snel op te lossen. Maar het is geen duurzame oplossing om de bovengenoemde punten. Bij veranderende situaties wordt die tag of overgenomen op de nieuwe situatie (want de mapper durft hem niet weg te halen), of verwijderd terwijl hij wel nodig is (want de mapper ruimt een oude situatie op en tekent een nieuwe in), of blijft onterecht staan terwijl de nieuwe situatie wel beperkingen met zich meebrengt (de mapper blijft van die tag maar af, want eng!), en weer een andere mapper (lokaal of uit een ander land, al dan niet via een StreetComplete-achtige tool) verwijdert ze integraal van fietspaden (want die weet niets van dit afwijkende gebruik, en daar is toestemming voor hulpdiensten immers geïmpliceerd).

Mappers kúnnen ook niet goed inspelen op die tag, want hij zegt zoals het nu voorgesteld wordt alles en niets tegelijk.

Dit kan geen gewenste manier van werken zijn. En het lijkt me ook niet nodig. Wij kunnen prima adviseren en documenteren wanneer er oplossingen nodig zijn voor veelvoorkomende situaties. De :emergency tags die juridische beperkingen oprekken voor hulpdiensten zijn daar een goed voorbeeld van.

2 Likes

Ik heb als lid van de OSM community geen inzage in de manier waarop LiveNav z’n routingscripts doorvoert. ‘We’ hebben geen contact met LiveNav… alleen met de VRmappers… die overigens ook niet van de hoed en de rand weten.

Ik verwijs VR mappers steeds weer opnieuw naar LiveNav.
Zelfs heb ik meegemaakt dat een VR mapper op zijn vingers werd getikt door de appbouwer toen hij te veel losliet.
Er zal ongetwijfeld concurrentie zijn op die ‘markt’.

Dat maakt het ook heel lastig om nieuwe VR mappers goed te informeren.
Nog een groot nadeel van het mappen voor LiveNav is dat alles met editor iD gaat. Het is een probleem om JOSM te ‘mogen’ installeren op het netwerk van de kazerne.
Resultaat is dat regelmatig routerelaties beschadigd raken.

Met een aantal VR mappers heb ik overigens prima contact en ze vragen regelmatig om een review.
Tja… en emergency=yes werkt dus niet altijd.
Bruggen die geen max_weight in de tagging hebben zouden niet routeren volgens een VR mapper.

Maar ik weet nog steeds niet of barrier= bollard icm bollard=foldable nu wel of geen emergency behoeft.
Zelfs emergency=no komt voor als de route ongewenst is.

De vraag of de VR wel ‘moet’ routeren met als basis OSM is voorlopig een gepasseerd station. Het gebeurt al.

1 Like

Het gebrek aan communicatie buiten goed contact met aantal Veiligheidsregio-mappers is zeker verontrustend. LiveNav mag echt wel eens wakker worden op dat vlak.

Typisch zo’n bug waarbij het heel nuttig zou zijn als de softwareleverancier hier ook eens reageert. Misschien dat de Veiligheidsregio-mappers daar eens op aan kunnen dringen?

Ten overvloede nog maar eens de Nederlandse wiki pagina van de hand van Lachgast.

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

2 Likes

Oh ja, die is er ook natuurlijk. Daar staat alles ook goed gedocumenteerd.

De laatste paragraaf vat ook goed samen waarom we emergency=yes niet als een simpele ‘geschikt voor hulpldiensten’-tag kunnen gebruiken:

Waarom kan emergency=yes niet gewoon alle beperkingen overschrijven?

Het is verleidelijk om met data-consumers zoals LiveNav af te spreken dat een simpele emergency=yes op een weg deze weg geschikt maakt voor hulpdienstennavigatie. Hier kleven echter een aantal nadelen aan:

  • Dit sluit niet aan bij de essentie van emergency=* wanneer toegepast op wegen en barrières; namelijk dat van een toegangswaarde voor een vervoersmiddelencategorie. emergency=* is hier de verkorte en voorkeursvorm van access:emergency.
  • Welke van meerdere fysieke beperkingen overschreven wordt (bijvoorbeeld bij een maxaxleload=* én een maxwidth=*), is niet duidelijk uit deze enkele tag.
  • Bij gebruik om enkel fysieke beperkingen te overschrijven doet de tag iets wat buiten de conventies valt, en wat andere mappers er toe kan bewegen de tag te verwijderen (want immers overbodig bij access=yes of geen access=*) — al of niet op basis van geautomatiseerde quality assurance tools.
  • Onduidelijk of bij het overschrijven van bijvoorbeeld maxwidth=* (de beborde siatuatie) ook maxwidth:physical=* overschreven moet worden.
  • Wanneer een mapper op basis van veranderende bebording nieuwe fysieke beperkingen aanbrengt, zou deze emergency=yes de nieuwe beperking ook automatisch overschrijven. Of dat ook werkelijk mogelijk is, kunnen wij als leken vaak niet goed beoordelen.

Het is nog specifieker: de tag zoals die nu wordt gebruikt geeft aan dat de weg, de barrier of het gebied bij controle door de dienst zelf geschikt is bevonden voor een bepaalde hulpdienst (of set van hulpdiensten) die daar opereert.

MI is dat een belangrijk gegeven, en ook noodzakelijk om voldoende betrouwbaarheid te hebben om er hulpoperaties op te kunnen baseren. Juist daarom zou ik het liever op een veel specifiekere manier vastleggen, namelijk zo dat het de goedkeuring, de datum van het goedkeurstempel, en de goedkeurende instantie aangeeft. Voor de applicaties is dan alleen het goedgekeurd zijn van belang: één tag die dezelfde functie heeft als waar nu emergency=yes voor is gekaapt.

De rest is voor verificatie, inschatting van achterstanden en voor planning van controlerondes, dwz qc en qa ten behoeve van de betrouwbaarheid.

Je krijgt dan iets als
emergency_approved=2025-02-01
emergency_authority=Veiligheidsregio Twente

En dat hoeven ze dan alleen te zetten op objecten waar het niet vanzelfsprekend is dat ze erlangs kunnen.

Overal bruikbaar, en omzetten van bestaande gegevens is niet heel moeilijk. De dienst kan beginnen met alleen het toevoegen van de nieuwe tags tijdens geplande controles. De toepassing kan om te beginnen handelen op emergency=yes én emergency_approved=*.

Voor de medewerkers die de controles doen zou ik een tool aanbevelen waarbij je het onderweg snel kan invoeren. Het zou een streetcomplete-achtige tool kunnen zijn, of een mapcomplete-thema. Of old-school, een plattegrond op een opzichtersclipbord, waar je groene vinkjes en rode kruizen op kalkt die daarna op het kantoor worden ingevoerd. Foto’s nemen, ook altijd goed.

Je legt dan de besluitvorming over de geschiktheid buiten de data, en maakt die gelijk onverifieerbaar.

Bekijk het voorbeeld van de Veiligheidsregio Fryslân hierboven nog eens:

highway=unclassified
maxwidth=2.0
maxwidth:emergency=3.0
source:maxwidth:emergency=Veiligheidsregio Fryslân

Hier wordt expliciet een specifieke juridische beperking opgeheven die navigatie tegenhield, maar niet gelijk ook maxweight. Dit kon, omdat de Veiligheidsregio vaststelde dat die breedte fysiek wel beschikbaar was, en de juridische beperking er hangt vanwege andere redenen. De source is ook netjes benoemd.

Dit is wat op de wikipagina ook gedocumenteerd staat, en wat ook al toegepast wordt. Er zijn geen nieuwe top-level tags nodig, en emergency=yes misbruiken/oprekken is ook niet nodig. Sowieso is dat laatste een heilloze weg, want menig brug met een maxweight of maxaxleweight in combinatie met toegangsbeperkingen mag wel door hulpdiensten gebruikt worden, maar niet door alle wagens. Zwaartekracht hef je immers niet op met emergency=yes of emergency_approved.

Dat legt de beoordeling bij de belanghebbenden, zonder allerlei details vast te hoeven leggen. De appbouwer kan daar vervolgens op rekenen, zonder met allerlei details rekening te hoeven houden. Dus hoe de emergency=yes nu gebruikt wordt, maar zonder de echte functie van emergency=yes aan te tasten.

Een datum erbij, dat is bonus, tbv het bijhouden/herbeoordelen.

Als de mogelijke beoordeling enkel bij de invoerders ligt, hoort de tag niet in OpenStreetMap-data thuis. Dan kunnen ze veel beter die tag toevoegen bovenop OpenStreetMap-data op basis van de way-id’s. Je creëert zo namelijk een enorm zwaarwegende tag waarvan de werking totaal onzichtbaar is.

Wanneer kun je hem weghalen als mapper? Wanneer moet dat zelfs? Wanneer moet je er van af blijven?

Wij passen van alles aan op de kaart, van snelwegen tot de kleinste paadjes. We werken winkels bij, maar zorgen ook dat de kaart bij blijft bij complexe wegenbouwprojecten. Soms verwijder je in een keer meerdere ways wanneer de afsluitingsdatum gekomen is, en teken je nieuwe wegen in in verschillende fasen. Daar past een ontransparante ‘nood’-tag niet bij.

Waarom zouden we het project daarmee op willen zadelen? We hebben al een werkende methodiek waarbij de specifieke opgeheven beperkingen duidelijk zijn. Alleen wil LiveNav daar niet aan?

3 Likes

Het ligt iets genuanceerder dan dat. Kernpunt is werkbaarheid. Als alle participanten ideale mappers en gebruikers waren, kon je veel meer doen dan in de praktijk werkbaar is.

emergency=yes op deze manier gebruiken is niet transparant. De methodiek die ik als voorbeeld schetste maakt het meer transparant en controleerbaar, uigaande van de al gegroeide praktijk.

Ik ben het met je eens dat het theoretisch beter zou zijn om dit gegeven bij de applicatie op te slaan - maar dat is niet gebeurd. En nu is het theoretisch zo dat andere data users het gegeven ook kunnen gebruiken. Aleen weten ze dan niet hoe het tot stand gekomen is en wat het precies betekent, en dat kunnen ze ook niet navragen want het gebruik is niet transparant.

Ik kan me in deze uitspraak helemaal vinden. Als er een tag komt die alleen door VR’s gebruikt mag worden, hoort deze m.i. niet in OSM thuis.

3 Likes