Paalnummers MTB-route en aanvullende informatie toevoegen

Het is voor een particulier landgoed dat een MTB route heeft aangelegd. Dus geen NM, SBB of iets dergelijks. Voor de boswachters/beheerders is het goed te weten waar welke paalnummer zich bevindt voor geval van meldingen van calamiteiten. Heb er tevens de ruiterknooppuntnummers op gezet.

Dat is misschien ook wel slim idd, ruiterknooppunten toevoegen. Hoe heb je deze dan toegevoegd? en heb je deze van veldwerk of uit een kaart?

Bij paal met route symbooltjes. Maar dan wel op de plaats, waar ze echt staan.
Combinatie met accesspoint

tourism=information
information=route_marker of trail_blaze
emergency=access_point
support=pole kan ook een tree zijn
De vraag is wat is de Engelse benaming voor een houten/plastic paaltje, post.

https://wiki.openstreetmap.org/wiki/Key:information
https://wiki.openstreetmap.org/wiki/Key:support
https://wiki.openstreetmap.org/wiki/Key:emergency

De ruiterknooppunten en emergency_access_points heb ik obv veldwerk/survey ingetekend. Als je op het kaartje in de eerder post klikt op zo’n access point kun je naar het punt klikken in OSM. Daar kun je weer op de changeset klikken en dan zie je dat ik bij source heb ingevuld “survey.” Veel mappers vullen de source in zodat je kunt zien wat de bron van de informatie is.

Dit onderwerp is al wat ouder maar ik heb hierover een paar vragen over hoe wat dat het best kunnen mappen. Maar eerst even de aanleiding voor die vragen.

Onlangs kreeg een mountainbiker een hart stilstand op het parcours van Den Treek Henschoten. Hij werd snel gevonden want het was op een zondagochtend en dan is het altijd druk. Vervolgens kwamen de hulpdiensten in actie. Politie, brandweer, ambulance en zelfs een heli. Het probleem bij dit soort calamiteiten is om goed door te geven waar je je bevindt. Op het parcours zijn paaltjes geplaatst met een nummer erop. De meeste daarvan zijn geplaatst bij de wat bredere paden zodat de auto’s van hulpdiensten er kunnen komen. Deze locaties zijn bekend bij de 112 meldkamer en hiermee kunnen ze de exacte locatie doorgeven aan de auto’s van de politie die er direct naartoe navigeren. Wellicht werkt dat ook zo voor brandweer/ambulance. Dus als de 112 meldkamer weet waar je je bevindt dan kan hulp zsm ter plaatste zijn.

Het probleem is vaak dat het moeilijk is uit te leggen waar je bent zo midden in een bos. Als je weet dat je bv ergens tussen nummer 8 en 9 bent dan ben je al een heel eind. Maar moet je dan eerst verder fietsen om dat nummerpaaltje 9 op te zoeken en weet je dan pas waar je bent? Dat kost kostbare seconden. Beter zou het zijn als mountainbikers de route en de nummers zichtbaar zouden hebben op hun GPS- of Telefoonscherm. Als al die punten in OSM staan dan is het al niet meer zo moeilijk om daarvan een GPX bestand te maken met bv Overpass turbo. Kaartenmakers kunnen het ook renderen. Osmand laat deze al zien en als je er op klikt krijg je het nummer/ref te zien. Het mag duidelijk zijn dat ik het mappen van deze highway=emergency_access_point aanmoedig. Ik heb alleen wel wat vragen over hoe we dat het best kunnen doen in het geval van een MTB route (round trip).

  1. Onderdeel van de route relatie?
    De emergency_access_point is onlosmakelijk verbonden met de route want de nummering volgt exact de route. Ik heb deze nu toegevoegd aan de routerelatie. Dus behalve de wegsegmenten heb ik ook de losse knopen, die momenteel net naast de wegsegmenten liggen, opgenomen in de relatie. JOSM piept wel als ik dat doe. Ik heb die punten geen “role” gegeven omdat ik niet weet welke ik zou moeten gebruiken. De vraag is of het terecht is dat deze punten in de relatie zijn opgenomen en zo ja …welke “role” zouden deze dan moeten hebben?

  2. Op of naast de weg?
    Zoals gemeld heb ik de emegency_access_point naast de weg gemapt. Zo goed mogelijk op de exacte locatie. De vraag is of ik het niet beter op de (de kruising van) wegen had moeten plaatsen. Wellicht wordt door de key “highway” al gesuggereerd dat het ondereel uit zo moeten maken van de highway = * . Dus net zoals knooppunt nummers van de knooppunt netwerken. Net als knooppuntnummer bevinden ze zich bijna altijd op een punt waar een keuze mogelijkheid is een andere highway te nemen.

  3. Route opknippen.
    En als het punt op de weg, in plaats van naast de weg, wordt gemapt is het dan ook niet logisch om losse relaties te maken van alle stukken weg tussen 2 nummers? Eigenlijk alles analoog aan een knooppunt netwerk. De MTB van Den Treek Henschoten bestaat uit 2 rondjes die voor een deel overlappen. Daarnaast is er een route verkorting dus ook op dat punt er er wel een keuzemoelijkheid. Die routeverkorting heb ik nu gemapt obv deze wiki van Peter Elderson.

Als de nummers meestal keuzepunten zijn, kan het als een knooppuntroute werken. Het is niet erg als erg stukken tussen zitten waar je alleen een aantal nummers moet passeren zonder afslagmogelijkheid. Dan kan je het ook als knooppuntnetwerkje mappen. Op een fietskaart zouden de nummers dan zichtbaar worden, en de refs bij de routedelen ook.

Let op: dan is hij wel opgeknipt dus je kan hem niet in 1x plannen/routeren, je moet dan een knooppuntroute plannen en daarlangs navigeren.

Onderdeel van de routerelatie(s) hoeft MI niet, de ruimtelijke associatie is MI voldoende en als je ze als knooppunten invoert zitten ze er al in want dan zijn ze onderdeel van de wegen.

Het volstaat niet fotograferend voorbij te rijden aan die paaltjes, dan zijn ze niet leesbaar.
Op de Kalmthoutse heide heb ik ze stilstaand moeten fotograferen.

Hier lijkt me niet sprake van bewegingsonscherpte maar een probleem met de autofocus van de camera (smartphone)

Is dat nog wel nodig? Sinds vorig jaar kan de meldkamer van 112 zien waar je bent via AML. Lijkt me uitermate geschikt als je ergens in het bos bent.

Onlosmakelijk verbonden met de route lijkt me wat te absoluut. Als er meerdere routes mogelijk zijn neem ik aan dat de paaltjes voor meerdere routes gelden, en ook zonder deze speciale routes zijn het nog steeds oriëntatiepunten voor de hulpdiensten.

Hoe men tot een bepaalde nummering komt is niet erg OSM-relevant, het zijn paaltjes met een label. Hadden ook letters kunnen zijn, of codes zonder volgorde.

Mij lijkt dat de ruimtelijke associatie genoeg zegt.

De vraag met opnemen van losse punten in de relatie(s) is: wat bereik je ermee, wie heeft dat wanneer nodig? En de vervolgvraag: is het realistisch dat deze OSM-registratie daar ook voor gebruikt gaat worden?

Hulpdiensten zullen neem ik aan niet naar deze routerelatie kijken, maar naar hun eigen noodroutering: hoe kom je met het benodigde materieel het snelste bij het doorgegeven punt.

Nu ben ik benieuwd, ik heb hier een compleet nieuwe rendering voor moeten maken, en dan nog krijg k de labels er niet bij… welke rendering gebruik jij dan? of zijn het bij jou POI’s?

Ik heb ze nu allemaal los gemapped, dit aagngezien ik zo de “fietsroute-mensen” niet stoor met mijn obsessie om objecten voor de openbare orde en veiligheid te mappen… De eindgebruiker ziet het verschil natuurlijk niet, dus het maakt in dat opzicht niet echt uit. Men kan misschien wel alle paaltjes in een relatie zetten, en deze vervolgens aan de MTB relatie toevoegen? of is dit technisch gezien niet mogelijk of niet volgens de “guidelines”?

In de openfietsmap stijl zie ik ze gewoon, werkt ook in de standaard osmand stijl (offline vectorkaart). Bij de online tegels zie je ze niet.

ik zie het nu ook idd, hebben ze het nu wel toegevoegd… Ga zelf nog wel wat onderzoek doen naar hoe ik de rel er naast kan zetten als label… Misschien weet een van jullie hoe dat moet in een custom render?

Ik weet niet precies hoe dat bij relaties werkt maar bij de poi label heb ik het even getest door in de default.render.xml file deze regel aan te passen en nameTag=“ref” toe te voegen:

<case minzoom="16" tag="highway" value="emergency_access_point" nameTag="ref" textOrder="157"/>

Resultaat:

Goeie vraag. Omdat de vraag om die punten op een kaart te laten zien kwam van de meldkamer ga ik er maar van uit dat het nog steeds toegevoegde waarde heeft. Ik zou het eens aan een bekende van mij kunnen navragen want die werkt bij de politie. Wellicht weet hij hoe het zit.

Even speculeren:
Locatie/GPS is onnauwkeurig in een nat door bladeren bedekt bos.
Er is geen bereik voor de telefoon waardoor je je eerst moet verplaatsen om te kunnen bellen en dat is dan weer de verkeerde locatie.

Ik zie het verschil niet echt met knooppunten in fiets/wandelknooppunt routes niet. Die nummers zijn ontstaan doordat die routes daar lopen en dat geldt hier (en op andere MTB routes) net zo. Knooppunten in fiets/wandelroutes worden in een relatie opgenomen dus waarom zou dat niet gelden voor emergency_access_point in de MTB routes. Die punten hebben naast een route volgorderlijkheid ook nog een extra functie maar dat hoeft m.i. niet te betekenen dat ze daarom anders gemapt zouden moeten worden dan fiets/wandel knooppunten.

Het voornaamste verschil is m.i. dat MTB routes niet een echt fijnmazig netwerk is. Ze bestaan meestal uit een rondrit die op een beperkt aantal punten keuzes hebben voor mountainbikers. Soms overlappen stukken van routes of heb je verbindings stukken. Of dit rechtvaardigt dat het anders gemapt zou moeten worden is voor mij nog wel de vraag.

Ik dit weekend ook de meeste punten van de MTB route Leersum gemapt. Het grote verschil tussen Leersum en Den Treek Henschoten is de paaltjes dichtheid. In leersum zijn het er bijna 3x zo veel per afstand. Sommigen staan zo dicht bij elkaar dat ik me afvraag of het wel verstandig is om losse relaties te maken van de segmenten tussen de nummers. Het betekent dan ook dat er wegsgmenten opgeknipt moeten worden en dat vind ik wel een nadeel.

Hmm, werkt voor mij niet echt… zou je misschien de rendering file willen delen? dan kan k eens kijken hoe jij het gedaan hebt?

Probeer deze eens https://drive.google.com/file/d/1GHl5yiIvSW0R3oN23nns2Fxg6UJGV27l/view?usp=sharing
NB je moet wel telkens Osmand geforceerd afsluiten als je de render file hebt aangepast anders zie je de oude versie nog.

De knooppunten in een knooppuntnetwerk zijn ontworpen als knooppunten, ten behoeve van het plannen van eigen routes. (Bijna) elk knooppunt is dan een keuzepunt; iedere geplande route is anders, en de uitvoer bestaat uit de reeks van nummertjes die je volgt voor de de jou ontworpen route. Tussen de knooppunten zitten ongenummerde pijltjes en paaltjes die de weg naar het volgende knooppunt wijzen.

Dat is wat anders dan een vaste route met enkele varianten.

Als je er een knooppuntnetwerk van wil maken, hoef je alleen de de echte keuzepunten als knooppunt invoeren en de verbindingen tussen die punten als node2node routes. De rest is geen knooppunt en speelt geen rol bij het maken van de route. Die stukken zonder keuze wil je dan ook niet allemaal opknippen in mikrosecties lijkt me. Als je niet op de knooppuntmanier gaat plannen, heeft het MI zowizo geen nut om het als knooppuntnetwerkje in te voeren.

Bij node2node knooppuntverbindingen hoeven de nodes niet als leden in de relaties te zitten. Het mag wel, en dat heeft simpelweg te maken met het invoeren en onderhouden, je maakt dan veel minder fouten bij het mappen. Software doet er niets mee, hoeft ook niet want de nodes zitten er al in omdat ze deel van de wegen zijn (eerste node van de eerste weg, laatste node van de laatste weg).

Als de paaltjes los naast de route(s) gemapt zijn, dus niet als intersectie-nodes, kan je niet op de knooppuntmanier plannen. Je kan ze wel als POI betrekken bij navigeren/routeren. Dan is de geografische nabijheid de verbinding. (“Je nadert Noodpunt vijfendertig”).
Wat voegt het opnemen in de routerelatie dan toe? (open vraag, ik ben er niet op tegen maar als het niets toevoegt waarom zou je de moeite dan nemen?)

Dank voor je reactie

Het was niet zozeer mijn wens om er een knooppuntnetwerk van te maken maar ik heb wel even gekeken hoe die werken en zag naast wat verschillen ook veel overeenkomsten. Ik wil ook niet perse iets nieuws introduceren maar zag wel dat als je de paaltjes niet opneemt op de weg maar ernaast dat het dan lastiger wordt om een verband te maken tussen de route en de nummers. En zo’n verband lijkt mij wel heel erg logisch. Als we die paaltjes nu als node opnemen op een wegsegment is dat probleem al opgelost want dan is er altijd af te lijden welke nummers in welke volgorde bij welke route horen. Dan hoeven we ook niet al die stukken tussen 2 punten op te knippen in losse relaties.

Mijn voorstel zou dan zijn om de nodes van de paaltjes te verplaatsen naar een node in de weg (meestal op het kruispunt van highways) en de nodes zelf uit de relatie te halen. Voor verbindingsstukken maken we dan in die relatie een aparte role aan. (bv alternative, approach). Zoiets?