LiveOp moet zich aan OSM houden, niet andersom. Ze kunnen hun routering gewoon aanpassen als er iets niet klopt.
1 Like
Ik snap wat je zegt - en het is in feite niet anders als wat ik in een eerdere discussie over BTCmap ook opmerkte:
Ietwat ge-edit om naar de huidige situatie aan te passen, gaat immers over eigenschap van een POI ipv de POI zelf. 
Wat ik aanneem dat speelt voor BTCMap durf ik ook aan te nemen voor LiveOp: het is makkelijker om alle info die je nodig hebt uit één bron te halen, maar strikt genomen heb je (@Peter_Elderson) gelijk dat het er niet in alle gevallen in thuishoort op OSM. Als het geen eigenschap van het object is, klinkt als een mooie scheidingslijn.
Maar, dat gezegd hebbend, deze ligt de interpretatie van deze scheidingslijn wel lastiger en genuanceerder dan ik 'm bij BTCMap vond liggen. Want of de nooddienst het obstakel kan passeren kan wel een eigenschap zijn van het object. Het eerder genoemde SOS toegang is daar een voorbeeld van. Andere toegangsmethoden die door de hulpdiensten gebruikt kunnen worden zijn dat ook (standaardcilinder zoals driehoek of vierkant, brandweercilinder, aanwezigheid van brandweerkluis of andere nood-opener, etc).
Enerzijds is dat niet altijd voor een leek waarneembaar, anderzijds vindt ik het persoonlijk passend om te zorgen dat dit (net als zo veel mogelijk andere tags) “iteratief” kan worden getagt. Dwz: eigenschappen eerst op hoofdlijn/in algemene zin toe te voegen en vervolgens verder te verfijnen.
Dwz: vergelijkbaar met de analogie vanuit sidewalk of cycleway (nav deze discussie): het moet zo simpel kunnen zijn als in eerste instantie algemeen aangeven dát toegang voor de hulpdiensten gefaciliteerd is - om vervolgens voor de liefhebber/expert/geef-het-beestje-een-naam óók de mogelijkheid te bieden om te specificeren hoe dat geregeld is.
Net als iemand kan beginnen met sidewalk=yes/right/left/no om aan te geven dat er een stoep is. Dat is toegankelijk en begrijpelijk voor zelfs een beginnend mapper en kent door z’n eenvoud een beperkte foutgevoeligheid.
Een gevorderder (of meer detail-georiënteerde mapper die van stoepen z’n ding heeft gemaakt), kan het vervolgens zo gek maken als 'ie wil met sidewalk:*:surface=*, sidewalk:*:smoothness=*, sidewalk:*:width=* of est_width=*, sidewalk:*:bicycle=*, sidewalk:*:incline=*, sidewalk:*:kerb=*, sidewalk:*:wheelchair=*, sidewalk:*:tactile_paving=*, sidewalk:*:traffic_sign=* - en weet ik wat niet nog meer - om de nuances in kaart te brengen.
Datzelfde zou wat mij betreft ook moeten gelden voor deze situatie. En dat kan al, door emergency=yes op hoofdlijn te gebruiken, en dan bijv. (als ik het tagging schema van AED’s volg) locked=* voor een verdere verfijning.
Daar sta ik achter, maar dat is dus feitelijk al een verfijning. Stap 1: ja, de paal is wegklap- of wegneembaar voor de nooddiensten. Stap 2 is hoe dat gebeurt.
Qua consistentie zou ik dan pleiten voor locked=* (zie boven), en/of emergency:unlock (en dan met een postfix ipv een underscore, zoals gebruikerlijker lijkt bij tags die op een dieper niveau details toevoegen aan iets wat op hoofdlijn al gespecificeerd is).
Overigens is het gebruik van emergency=yes wel gedocumenteerd en goedgekeurd als ik Key:emergency - OpenStreetMap Wiki goed interpreteer:
Die laatste (de code-optie) kun je overigens ook uitleggen als “niet eigenschap van het object”. Want is het de gebruiker die de code heeft of het object dat de code accepteert? In zekere zin geldt dat eigenlijk ook zo voor een sleutel.
Begrijp me niet verkeerd, ik snap echt waar je vandaan komt, maar vind het grijs genoeg om er in dit geval geen punt van te maken. Zeker omdat we het bijv. voor wegen en andere variaties wel al toestaan - je kunt dit echt allebei de kanten op uitleggen.
Onderaan de streep denk ik dat we er trots op mogen zijn dat OSM in Nederland zo goed, nauwkeurig en actueel is dat het aantrekkelijk is voor hulpdiensten om er gebruik van te maken tov alternatieven en het willen verrijken met dit soort informatie (wat we accepteren voor wegen etc en andere plekken waar toegang geldt, en dan alleen hiervoor evt niet).
Ik zou er dan ook voor willen pleiten dat we vooral kijken wat er wél mogelijk is (zeker in een grensgeval als dit) en ons te veel verliezen in bikeshedding. Idealiter gaan we nog een stap verder en treden we hierover in overleg met LiveOp (of eigenlijk: idealiter zij met ons, zoals SOS Toegang wel deed, maar het kan niet altijd feest zijn ), kunnen we behoefte en juiste implementatie op elkaar afstemmen en documenteren.
Maar tot die tijd, lijkt het mij in ieder geval prima om waar nodig en van toepassing emergency=yes op barrier’s te zetten. De verantwoordelijkheid om dat kloppend te houden ligt dan bij veiligheidsregio’s, maar die nemen ze de facto al.
1 Like
Dat is er in december 2022 bijgeschreven, maar ik denk niet dat dat een consensus weergeeft. Als ik me goed herinner was de teneur van de discussies eerder dat emergency=* speciale wettelijke access weergeeft waar die normaal gesproken niet is.
In ieder geval vind ik het geen goed idee om het sleutelbezit van een heel specifieke usergroep op de OSM-objecten te mappen met een access tag. Ik denk dat het goed werkt als we de soort barriere en de wijze van passeren taggen, en dan kan de navigatie aan de hand van het gebruikersprofiel bepalen of dat te passeren is voor hulpvoertuigen.
Net zoals die kan bepalen of een eenrihtingsvoer voor het betreffende voertuig gerouteerd kan worden.
Als je aan de barriere ook specifiek kan zien welke speciale sleutel/app/button/… hem opent, kan de navigatie dat ook in de route tonen en melden.
Dat lijkt me veel zuiverder én nuttiger.
Ik kan me herinneren dat een aantal jaren geleden, de Veiligheidsregio IJsselland al sleutelgegevens bij de bollards zette. Maar welke tag en welke bollards, dat weet ik niet meer. Wel dat er dan bijv. Utrechtsleutel bij stond. IJsselland was een voorloper met OSM gebruik.
1 Like
Ik kan meegaan in het relaas van roelant. Het is een gegeven dat sommige paaltjes alleen verzinken voor hulpdiensten of verwijderbaar zijn door hulpdiensten. Te denken valt bijvoorbeeld bij een CADO (Calamiteitendoorgang).
Het klopt wel dat binnen LiveNav nog extra zwaarte kan worden gegeven aan bepaalde wegen. Naar ik meen wordt ook de wegopbrekingsinformatie van Melvin meegenomen in LiveNav. Zodoende wordt de navigatie naar de bestemming zo voorspoedig mogelijk.
Nog even teruggrijpend op de aanleiding van deze discussie: het toevoegen van een adviessnelheid boven het normale maximum lijkt mij eveneens onwenselijk. Dat zou binnen de applicatie geregeld moeten worden en niet in de gegevensbank van Openstreetmap.
1 Like
De VRT benadrukte juist dat ze die CADOen niet gebruiken; die zijn voor onderhoud en voor het afleiden van het verkeer als de snelweg geblokkeerd is.
De beweegbare palen zijn gewoonlijk niet speciaal voor nooddiensten; ze zijn meestal voor bewoners, leveranciers, speciale parkeerders; toegang voor gehandicapten- en diplomatenvoertuigen; etc. Noodvoertuigen moeten ook toegang krijgen, maar dat is meestal niet het hoofddoel.
Als er een toegang is die speciaal bedoeld is voor noodtoegang, dan verwacht ik er ook een bord dat dat zegt, en dan is emergency=designated de juiste access. Als het voor normaal gebruik door auto’s toegankelijk is, dan is het zowizo ook toegankelijk voor noodvoertuigen. Tenzij het fysiek niet mogelijk is, dan emergency=no.
Alleen als je normaal géén toegang zou verwachten voor noodvoertuigen, zoals bij pakweg een cycleway, een footway of een path, dan geeft emergency=yes aan dat noodvoertuigen er tóch op mogen en kunnen.
Voor het overige is het vooral van belang dat de diensten weten hoe ze het moeten openen, en dat kan je normaal ook aan de barrier zien en verifieren.
En dan vind ik niet dat er in OSM opgenomen moet worden of hulpdiensten over de sleutel beschikken. Net zoals je niet bij een winkel mapt dat de klanten een pinpas hebben; je mapt dat daar pinbetaling mogelijk is, en dan kan de klant bedenken of-ie dat heeft.
En bv bij een vaardoorgang map je niet hoe breed de schepen zijn, je mapt wat de doorvaartbreedte is en dan bedenkt de schipper (of de vaarrouter) of-ie erdoor kan.
Dat ligt ook aan het type noodvoertuig.
Een ladderwagen van de brandweer is fysiek heel wat groter dan een politieauto. En een motorambulance/brandweer en politie op de motor/fiets/paard kunnen zelfs niet al te stijle trappen nog wel bedwingen om iets eerder ter plaatse te kunnen zijn…
Je zou dan haast moeten gaan taggen voor emergency:hgv, emergency:motorcar, emergency:motorcycle, … en ik denk dat dat wellicht iets te ver gaat om in OSM op te nemen.
Je herhaalt nu je argument(en), dus dan sta ik mezelf toe dat ook nog een keer te doen, te meer je in reactie op mijn vorige post eigenlijk alleen in bent gegaan op de zijdelingse opmerking over de wiki en de rest van mijn argumenten onbeantwoord hebt gelaten.
Een winkel is geen weg of barrière, want betalen is daar een gegeven en dus standaard aangenomen. Er is geen winkel waar je niet kan of moet betalen - en je mag er tijdens openingstijden ook altijd naar binnen.
Als je dan toch de vergelijking met betalingen wil maken, is een parkeerplaats wellicht passender: daar kun je aangeven of je er door/op/in mag met access, vervolgens of er betaald moet worden met fee, en vervolgens hoe je kunt betalen met de diverse payment:* tags.
Bij een winkel kun je stap één en twee overslaan, want ja je moet altijd betalen en ja je mag altijd naar binnen (mits open).
Maw: iteratief taggen. Van grof naar fijn. En dat is relevant, want jouw argument gaat pas over het detail: niet of ze er door mogen (of kunnen), maar hoe, en dat is feitelijk pas stap twee. En dan kun je nog argumenteren of je dan mapt dat de hulpdienst de sleutel/transponder/code/whatever heeft, of dat de barrière die ondersteunt. Net als je zelf doet met of de klant een pinpas heeft of de winkel pinbetaling ondersteunt.
Natuurlijk is meer detail beter en mooier. Maar we kunnen ook gewoon een boom taggen zonder meteen te moeten aangeven wat de leaf_type en leaf_cycle is of wat voor soort boom het is - en dat is in feite wel wat je hier vraagt of “vindt”. Of een AED zonder het kasttype, zonder dat of hoe die op slot zit, etc. Daarmee kan iedereen op elk niveau een bijdrage leveren en alles laagdrempelig op de kaart gezet worden, om het daarna door kenners verder te (laten) verfijnen. Dat is hoe OSM werkt. 
In jouw voorstel sla je die stap over: het mag alleen gemapt worden dat het er is, als je ook gelijk mapt hoe. Daardoor wordt de drempel om dit te kunnen mappen onnodig hoger gelegd door direct het volledige detailniveau te vereisen.
Dat maakt het voor in de praktijk voor een hele grote groep onmapbaar wordt, terwijl een substantieel deel in de praktijk best zal weten óf hulpdiensten ergens door kunnen (men kent immers de eigen woonomgeving en heeft ze er misschien wel eens door zien gaan), alleen niet precies weet hoe (want van SOS toegang of standaardsleutels heeft menigeen nog nooit gehoord).
Dus kom ik weer terug bij mijn pleidooi van de laatste keer: ik snap waar je vandaan komt, maar zou er voor willen pleiten om in dit geval te kijken naar wat er mogelijk is. En niet op basis van een principiële “ik vind” - voor iets wat aantoonbaar en objectief op twee manieren uit te leggen is - de deur dicht te gooien naar iets wat onderdeel is van een hele mooie symbiose (tussen hulpdiensten en OSM).
En, op het risico af dat dit weer het enige is waar je op reageert, om de wiki-pagina dan ook nog even aan te halen: eens dat “het staat op de wiki dus het is waar” zeker niet altijd opgaat. Daar staat tegenover dat volgens taginfo de key emergency 10.921 keer in combinatie met barrier gebruikt wordt, waarvan 8.027 keer met de waarde yes en nog eens 1.180 keer met designated. Gezien dat stuk voor stuk om single nodes gaat vind ik dat best significant, maar als je nog niet overtuigd bent zou je altijd nog eens met overpass kunnen kijken waar die zich bevinden.
@ Sander
Daarom heb ik ooit begrepen dat het belangrijk is om de breedte van een fietspad op te geven ivm die zwaardere voertuigklasse.
Die specifieke HGV tags ben ik ook al tegengekomen.
Ik heb ook ooit begrepen, maar nooit iets zwart op wit gehad dat fietspaden gewoon routeren in OSM en geen emergency=yes behoeven.
De kennis bij VR mappers is nog niet erg groot.
LiveOp had er moeite mee dat mappers communiceerder met de OSM community hoe de tagging werkt.
Dat houden ze liever onder de pet. Er zal vast ook wel concurrentie zijn op dat gebied in de vorm van ‘medespelers’.
Dat maakt het voor ‘ons’ wel lastig om te adviseren.
Het blijft koffiedik kijken. Wat wordt in de navigatie genegeerd?
Bv afslagbeperkingen niet. except=emergency blijft dan nodig op de relatie.
access=private … Geen idee
Fietspaden? …
Wegneembare paaltjes? Ik hoor verschillende dingen. De wiki geeft nog geen uitsluitsel.
Er is wel al een tijd een wiki ooit gestart door Lachgast
https://wiki.openstreetmap.org/wiki/NL:Hulpdiensten
Maar nog steeds niet ‘waterdicht’.
1 Like
Nee hoor, je mapt dat er een barrière is en wat de toegang is per voertuigcategorie. Normaal gesproken mogen hulpdiensten erlangs, dus daar hoef je geen extra informatie voor toe te voegen; alleen voor uitzonderingen.
En daarmee is de snelle mapper klaar.
De detailmapper kan er details aan toevoegen: wat voor barrier, wat voor materiaal, hoe krijg je hem open, is het standaard open of dicht.
Wat voor de gewone mappers onmapbaar is, is of een hulpdienst over de benodigde middelen beschikt. Want dat weet alleen de betreffende hulpdienst. Dát is wat ik niet in OSM vind thuishoren, en waar je als LiveOp ook niet op zou mogen vertrouwen.
Wat er mogelijk is, geef ik aan: mappen waar je over moet beschikken om de barriëre te passeren. Dat is ook wat de hulpdiensten moeten weten. Of ze het hebben weten ze zelf. Dat is geen objectieve, verifieerbare, algemeen bekende informatie.
Wat je nodig hebt om de barrière te passeren, kun je wél aan de barrier zien, als je details wil mappen.
Voor de duidelijkheid: ik ga niet aan die tagging zitten. Ik vind emergency=yes op iets waar je al toegang hebt, redundant, en als het op grotere schaal toch wordt gedaan, dan denk ik dat de betekenis die er door een NL veiligheidsregio aan gegeven wordt, er al snel niet meer inzit, en dat het gewoon wordt: toegestaan voor hulpvoertuigen.
2 Likes
Dat ben ik op zich met je eens, maar dan leun je wel op een veronderstelde default - dat de hulpdiensten er door kunnen tenzij. In lijn met waar we het hier over hebben gehad: Zijn deze defaults inderdaad default - en zijn ze dat dan ook terecht?
En zoals ik de situatie met LiveOp begrijp dat doen zij dat niet. Hun stelling lijkt*: “In geval van nood durven we niet over een barrière te routeren waarvan we niet zeker weten (omdat het is aangegeven) dat de hulpdiensten er door kunnen.”
En daar is iets voor te zeggen, want mocht het ter elfde ure niet zo zijn, dan moet betreffende nooddienst ineens een stuk omrijden en levert de beoogde winst die de route over de barrière op zou leveren ineens extra tijd op.
*) Aanname op basis van de oorspronkelijke berichtwisseling in de changeset.
Tja, ben ik met je eens, maar dat geldt ook voor of ze de barrière voorbij kunnen en zei ik ook:
De vraag is of je ze zo ver kunt en wil** krijgen dat ze dat gaan toevoegen - en of ze dat überhaupt openbaar willen maken (de “hoe”).
**) Ik begreep van @eggie laatst dat hij nu al behoorlijk wat tijd kwijt is aan het coachen van (nieuwe) VR-medewerkers.
En persoonlijk vind ik het dan meer vallen onder hoe je het zelf in het topic over defaults schreef:
… als ze daar vervolgens emergency=yes op plakken. Het risico zit 'm meer in wat je daar ook zegt:
Want dat is in dit geval natuurlijk zo (per veiligheidsregio, als ze dat primair zelf onderhouden), maar het risico bestaat natuurlijk dat iemand anders die niet weet hoe het moet of betrokken is bij die afspraken die tag her en der toevoegt of verwijdert, met alle impact van dien. Maar goed, dat risico lopen ze in de breedte met het gebruik van OSM en gaat vooralsnog goed.
Dat voorkomen is m.i. de enige toegevoegde waarde van de gedetailleerde “hoe kunnen ze passeren”-aanpak, tenzij de regio’s zelf de toegevoegde waarde zien van zoiets als dit:
Maar dat moeten ze wel zelf willen (en LiveOp wel willen implementeren).