VRT mapt in Hengelo .. graag assistentie

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.

Bekijk maar eens langs een spoorlijn, de eerdere situatie die besproken is (de aanleiding van dit topic), als ergens een trein ontspoort, bij de boerenovergang. Hoe kom je er.
Laatst hadden we een zaak, met een boer die paden weghaalde, maar erachter ligt wel een gemaaltje van het waterschap, en waarschijnlijk krijgt de boer zelfs vergoeding voor bereikbaarheid, dat gebeurd. Valt iemand in het water of anderszins.

Calamiteiten gebeuren op de gekste plaatsen, ga je scenario bedenken, dan is dat op vele plaatsen.
Willen ze daar op voorbereid zijn?

Laatst nog het vliegtuig bij Apeldoorn in de sloot naast de snelweg, daar stonden de politie auto’s in het weiland.
Toen speelde deze vraagstelling en dacht, is dit zo’n situatie.
Een keuze ter plekke van de dienstdoende.

Om daar nu allemaal bordjes neer te zetten, ondoenlijk en schept ook deels onduidelijkheid.

De eigenaar van de grond bepaald of er borden komen.

Er is geen wettelijke verplichting waar men het kan afdwingen, is mij niet bekend.

Dit ging over de nooddoorgangen die de brandweer/VRT van tevoren voor dit doel met de eigenaar overeenkomt. Ik kreeg niet de indruk dat dat om grote aantallen gaat, eerder zeer kleine aantallen. Wat ze doen als er geen afgesproken vrijgehouden doorgang is, is een ander verhaal. Nood breekt wet, denk ik.

Als de hulpdiensten langs alle spoorwegen kunnen rijden, dan zouden ze hun navigatiesysteem hierop kunnen aanpassen.

Als het zover komt dat we in willekeurige weilanden paden voor hulpdiensten tegen gaan komen zodat de hulpdiensten de sloten kunnen bereiken, dan is dit onbegonnen werk, want er is nooit genoeg mankracht om wegen door elk weiland en naar elke sloot te mappen.

Andere OSM mappers zullen deze paden sneller al dan niet per ongeluk weghalen dan dat ze eraan bij (kunnen) dragen, dus dit kan zelfs nog ongewenste onenigheid opleveren.

Misschien is dit idee te vergezocht, maar een mogelijkheid voor de veiligheidsregio’s zou kunnen zijn om een privé-server erop na te houden met dergelijke paden en deze te linken aan OSM-data die regelmatig geïmporteerd worden. Validator-waarschuwingen kunnen aangeven waar de paden niet meer op OSM-wegen aansluiten. JOSM is uitstekend in staat om zulke waarschuwingen te genereren.

Binnenkort is er (als het lukt, ik denk het wel) een gesprek met de leverancier van de navigatiesoftware, met Mike van de VRT en 3 van OSM (ons soort mensen, ja). Een van de vragen is hoe vaak dit voorkomt, routeren/navigeren over een terrein zonder zichtbaar pad.

Een aantal daarvan zijn brandgangen in een bos, daarvan hebben we al vastgesteld dat je die als ways kan invoeren met bijvoorbeeld access=no emergency=dedicated.

Wij hebben zo’n beetje de insteek:

  1. Er moet wel iets van ground truth/verifieerbaarheid zijn.
    Als er bij de toegangen tot zo’n noodroute een bordje of teken zichtbaar is dan heb je dezelfde situatie als bijvoorbeeld bij een ferry: de terminals zijn bekend en verifieerbaar, dat is voldoende ground truth om de meest waarschijnlijke route over het wateroppervlak in te voeren. Er zijn meer van zulke voorbeelden.

Als er helemaal niets zichtbaar is, dan raden wij het af, en hebben we ook geen argumenten om andere mappers te verbieden het weer weg te halen wegens niet bestaand. Anders gezegd, dan raden we aan dat de VR/Brandweer een zichtbaar kenmerk aanbrengt, om tegelijk hun chauffeurs en de registratie/routering/navigatie te helpen.

  1. Als het om grote aantallen gaat zonder zichtbare toegang, dan is het alternatief beter: de navigatiesoftware moet zelf over areas kunnen navigeren. Er zijn algoritmes voor, en een commercieel bedrijf moet dat wel in hun navigatie in kunnen laten bouwen.

Dan nog moeten de toegangen goed en verifieerbaar gemapt en getagd worden, en ook de area zelf. Zonder zichtbare access-kenmerken, al is het maar een rode stip of zo, wordt dat in OSM moeilijk, denk ik.

Hetzelfde geldt voor een oplossing met een relatie. Je kan zeg maar een brandweervoorkeursnetwerk taggen, waar alle bij voorkeur te gebruiken wegen en toegangen in een brandweerrelatie staan. Dan moet je dat wel op de weg kunnen zien - niet noodzakelijk op elke afzonderlijke weg, maar wel op voldoende plekken. En dan moet de navigatiesoftware kunnen routeren/navigeren over een relatie. Dat is niet heel moeilijk trouwens, OsmAnd en cycle… (ik vergeet de precieze naam altijd) kunnen dat door in een profiel op te nemen dat leden van een bepaalde soort relatie een hoog routeergewicht krijgen.

Hm, ik praat weer teveel en ik loop vooruit.

Ik bedoel maar, de grondprincipes van OSM zijn we wel hoog aan het houden! Ground truth, verifieerbaar, consensus, respect voor elkaars werk. En zodoende bijdragen aan belangrijke toepassingen.

Inderdaad, als hulpdiensten willen navigeren op OSM data is dat zeker mogelijk. Ook als iets dat er niet is dat niet in kaart wordt gebracht! Zoals een aanrijroute die er niet is, dwars door een weiland.

Elk navigatiesysteem werkt zo, dat als je een beslissing neemt om dwars door een weiland te crossen, waar geen zichtbaar pad, of track is, de navigatie je vanzelf weer oppikt op een weg waar je wel een routering hebt.

Hiermee wil ik zeggen:
Probleem opgelost!

Als nood doorgangen niet aanwezig zijn in het veld dienen ze niet te worden opgenomen in OSM.

Inderdaad, en bordjes is geen optie.

Volgens mij is dit nog nooit gelukt door enige navigatie softwarebouwer, met OSM data.

Technisch kan de mens ook naar Mars, maar dit is ook nog niet gelukt, men weet dat men niet meer terug kan komen, en zal er (op dit moment) alleen over kunnen dromen.