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:
- 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.
- 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.
?? Veel ground truth hangt aan bordjes, waarom is dat geen optie ??
Ik heb ooit een stukje code in een testsituatie werkend gezien. Voornaamste probleem: niemand die het zou kunnen maken ziet er het nut van in. Een commercieel bedrijf kan er budget instoppen en dan krijgen ze het zeker werkend, er zijn algoritmes. Performance zal een dingetje zijn, maar daar zijn werkbare oplossingen voor. Je kan als router beginnen met de kortste randlijn van entreepunt naar exitpunt, en dan als extra proces gradueel verfijnen.
Maar dan moet het vaak genoeg voorkomen en genoeg opleveren om belangrijk te zijn.
Een routeberekening van tevoren kan natuurlijk niet afhankelijk zijn van de akties van de bestuurder, dat is alleen bij herberekening na de aktie. Als er een doorsteek is, dan wil je die ook in de berekende route zien.
Persoonlijk snap ik niet waarom er zo halsstarrig aan die “ground truth” wordt vastgehouden hier?
Veerroutes, historische (vee) routes staan toch ook gewoon in OSM.
En dan nog niet te spreken over gemeente, provincie en landgrenzen.
Als je de hele dag een veerpont heen en weer ziet gaan en deze op verscheidene locaties goed staat aangegeven, zoals in de meeste gevallen zo is, dan vind ik het best logisch om deze te mappen.
Historische routes horen niet thuis in OSM, tenzij ze goed staan aangegeven, maar dan zijn ze niet meer historisch. Zo vind ik ook dat vroegere tramroutes waar nu wegen en fietspaden liggen best wel uit OSM mogen verdwijnen op plekken waar er van die vroegere tramroutes niets meer zichtbaar is (Spijkenisse-Hellevoetsluis is zo’n geval).
Het al dan niet mappen van grenzen is een weloverwogen besluit geweest van nog voor 2010, ik denk 2007 of 2008. Dit staat goed gedocumenteerd in de archieven van de OSM-Talk mailing list. Dit onderwerp is hier verder irrelevant.
Als ergens geen pad ligt, wat wil je dan precies mappen en hoe kunnen andere mappers dit verifiëren? Hoe verhinder je dat een mapper dit weghaalt omdat hij/zij op locatie geen herkenbare dingen ziet? Hoe verhinder je dat iemand ergens zo’n pad mapt waar deze volgens de richtlijnen van de veiligheidsregio’s niet hoort te liggen? Hoe verhouden de richtlijnen van derde partijen (zoals de veiligheidsregio’s) zich tot onze richtlijnen? Dat zijn belangrijke vraagstukken als het om “ground truth” gaat. Persoonlijk ga ik liever niet hierover discussiëren en ik verwijs hiervoor naar de richtlijnen die OSM al sinds het prille begin heeft en waar de overgrote meerderheid binnen de OSM-gemeenschap het over eens is.
Als voorbeeld de https://wiki.openstreetmap.org/wiki/Tag:route=transhumance?uselang=nl
Sommige veerboten varen veel minder frequent hoor, soms maar om de paar dagen.
Voor beide gevallen geldt ground truth. We mappen ze mits ze verifieerbaar zijn op locatie. Dat is nu ook het plan met de routes van de veiligheidsregio’s.
Volgens mij moeten we het situatie niet groter voordoen dan wat het is; we weten nog niet over welke aantallen doorgangen we het hebben. Overigens gaat het, zoals Peter al zegt, om stukken land waarover met de eigenaar is afgesproken dat deze worden vrijgehouden voor de brandweer. Het is dus niet geheel aan de bestuurder om een stuk grond om te ploegen. Het gaat hier dus niet om een incident op een weiland, maar (ergens) aan de andere kant van het weiland. Het stuk land wordt dus echt als doorsteek gebruikt.
Enfin, verder niks toe te voegen behalve: wordt vervolgd!
Wellicht zou iemand ook Template:NL:Map Features:emergency willen vertalen. Deze lijst staat op de pagina NL:Kaartelementen.
In principe zou ik een groot deel ook zelf kunnen vertalen, maar de mensen die contact onderhouden met de veiligheidsregio’s hebben meer kennis over dit onderwerp.
Er is al een vertaalde versie van: https://wiki.openstreetmap.org/wiki/Template:NL:Generic:Map_Features:emergency
Er staat een woord “Generic” extra in de URL. Hoe het precies zit met het includeren van zo’n vertaald template in een pagina weet ik niet. Misschien had dit ook niet moeten bestaan maar horen de vertalingen in één generieke template ingesloten te zitten?
Ik heb nu op de NL:Kaartelementen pagina de link gemaakt naar de vertaalde pagina: https://wiki.openstreetmap.org/wiki/NL:Kaartelementen#Emergency
Het heet nu alleen geen “Noodgeval” meer zoals bij het onvertaalde sjabloon/template, maar die vertaling vond ik sowieso al niet goed aansluiten op de inhoudelijke betekenis.