role route relation foot en vluchtheuvel

Route relation foot

Bij vluchtheuvels worden rijbanen gescheiden in lanes.

Voor een bicycle route relation gebruikt men de member role forward or backward. Dat is correct. Vanwege het rechts houden en/of verkeersdbord op de vluchtheuvel.

Maar bij foot is het een ander verhaal, de keuze waar je loopt bepaal je zelf.
Dus links of rechts van de vluchtheuvel kan je kan beide richtingen op.

Is er wel een goede member role om dat aan te geven binnen een route relation.
Geen backward of forward, maar iets dat beide richtingen aan geeft.

Roles_for_recreational_route_relations

of is dat role:main?

Voor mijn gevoel niet. Er mist een member role value.

Role:main

Is er een manier om alle roles inzichtelijk te krijgen?

in een xml staat de text line role=

....
<member type="way" ref="1" role="main"/>
.......

https://wiki.openstreetmap.org/wiki/Relation

het is geen key of value, inzichtelijk met een taginfo site.

Ik zou gewoon lamgs éen kant van de vluchtheuvel routeren.

Zelf doe ik het ook vrijwel altijd maar aan een kant van de vluchtheuvel. Als er een logische kant is, bijvoorbeeld doordat je vanwege aansluitende wegen aan een kant van de weg loopt, dan kies ik die kant. Meestal is het echter willekeurig.

Ik ken wel een plek waar de wandelroutestickers aan de rechterkant van de straat op de lantarenpalen geplakt zijn. Daar heb ik bij een rotonde wel forward en backward gebruikt.

Als ik het goed begrijp is het probleem vooral dat je in de relatie een van de twee takken moet kiezen, terwijl ze op de grond allebei in de route horen.

Als je eenmaal gekozen hebt hoef je geen rol te geven (default=main). Als je ze beide invoegt, moet je ze aan een richting toewijzen, en dat is willekeurig (dus geen ground truth) want de voetganger kan allebei de kanten gebruiken voor elke bewegingsrichting.

Dus je vindt dat er een rol zou moeten zijn om te zorgen dat je beide takken toe kan voegen waarbij ze allebei zowel forward als backward kunnen zijn. Kan ik inkomen, theoretisch, maar praktisch gezien lijkt de oplossing mij erger dan de kwaal!

Op een overgang, haaks, kruising met een provinciale weg, heb ik voor foot net zoals bij bicycle forward en backward gebruikt, wat ik eigenlijk niet correct vindt, ik vindt wel dat de beide lanes binnen de relatie horen, dat weegt mij dan even zwaarder.

Bekeken vanuit een Nederlandse situatie.

Ik mis een member role value, waarbij in JOSM relatie wel de splitsing aan geeft.

foot zou dan forward backward kunnen negeren, keuze route engine, maar het is een wereldwijd tagging systeem, regels die voor Nederland gelden, gelden niet voor andere landen, daarom zou een wereldwijde mogelijkheid moeten bestaan om dit aan te geven.

Dat zou weer een extra soort rol zijn. Eigenlijk is forward/backward (directional role) al niet te kombineren met alternative/approach/connection/excursion (functional role). Je kan bijvoorbeeld zo’n splitsing hebben in één bewegingsrichting van een aanlooproute. Al zal dat zeker bij wandelen weinig voorkomen, maar ik vind het ook belangrijk om al het routegebeuren generiek te houden. Dus voor alle transportmethoden gelijk.

Als je de twee takken persee alletwee wil invoeren, kan je wel een van de twee ways in de relatie de rol alternative geven. In principe kan een gpx-export daar dan op filteren. Dat moet elke data-user dan wel zelf regelen, want de export van overpass doet dat vziw niet.

Waar gaat dit over? Hoe waarschijnlijk is het dat een wandelaar zich door een routeerder aan de in looprichting linker- of rechterzijde van een weg laat leiden?

Het lijkt mij dat deze “mathematisch juiste” routering weinig oplevert en een gpx-track is niet nauwkeurig genoeg, normaal gesproken, om de linker of rechter zijde van de weg juist weer te geven.

Besef dat het onderhoud en wijziging van dergelijk routeringsfinesses door anderen bijna onmogelijk wordt. Ook dat vind ik een argument dat we zeker niet uit het oog moeten verliezen.

Hm… dat ben ik niet helemaal met je eens. Voor een opgenomen track geldt het wel, maar een exporttrack moet zo precies mogelijk de wegen aangeven die in OSM in de relatie zitten. Anders kan je zomaar de verkeerde kant van een snelweg of een kanaal opgestuurd worden.

Ik vind het trouwens zowizo zonde als je een route eerst naar gpx moet vertalen, waarna een toepassing de gpx (punten) weer naar de route (wegen) moet gaan terugvertalen. Maar áls het dan zo moet, dan moet de gpx wel precies de aangegeven ways geven. De overpass export doet dat, als je tenminste de routerelatie in orde hebt, dus 1 aaneengesloten keten van wegen zonder onderbrekingen en zonder verdubbelingen.

Daar heb je gelijk in :smiley:
Ook al geeft jouw gps aan dat je aan de linkerkant van de weg loopt, zelf zie je natuurlijk wel dat je rechts loopt; of over de middenlijn.

De rest van mijn betoog handhaaf ik. :slight_smile:

En: het is sowieso (uit het Duits).

Ja, ik heb de spelling vernederlandst.