emergency=designated bedoel je?
Au! Ja, dat had ik willen bedoelen!
Probleem met CaDo’s is dat de wegbeheerder (meestal RWS denk ik) niet altijd zomaar de slagboom/vangrail voor je opendraait als je haast hebt.
Dus tenzij er op de snelweg zelf iets gebeurd is en het verkeer in beide richtingen daar toch al tot stilstand is gekomen zal het meestal praktisch een no-go zijn om deze op te nemen in de standaard navigatiebeschrijving van de hulpdiensten.
Ze zullen eerder specifieke instructie krijgen vanuit de meldkamer om daar door te steken of tegen het verkeer in te rijden via een afrit en die instructies volgen.
Ja dat is het soort vragen dat de VR’s zouden kunnen beantwoorden. Ik ga er nu van uit dat ook de meldkamer diezelfde toepassing gebruikt, en dat alles vanuit de toepassing gezien/gestuurd moet kunnen worden, en niet vanuit lijstjes die ernaast liggen. Dus als er voorwaarden zijn, noteren in de database of in een aparte tabel ernaast, en dan moet de toepassing de code genereren of signaleren dat er een code opgezocht moet worden of op knop A gedrukt, of wat er dan ook nodig is. De komplete wegsignalering in cyclus X zetten, een 50Km deken uitrollen, file-inversie doen, NL Alert eruit gooien, code rood afkondigen, kamer terug laten komen van reces… okee, dat laatste gaat misschien wat ver.
En net als met elke navigatie: als je ervan afwijkt door pakweg het hek van het kerkhof te rammen en dwars over de graven te rijden, mag die wel piepen maar daarna moet-ie het weer oppikken en herberekenen.
Een ander geval is als er “ramproutes” zijn, waarbij al vastligt hoe je precies bepaalde trajekten aflegt. Dan hebben we het MI over routerelaties, dus reeksen wegen en misschien toegangen/obstakels die in vastgelegde volgorde afgelegd worden. Dan moet de navigatie dus in staat zijn om precies via een routerelatie te navigeren. Of de oude manier: wegen en doorgangen een unieke routeref geven zodat de navigatie ze aan elkaar kan rijgen.
Denk ik te ver door? Hm, waarschijnlijk.
Voor hulpdiensten als brandweer en ambu en politie is het alleen handig om te weten waar deze CaDos zich bevinden op een snelweg. Deze kunnen op verschillende manieren gebruikt worden. Voor de hulpdiensten om bij een (grote) calamiteit te komen, en voor weggebruikers (uiteraard alleen onder begeleiding van RWS of/en Politie om het verkeer eventueel om te leiden Dus voor de hulpdiensten alleen een markering van zn CaDo (met uniek nummer) in de kaart is meer dan voldoende.
ik zou deze niet als doorsteek in laten tekenen door wie dan ook.
als ik voor onze VR spreek, dIt hoeft voor ons niet eens in OSM te staan, dit kunnen wij zelf in ons systeem als POI (point of intrest) zetten.
Dan vraag ik me meteen af wat er voor jullie dan wél in OSM hoeft te staan, en: wat is “ons systeem”?
Dus, als ik het goed heb zijn er vier verschillende hulpdienstwegen:
- Calimiteitendoorgangen
- Passeerbare velden zonder duidelijke weg
- Normale paden en wegen die toegankelijk zijn voor brandweervoertuigen
- Dienstwegen nabij hulpdienst (highway=service), bijvoorbeeld voor de uitruk van brandweervoertuigen
In de navigatie van hulpdiensten (in ieder geval die van de brandweer) wordt gebruik gemaakt van Melvin. Deze dienst van de overheid maakt gebruik van extra lagen bovenop de data afkomstig van ons project Openstreetmap. Naast wegwerkzaamheden betreft het hier ook file-informatie. Dus de navigatie houdt sowieso rekening met drukte en andere redenen voor oponthoud.
Wat tof dat je workshops wilt verzorgen. Met jouw ervaring met JOSM lijk je me prima geschikt!
Ik bied me graag aan om eventueel mee te denken over opzet & leerdoelen en mee te helpen bij de interactieve gedeelten. Altijd leuk om te doen.
Hierbij ben je uitgenodigd, ik laat je weten welke data de workshops starten.
Half september zal de eerste Workshop starten.
We brainstormen voor die tijd nog even als je wil, eerst vakantie.
Op dit moment zijn er 4 Veiligheids regio’s die interesse hebben getoond (Twenthe, Friesland, IJsselland en Gooi & Vechtstreek), waarbij bij elke regio ongeveer 7 personen (virtueel) aanwezig zullen zijn.
In eerste instantie zullen zal een workshops uit 2 dagdelen van ongeveer 1 a 1,5 uur beslaan (elke regio zal een eigen workschop genieten, met dezelfde onderwerpen)
Daarna kunnen specifieke vragen eventueel geïnventariseerd en behandeld worden.
Als er buiten de 4 ingeschrevenen nog meer Veiligheidsregio’s willen inschrijven, verzoek ik deze om privé contact met me te zoeken. (Email link in linkerkantlijn)
Zijn er nog ontwikkelingen te melden?
Geen idee. Commodoortje, kun je bij terugkomst even een seintje geven? Dan kunnen even contact hebben over de inhoud van training.
Even ter herinnering, dit waren de “actiepunten”:
-
Op NL forum bespreken en tot een voorstel komen. Zie https://docs.google.com/document/d/1qCpQj1hSSxNWdnS1RKax44LF9BPHuIckTnVRK7wtlEY/edit?usp=sharing
-
Daarbij ook wel de internationale tagging list raadplegen, al is het alleen maar om de weten wat ze elders doen. Jeroen Hoek wil dat wel bespreekbaar maken.
-
Mike gaat wat foto’s op het forum plaatsen, voorbeelden. Ook van de orientatiepunten, zijn dat een soort knooppunten met routes ertussen?
-
Voorbeeldfoto en plaatje van de toepassing? Kunnen we de toepassing in werking zien? Dit helpt ook bij het bespreekbaar maken op het internationale forum (mailing list).
-
Mike gaat collega’s ook bij andere veiligheidsregio’s en andere kennisbronnen benaderen, ook Jan Willem van Aalst die hier veel van weet. (Informatie hierover: voegt kaarten en geobronnen samen, pandkenmerken e.d. voor de vraag “hoe ziet het pand eruit waar we naar toegaan. Veiligheidsregiokaarten, maar geen routering/navigatie.) Fireman2130 werkt ook voor een meldkamer met OSM.
-
Vervolgbespreking, mogelijk miniconferentie, met ook andere geïnteresseerde VRs.
Bovenstaande lijkt me een goed plan.
Wellicht zaterdag tussen 10.00-11.00 op Jitsi.
Half september ben ik voornemens om workshops te houden.
Inmiddels hebben 4 veiligheids regio’s interesse getoond. Begin September laat ik meer horen naar de Veiligheidsregio’s.
In eerste instantie zullen de workshops gerelateerd zijn om te werken met JOSM, en gaandeweg kunnen daar specifieke taggings voorbeelden voorbij komen.
Nu zie ik dat het allemaal een beetje hakkelend gaat, mede omdat sommigen net begonnen zijn met mappen.
Middels de workshops zullen de mogelijkheden van het raadplegen van andere bronnen etc. besproken worden.
Als er dan wat ervaringen zijn opgedaan kan gedacht worden om een NL wikipagina te introduceren voor Veiligheidsregio’s
(hopelijk staat binnen de gemeenschap iemand op, om deze wikipagina op te zetten.)
Het is dan handig dat volgens de afgesproken richtlijnen getagd gaat worden, en niet iedereen maar gaat doen wat hij zelf denkt dat goed is.
Als een onderwerp nog niet op de wiki staat is dan ook niet te taggen, mits het een normale tagging is die gangbaar is voor iedereen.
Natuurlijk is het dan handig om, als er voorbeelden zijn, internationaal te kijken.
Onderstaande punten komen aan de orde in de Workshop, maar gaandeweg kan er afgeweken worden.
• Introductie
• Kennismaking met JOSM
• Installatie en instellingen JOSM
• Sneltoetsen
• Werken met layers (ondergrond kaartmateriaal, zoals BGT, en satelliet images)
• Structuur om materie te onthouden.
• Aan de slag in JOSM.
• Rondvraag
Daarom probeer ik tot een afspraak te komen, aan de hand van aan te leveren use cases en foto’s; oplosrichtingen en mogelijk al bestaande oplossingen; dan konkrete tagging instructies, gedokumenteerd op een wikipagina.
Ik heb daar een voorzet voor gedaan maar zou graag feedback krijgen, antwoorden op de vragen en meningen over de oplosrichtingen, anders blijft het hangen. Dan kan je kursussen geven maar daarna tagt iedereen naar eigen inzicht (Allroads heeft bv tags met fire_pad en fire_brigade gevonden) en worden er weer mappers boos!
Ik heb inmiddels het document van Peter doorgelezen.
Volgens mij is het ondoenlijk om alle wegen waar een 1e hulp voertuig kan rijden, om te taggen voor routering voor LiveOp!
Hulplijnen niet mappen!
Daar zal LiveOp zelf een oplossing voor moeten bedenken.
Ik probeer een voorzetje te geven.
Kijk naar een app zoals OSMAND, deze kan overweg met tracks, die van te voren of in het verleden gereden zijn.
Als LiveOp nu gebruik maakt van een tracklijst, dan kan deze worden gebruikt als layer, waar de bestuurder zelf een afweging maakt om een routeverkorting te maken.
De bestuurders hebben lokale kennis en weten de weg normaal gesproken uit hun broekzak.
Deze tracklijst zal bestaan uit de gereden tracks die door brandweer als (goed) berijdbaar worden beschouwd, en normaliter niet toegankelijk zijn voor motorvoertuigen.
Met deze tracklijst kan worden gewerkt, zonder de database van OSM halsbrekende toeren moet gaan uithalen. Ook de tag firepath=yes is hiermee overbodig.
Mij lijkt dit de beste oplossing.
Ik ben geen voorstander om extra tagging te bedenken die in het document van Peter staan.
Dit maakt het alleen maar moeilijker, en wij hoeven het probleem van routeren niet voor deze hulpdiensten op te lossen.
Nogmaals, de workshops zullen de basis van OSM behandelen, zonder te diep in te gaan op mogelijke taggingsschema’s.
Persoonlijk ben ik (op dit moment) overtuigd dat OSM daar niet voor is bedoeld.
Maar middels inventariseren en vastleggen van argumenten kan hier wellicht verandering in komen.
Nu zie ik dat als de VR mappers taggen, niet juist, maar ook niet volledig taggen.
Daar is juist de workshop voor bedoeld.
Dat is volgens wat ik ervan begrepen heb zeker niet de bedoeling! De hulpdiensten mogen op gewone wegen natuurlijk overal rijden. Ze mogen ook verkeersregels overtreden, tegen het verkeer in bijvoorbeeld, dus daarvoor hoef je ook niks speciaals te taggen. Dat kunnen de router en de chauffeur oplossen Alleen waar gewone stervelingen niet mogen/kunnen komen, daar tag je wat bij, maar de normale tagging blijft wat het is.
En dan zo dat alle toepassingen het kunnen gebruiken, niet speciaal voor dit ene bedrijf.
De VR heeft aangegeven dat ze zelf zowizo controleren en bijhouden welke speciale doorgangen geschikt zijn, dus dat lijkt me heel doenlijk! We hoeven alleen de te gebruiken tagging af te spreken en te dokumenteren.
Sorry, maar OsmAnd kan nauwelijks routeren en navigeren met gpx-tracks, en al helemaal niet met een netwerk van tracks. Je zou alle mogelijke routes als track moeten hebben, inklusief alle gewone wegen die je mag gebruiken. Of je zou alleen de speciale stukken als track moeten overlayen, maar dan moet de router in staat zijn om een statische losse track midden in een normale berekende route mee te nemen. Ik ken geen enkele toepassing die dat kan. Als er een algemene tagging-oplossing is die routeren/navigeren het via een routerprofiel in de normale on-the-fly routering kan oplossen dan heeft dat absoluut mijn voorkeur! Dan heb je juist een hele mooie algemeen bruikbare OSM-toepassing.
Ik zou zelf wel de eis stellen dat er ‘in het veld’ iets waarneembaar moet zijn waaraan de willekeurige mapper kan verifiëren dat de tagging klopt.
Nou, halsbrekende toeren… fire_path=yes is bestaande tagging. Ook emergency tagging wordt veel gebruikt. Een way aanmaken over een area tbv routing is ook niet nieuw.
Klopt, maar het is wel een kans om een bruikbare en uiterst nuttige toepassing van OSM mogelijk te maken. Zowel de gebruikers als OSM profiteren daarvan. In dit geval kost het de reguliere mappers ook helemaal geen moeite, want de gebruikers doen alle mapping, onder de normale controlemechanismen van OSM.
Ik ben het met Peter eens dat wij er zomaar een boel gekwalificeerde collega’s bij kunnen krijgen, waar we verder net zo veel omkijken naar hebben als menig andere kaarttekenaar. Mits we in gezamenlijkheid bepalen welke sleutels en waarden we gebruiken voor de voor hen belangrijke elementen. Commodoortje heeft al voorgesteld dat Peter wellicht ook meehelpt bij (het voorbereiden van) de training; dat lijkt mij bijzonder nuttig. Drie weten meer dan twee 
Wat mij betreft een prima idee. En ik denk eigenlijk dat we dit ook als leerdoel mee moeten nemen in de werkplaats, al was het maar als aparte dia of oefening. Wellicht dat we ook een discussie kunnen simuleren, om te tonen hoe de gezamenlijkheid werkt, en secundair om ideeën te verzamelen en te komen tot een heldere afspraak. Ik ben ook benieuwd hoe andere medewerkers van Veiligheidsregio’s zich ingelezen hebben.
Het taggingsschema zal zeker noodzakelijk zijn, en zal in de loop der tijd vorm krijgen.
Mocht er nu al belangstelling zijn, wil ik morgen vroeg rond 10:30 wel een sessie opzetten om het een en ander te testen.
Veiligheidsregio
Barrier.
Het zetten van emergency=yes.
Wanneer zet een OSM’er het, als het te zien is.
Niet van, lift_gate toegang, het is belangrijk dat emergency er langs kan, men zal er wel langs mogen dus ik zet er emergency=yes op.
Ik begrijp dat deze sticker daar geplaatst is. Zelfs met een nummer.
Voorstel:
access_sign=NL:SOST of SOSToegang op de barrier te zetten. Samen met SOST:ref=20
Dat is de basis, gevolg het afgeleide emergency=yes te taggen.
Edit: Een nummer, een los nummer, dat kan ook een aanduiding zijn van een operator, barrier nummer, niet behorende bij het SOST systematiek. Wellicht is het een barrier:ref=*.
Je moet je we degelijk afvragen waarbij hoort dat nummer.
Zo maak je ook onderscheid tussen andere nodes met emergency=yes.
Gevolg beter controleerbaar.
En voor andere beter te filteren, voor een bepaalde toepassing, applicatie.
Eigenlijk zou de stichting dan een kaart moeten maken met SOStoegang POI,
of een bestand url ter beschikking stellen aan OSM.
Edit:
Toevoeging:
https://kaart.geo4oov.nl/geo-beheer/app/catalogue/servers
SOS toegangslocaties Besloten 19-02-2021 27-08-2021
Besloten database.
Bijna landelijke dekking
Hier staat de sticker naast de bollard ref 10.
Dan source:access_sign=NL:SOST SOST:ref=10 emergency=yes op de bollard.
Dan kan je ook nog apart de sticker taggen op dat andere paaltje met een access_sign:direction=180 180 graden.
