VRT mapt in Hengelo .. graag assistentie

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 :slight_smile:

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.

https://www.sostoegang.nl/

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.

Afgelopen dinsdag hebben Lachgast, Commodoortje en ik een Jitsi sessie met de VR Twente gehouden.

Een en ander wordt steeds konkreter en duidelijker. We richten ons nu vooral op de navigatie / navigeerbaarheid, omdat bijkomende informatie zoals objectgebonden informatie en werkzaamheden in andere (extern geleverde) lagen door de toepassing aangeboden worden. Algemene principes zijn:

  1. er moet wel “ground truth” zijn, dus verifieerbaarheid.
  2. zo veel mogelijk de al bestaande tagging gebruiken, en aan de router overlaten hoe dat voor navigatie gebruikt wordt. Dus zuinig zijn met emergency=* tags en fire_path tags.

Voorbeeld van 2: Als een pad door brandweervoertuigen gebruikt mag worden en daar qua breedte, hoogte en ondergrond geschikt voor is, dan tag je breedte, hoogte en ondergrond. De routing algoritmes mogen access tags en verkeersregels negeren maar moeten dan wel naar breedte, hoogte en ondergrond kijken, dat zijn zaken vooer het brandweerwagenprofiel. Je hoeft dan geen emergency tag of fire_path tag te zetten. Dat kan je (principe 1) wel doen als er op de weg een bord staat dat het om een speciale noodroute of brandweerroute gaat.

Volgende workshops kunnen dan nog konkreter worden wat betreft voorbeelden en oefeningen.

We hebben na de workshop met zijn drieën afgesproken: Lachgast gaat een concept-wiki maken; daarna dragen Commodoortje en Peter Elderson het hunne bij, waarna het in het forum, en bij de VR’s besproken en afgemaakt kan worden.

Dat is dan a) de dokumentatie voor de brandweer mensen hoe ze moeten taggen, en b) tevens de tagging specificatie voor Liveop (of andere data users).

Routeren over een area
We hebben nog geen consensus voor het vraagstuk van routeren over een area. Het probleem speelt op meerdere punten in OSM, bijvoorbeeld routes over een pedestrian area, veerpont over een rivier, vaarroutes over een meer, en wordt op verschillende manieren opgelost om te kunnen routeren: highway=path over een pedestrian area, route=ferry over de rivier, waterway=fairway over een meer.

We moeten dit MI wel oplossen, anders gaan de gebruikers improviseren en dan ben je verder van huis.

Mooie voortgang, jullie zijn goed op weg!

Mijn voorkeur heeft het om het mappen van highway=* + area=yes te ontmoedigen en ons volledig te focussen op lijnobjecten voor het creëren van routes. Een area kan dan aanvullend gemapt worden als area:highway=* of place=square. Hier maakt navigatiesoftware geen gebruik van, maar met deze tags kunnen dergelijke gebieden toch in OSM gemapt worden.

En heb je dan -voor het routeren over een area via een niet expliciet aangegeven way- voorkeur welke tags? We hebben nu de opties

  • highway=virtual (maar dat is een weggestemd voorstel)
  • highway=emergency of highway=fire_path
  • route=emergency of route=fire_path (vergelijkbaar met route=ferry, dus de inrit en uitrit wil je dan verifieerbaar hebben maar de weg ertussen is een benadering)

of nog anders?

Even los van navigeren over vlakken/vlaktes…

In aanloop van de (concept-)wiki voor hulpdiensten ben ik een aantal wiki-pagina’s aan het vertalen als voorwerk (en pas de inhoud waar ik het kan aan op de Nederlandse en/of Belgische situatie).
Het gaat tot dusverre om emergency=* (die ik nog zal aanpassen op het emergency=yes-gebruik) en Toegangsbeperkingen (access). Ik vermoed trouwens dat de titels nog aangepast kunnen worden, maar ik weet niet wat voor effect dat heeft op doorverwijzing van andere taalversies.

Key:access
https://wiki.openstreetmap.org/wiki/NL:Key:access

Key:emergency
https://wiki.openstreetmap.org/wiki/NL:Key:emergency

Ik moet mijn vertaling nog nalopen, maar op- en aanmerkingen zijn uiteraard welkom!

@Peter Elderson

Wat vind je van highway=path/track + informal=yes? Dan kunnen we namelijk blijven werken met bestaande tags, en informal=yes geeft dan aan dat iets een “niet expliciet aangegeven way” is. Die tag wordt nu al gebruikt voor olifantenpaden, maar dit kan worden uitgebreid naar onofficiële wegen en paden voor hulpdiensten. Hier kan natuurlijk ook access=private bij als zo’n pad zich op iemands erf bevindt.

Het kan zijn dat ik je nog niet volledig begrijp, want ik heb de workshops e.d. zelf niet gevolgd. Heb je voorbeelden voor mij?

@Lachgast

Bij NL:Key:emergency mag het stuk over “emergency als access-tag” nadrukkelijker genoemd worden, net als op de Engelse pagina. Ook ontbreekt een vermelding van emergency=emergency_ward_entrance nog. Ik heb het gevoel dat er meer tags nog niet vermeld zijn, maar daar heb je zelf waarschijnlijk meer zicht op.

Bij NL:Key:access kun je ook verwijzen naar NL:The Netherlands road tagging en naar de Nederlandse pagina over verkeersborden. Als mensen toch wegen aan het mappen zijn, dan is dit voor hen wellicht ook relevant, maar op de Engelstalige pagina staat dit natuurlijk niet zo vermeld.

In ieder geval zien de vertalingen er helder uit, ga zo door!

Goed begin!
Het lijkt erop of je een disambiguation page als basis hebt gebruikt.
Edit: Dat ligt aan de engelse pagina.

Die is voor zichtbare en verifieerbare olifantenpaadjes, maar daar gaat het nu niet om. Het gaat om het routeren/navigeren over een terrein, zonder dat er een zichtbare/verifieerbare weg is.

Dat legde Commodoortje zaterdag ook aan mij uit. Die paden kunnen we helaas niet in OSM mappen tenzij de hulpdiensten er vaak genoeg overheen rijden dat er daadwerkelijk een pad zichtbaar is.

Mijn suggestie aan de veiligheidsregio’s zou zijn om een bordje bij deze paden te zetten, ten eerste zodat men ze vrij houdt van obstakels, en ten tweede zodat we in OSM een object hebben om naar te verwijzen bij het mappen binnen het principe van “map what’s on the ground”.

We hebben de vraag al klaarstaan: hoe veel van dergelijke situaties zijn er nou eigenlijk? Als dat er tien zijn, dan is dat niet zo’n bewerkelijke gedachte: overal even een paaltje ter markering.