Paalnummers MTB-route en aanvullende informatie toevoegen

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?

Nogmaals, je kan alles doen en het is heel logisch, maar waarvoor, dat is de vraag. De richtingen en afslagen zitten al in de route vervat, je geeft immers exact aan welke wegen in welke volgorde gedaan moeten worden.

Wil je dat je navigatie in je oor roept welk nummer je nadert? Nabijheid POI aangeven is een gebruikelijke optie in navigatie, bv veel gebruikt voor parkeerplatsen en en tankstations, maar kan in principe voor alle POIs.

Visueel voor de kaart? POI, hoeft niet precies op de route, kan eigenlijk beter op de exacte plaats van het paaltje staan.

Ik heb nog steeds geen principiële voorkeur, ik denk gewoon hardop.

Worden hektometerpaaltjes langs wegen getagd?

Anwb richtingaanwijzers hebben nummers maar die worden niet echt gebruikt of massaal ingevoerd. De palen zelf worden gemapt op de plaats waar ze staan, niet op de logische intersecties.

In langeafstandsroutes worden soms wel punten opgenomen met een rol, maar VZIW doet niemand daar iets mee.

Over de MTB circuits: Als er een paar standaard varianten zijn die deels dezelfde wegen gebruiken, lijkt het op de bekende paaltjesroutes in een “natuur”-gebied. Deels apart, deels samen, hier en daar kan je overstappen van kleur. Dei worden gewoon als verschillende routes in aparte relaties ingevoerd, ook al zitten sommige paden dan in twee of drie routes. Ik zou kijken naar hoe het aangekondigd en aangegeven staat. Vooraf op de informatie ("De lange route/ de korte route / route A / route B / Beginnersroute / gevordencircuit) en onderweg: wat staat er bij een splitspunt? Een pijltje naar een volgend nummertje, of een routeaanduiding (bv een A of en B, of een kleur, of “variant”)…

Hm, ik geloof niet dat deze breinstorm veel helpt… sorry. Ik moet eerst maar s gaan bergfietsen.

Goeie vraag. Daarop zijn meerder antwoorden mogelijk.
De eerste is dat ik me graag conformeer aan logische of (misschien nog beter ) geaccepteerde manieren van mappen. Niet ieder weer zijn eigen wiel uitvinden. Dan kijk ik naar voorbeelden elders en als je die niet kunt vinden dan naar iets dat er veel op lijkt. Fiets/wandelknooppunten hebben hier veel overeenkomsten mee vandaar. In die netwerken worden de knooppunten op de weg geplaatst en worden de nummers als ref opgenomen in een relatie. Is dat dan wel nodig? Tja het is maar net wat je belangrijk vindt. Ik vind om reden van onlosmakelijk verbonden aan de routes dat dit best logisch is. Zo kun je heel eenvoudig alles wat te maken heeft met de relaties inzichtelijk maken. Misschien is het wat overdreven dat die knooppunten EN in een relatie zitten EN onderdeel uitmaken van wegen die in een relatie zitten maar vind dat niet echt een probleem

Het 2e antwoord heeft te maken het wat ik maar onlosmakelijk verbonden noem.
Stel dat ik een specifieke kaart voor MTB-ers wil maken dan vind ik het belangrijk dat ik naast het tonen van de route ook deze paaltjes kan laten zien. Dan wordt het wel een stuk makkelijker gemaakt dat die paaltjes OF in een relatie zijn opgenomen OF geplaatst zijn op wegdelen die onderdeel uitmaken van de route. Als dat niet zo zou zijn moet je met een spatial query die punten ophalen en dat is verre van ideaal en zal niet altijd tot de juiste resultaten leiden.

Ik krijg de indruk dat jij vindt dat die paaltjes niet in een relatie horen en ook niet als node op de wegdelen gemapt zou moeten worden. Dat komt in vergelijking met fiets/wandel knooppunt routes op mij inconsequent over.

Ik denk ook hardop. Heb momenteel nog niet echt een voorkeur voor OF paaltjes op de weg OF paaltjes in de relatie maar wel graag minimaal 1 van beide

Ik heb vandaag ook een rondje ge-bergfietst. Daar knapt een mens van op. Jij ook? Misschien wel nieuwe inzichten opgedaan. Je weet het nooit.

De intersecties van de wegen zijn de verbindingspunten van de routes in het netwerk, dus ja, die zijn daar nodig. Als je als losse punten zet, moet de planner telkens in de buurt gaan zoeken of er bruikbare wegen liggen voor de aansluiting. Niet onmogelijk, maar 't gaat makkelijker als de boel al aan elkaar zit.

Het knooppuntpaaltje is niet het verbindingspunt, het zegt dat er een verbindingspunt in de buurt is waar de routes op landen. De nummers zijn geen lokaties of objektnummers, ze zijn ook niet nodig voor het plannen, het zijn geheugensteuntjes voor de gebruiker. De software plant wat je op het kaartje klikt, daarna zet-ie het om naar de labeltjes voor het gemak van de gebruiker. De gebruiker doet de ruimtelijke associatie tijdens het wandelen/fietsen.

Voor knooppuntroutes is planning alles. Zonder planning heb je geen route, dan dwaal je maar een beetje rond.
De mtb-routes hebben zeer minimale planning nodig. Een paar herkenningspunten om de varianten aan te geven, dat is het. Het werkt ook zonder al die paaltjes, met alleen pijltjes onderweg.
Hetzelfde geldt voor LAW-routes.

Hoewel die LAWen inmiddels ook een aardig netwerk aan het vormen zijn. Het zou niet slecht zijn als ze daar de kruispunten zouden nummeren dan heb je een mooi LAW-knooppuntennetwerk!

Aangepast: Tikfoutjes

Ik ben nog ff verder gaan zoeken en dacht toen… hoe zit het met die informatieborden die bij sommige fietsknooppunt nummer staan. Hoewel ik had verwacht dat deze op een of andere manier wel opgenomen zouden zijn in een relatie blijkt daar niet veel van. Voor mijn gevoel ook onlosmakelijk verbonden met een relatie maar daar kijkt OSM blijkbaar anders naar. Tja als je het zo bekijkt is het wellicht ook logisch dat de MTB paaltje ook niet in een relatie opgenomen worden. Hoewel ik niet helemaal logsich vind is het wel zo consistent.

Ik heb het even nagevraagd via een bekende politieagent bij de 112 meldkamer. Hier de reactie

Ten eerste werkt het kennelijk nog steeds niet op Iphones, maar alleen op Android.
Ten tweede is het niet erg nauwkeurig.
Ze krijgen een cirkel van 100m ongeveer.
Dit is in een bos natuurlijk niet ideaal, en al zeker niet in een dichtbevolkt gebied. Het geeft dus zeker een indicatie, maar geen precieze locatie.*

Voordeel voor de centralist is vooral dat de kaart die hij voor zijn neus heeft automatisch centreert op de (niet heel nauwkeurige) locatie van de beller, bij aanname van het telefoongesprek.

De hulpverleners op de route hebben die kaart dan weer niet zichtbaar, alleen in het voertuig, en moeten verder afgaan op de omschrijving door de centralist.

*Daarom hebben de nummers op de paaltjes dus zeker nut. *

*Alle beetjes info bijelkaar zorgen uiteindelijk voor het meest complete beeld.
*

Staan die dichter dan 100 meter van elkaar?

Nee effe zonder dollen. Zou je me in het kort uit kunnen leggen wat het nut is om de paaltjes op de kaart te zetten?
Stel ik val tijdens het MTB’en op m’n plaat (niet zo ondenkbaar, gisteren nog gebeurt ), en stel, ik heb een dusdanige verwonding dat ik niet meer verder kan, maar nog wel 112 kan bellen. Hoe helpt het dan dat we de paaltjes gemapped hebben?

Als jij bv Osmand op de telefoon hebt staan dan kun je daar de MTB route op zien (mits gemapt) , de paaltjes met ref/nummers en je eigen locatie. Dan kun jij de meldkamer melden waar je bent. (tussen paaltje x en y, 100m bij paatje X vandaan). De locatie van de paaltjes zijn bekend bij de meldkamer en in hun GIS systeem ingevoerd. Dus kan de meldkamer de exacte locatie van jou doorgeven aan de ambulance/politie. En ook zelfs de locatie waar ze het best met de auto naar toe kunnen rijden om vervolgens te voet of met brancard/AED naar jou toe te gaan.

Mocht je een GPS hebben dan zijn al die paaltjes daar eenvoudig op te zetten door bv uit Overpass turbo dit resultaat als gpx te exporteren. Dan kun je ze dus ook op je GPS zien. Den Treek Henschoten biedt bv de MTB routes in .gpx formaat aan inclusief de paaltjesnummers. En last but not least, ook andere kaartmakers dan Osmand kunnen deze locaties in hun kaart inbakken.

Op de standaard OSM fietskaart zie je bij knooppunt fietsroutes de naam van de verbinding tussen 2 knooppunten. ( Hier de cijfers 51-95). Als zoiets ook in te bakken zou zijn in een kaart dan wordt het al helemaal makkelijk (en snel) om door te geven waar je bent tov de paaltjes. Dat was de reden waarom ik begon te denken om die routes op te knippen in aparte relaties tussen 2 paaltjes in. Of de paaltjes op de weg te plaatsen zodat het af te leiden is.

Je ziet de ref van de relatie. Je kan per sectie een routerelatie maken, en de secties in een andere relatie in de juiste volgorde daarin zetten. De dwarsverbinding kan je in de totaalrelatie de rol “connection” of “alternative” geven, conform de vastgestelde rollen voor recreatieve routes. (Waar de oorspronkelijke “aanstichter” trouwens zelf nog niks mee gedaan heeft…)

Je kunt ook meerdere totaalrouterelaties maken voor verschillende rondjes (bijvoorbeeld als ze aparte namen hebben zoals “De korte lus” en “De lange lus”.)
Of rondje A en rondje B en rondje B met allebei een “connection”.

Om de paaltjes op de kaart te zien kan je ze inderdaad invoeren en taggen als knooppunten op de route, of als POIs ernaast zetten op de echte plek waar ze staan. Beide zijn renderbaar. Omdat knooppunten al renderen is dat het handigst, maar het heeft wel een beetje een luchtje van taggen voor de renderer. Aan de andere kant, knooppunten met twee routes, oftewel genummerde punten langs de weg, zijn bij knooppuntnetwerken heel normaal, in dit geval zijn het er alleen wat veel.

Kun je dan niet veel makkelijker in Osmand je huidige locatie delen (in lat & lon) met de meldkamer?

Edit: typo