Gebruik van roles in hiking/foot relations

Er ligt een voorstel voor het gebruik van roles voor de leden van wandelrouterelaties.
https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles
De hoofdreden is om alternatieven anders te kunnen renderen, en om alternatieven uit te filteren ivm data-gebruik zoals export als track, lengteberekening en hoogteprofiel.

De discussie op de tagging list is vrijwel stilgevallen en de voorsteller doet al maandenlang niks meer. Er was wel veel steun voor het idee maar de discussie ging nog alle kanten op. Ik zou het toejuichen als een basisafspraak komt, liefst 1 op 1 toepasbaar op alle recreatieve routes.

Als ik alles waarover nog geen duidelijkheid of consensus was weglaat, komt het neer op:

• Ken een role toe aan de leden (wegen en/of relaties) van de routerelatie die niet tot de hoofdroute behoren.
• role values zijn: alternative, approach, excursion

alternative: Een alternatief deel van de route, bijvoorbeeld een hoogwatervariant, seizoensvariant of hondenvariant.
approach: Aanlooproute vanaf bv een treinstation, of een linkroute tussen twee verschillende hoofdroutes
excursion: Je gaat van de route af voor bv een berghut, een kasteel, een rondje rond een meer of een uitkijkpunt, waarna je de hoofdroute weer vervolgt.

Deze drie rollen dekken de varianten van alle LAWen , SPen en andere genmarkeerde lange wandelroutes in Nederland (met uitzondering van de Waddenwandel LAW, want die bestaat uit rondjes op de eilanden. Meer een collectie dan een route dus. )

Omdat onze LAWen en SPen al bijna volledig onderverdeeld zijn in een hoofrouterelatie en variant-relaties, is het een simpel en afzienbaar klusje om deze basisrollen toe te kennen aan de subrelaties. Mijn voorstel is om dat voor een aantal paden gewoon maar even te doen, met een note erbij dat het voorlopig is. Renderers en data-users kunnen het dan voor een pilot gebruiken. Mocht het niet aanslaan, dan haal ik het wel weer weg.

Gedachten, opmerkingen, ideeën?

**Bijgewerkt 2020-06-17:
Het aangepaste voorstel https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles is aangenomen met 36 stemmen voor, 1 tegen en 1 onthouding. **
Merk op dat de toepassing verruimd is naar (bijna) alle soorten recreatieve routes. Bovendien is de rol “connection” toegevoegd. Daaree knoop je twee routes aan elkaar, en je neemt de verbinding in beide routes op.

De rollen zijn in Nederland op alle LAWen al toegepast. Zodra renderers (met name Waymarkedtrails) het oppakken zal het ook voor publiek zichtbaar worden.

Ja, waarom alleen op wandelroutes (of heb ik je uitleg niet goed begrepen). Dit zou net zo goed voor fietsroutes (MTB-routes) kunnen. Zo kun je in de MTB-route van Ter-Apel er voor kiezen om door de Ruiten-Aa te gaan, of er omheen.

Dan rijst meteen de vraag. Heb je 1 hoofdroute en een alternative, of een hoofdroute die splitst in 2 alternatives om weer samen te komen op de hoofdroute.

Ik denk dat deze basisrollen ook op andere recreatieve routes gebruikt kunnen worden. Maar ik ben alleen goed thuis in hiking/foot routes, dus hoor graag van anderen of dat klopt.

Het idee is wel dat je 1 hoofdroute benoemt en de andere alternative maakt. De alternative route wordt dan bv een streepjeslijn. Als je ze allebei main (=zonder role) maakt, is er geen verschil met nu, dus ze renderen prima maar je kan er dan niet 1 routeerbare gpx van maken, geen enkel hoogteprofiel en geen lengteberekening voor 1 van de twee.

Duidelijk. Alhoewel, je antwoord dan. Bij het door mij genoemde voorbeeld is het me niet duidelijk wat de hoofdroute is

Ik ben er tegen zoals het in het voorstel staat.
Dat wordt een zootje binnen de kortst mogelijke keren.
Hoe minder rollen op de afzonderlijke members van een routerelatie hoe beter.
Voor aparte takken moet je aparte relaties aanmaken.
Dat je dan boven in de routekop van zo’n relatie aangeeft wat voor relatie het is, prima.
Maar geen rollen op de aparte members.
Dan ben je ook zo het overzicht kwijt.

En werk dan met bijvoorbeeld route:type=
Dat is voor renderers en stylesheets ook veel duidelijker

Persoonlijk had ik graag eens een poos rust in de tent gehad, maar dat terzijde.

Nog even aanvulling
Als je dit op de afzonderlijke members gaat zetten, ben je naar mijn idee, datatechnisch een niveau te laag.
Dat zie je ook in het voorbeeld, een heel rijtje alternative’s dan weer een rijtje main.

Als dat zo door gaat, verlies je binnen de kortste keren het overzicht

Dat roept er om dat je die members gaat groeperen en daarvoor heb je een aparte routerelatie nodig.

Bovendien vliegen in JOSM je foutmeldingen om de oren, daar hebben we nu al veel last van bij wandelroutes.
Dan moet je aparte presets maken met al die rollen erin.

Een ander bezwaar tegen rollen op de aparte members is, dat je gaten krijgt in de routelijnen en dus niet meer goed kunt zien of het gat een fout is of een gat tussen bijv. main en een alternative.

Wat hier als role wordt gepresenteerd is een functie van de route en geen functie van de member en moet dus in de route eigenschappen.

Een routerelatie kan in verschillende samengestelde routes voorkomen met verschillende rollen. Waymarkedtrails heeft aangegeven dat rollen voor de members juist gewenst zijn om onderscheid te kunnen maken tussen varianten en hoofdroute. Wat ze doen is nog vóór het weergeven van routes op basis van de member roles filteren welke members meegenomen worden en welke niet. Het oplossen van de relatiehierarchie zit ook in die verwerkingsslag.

Met andere woorden, variant of niet is dus een eigenschap van de members binnnen de relatie en niet van de member-relatie.

Het voorstel is zo dat ook afzonderlijke wegen een member role kunnen hebben binnen de routerelatie. Aangezien wegen vaak in tig routerelaties voorkomen, kan je niet de wegen zelf taggen als variant, je geeft dan in de relaties aan welke rol die weg daar heeft, en dat de rol kan verschillen tusen de relaties.

Dus op deze manier is het gebruik consistent, of je de route nou hierarchisch opgebouwd hebt of niet.

Dit begrijp ik niet goed. Misschien heb ik niet duidelijk gemaakt wat hier bedoeld wordt?

Er is 1 main route, ik maak daar altijd 1 relatie van. De alternatieven zijn bij mij aparte relaties. Er is een overkoepelende relatie waarin de main route en de variant of varianten members zijn. Dus de enige wijziging die ik nu voorstel is om die overkoepelende relatie rollen aan de members te geven. Op de lagere niveaus verandert helemaal niets.

Hoe zouden daardoor gaten kunnen ontstaan?

Ja, maar jij geeft die rollen aan de relaties.
Ik kijk naar het proposal en zie daar een plaatje waar rollen, zoals alternative, approach zijn toegekend aan de wegen.
En daar baseer ik mijn kritiek op.

Zoals het in plaatje in het proposal staat, zie je meerdere routetypen in 1 route met een batterij alternative en een batterij main. En dan zeg ik dat moet je splitsen in aparte routes

Als je een hoofdrelatie hebt met daarbinnen diverse routes en je kent deze rollen aan de routes toe, dan is het een heel ander verhaal.
Dan ben ik er wel voor, want dat is dan wel duidelijk.

Ja, daarom stelde ik ook dat ik het proposal zo niet bruikbaar vond, en dat ik het alleen op relation members wou toepassen. Maar in het buitenland wordt vaak gewerkt met alles in 1 relatie plempen, daar zou het al een verbetering zijn als alle dubbel opgenomen wegen of losse takken een rol krijgen. Ikzelf wil daar niet aan beginnen, ik doe liever wat extra moeite om duidelijke variant-relaties te maken.

Bedankt voor het kommentaar!

Als je dit gaat toepassen op wegen binnen een routerelatie, hoe ga je dan om met de bestaande rollen forward en backward? Wat doe je als alternatieve route verschillend is voor heen- en terugweg?

De enige mogelijkheid die ik zie is beide rollen combineren met een scheidingsteken. Scheidingstekens worden echter slechts beperkt toegepast, omdat het geen onderdeel is van de OSM-datastructuur. Een rol als alternative;forward wordt niet herkend door datagebruikers omdat dit een andere rol is dan forward.

In ‘superroutes’ die slechts relaties voor subroutes bevatten, lijkt me dit voorstel wel toepasbaar. Dan krijg je een relatie met bijvoorbeeld subrelaties ‘main’, ‘approach’, ‘alternative’, etc. wat dan routerelatie van respectievelijk de hoofdroute, een aanlooproute en een alternatieve routedeel zijn.

Tja, waar er geen verschil is houdt het op! Het probleem van 2 gelijkwaardige routes is wel genoemd in de diskussie maar daar is niks bruikbaars uit voortgekomen dus daar ga ik mijn vingers niet aan branden. Ook zoiets als de jakobsroute, wat in wezen een collectie gelijkwaardige routes is, kun je zo niet oplossen (“gelukkig” is dat in NL niet gemarkeerd…)

Een situatie als: een knooppunttrajektje tussen 2 knooppunten dient als verbindingstakje tussen twee LAW-en (ergens bij Bergen op Zoom heb je dat), dat kan nu wel. Je neemt de relatie van het knoooppunttrajekt gewoon als member op in de overkoepelende relaties van beide LAWen met role=approach.

Dat heb ik in de diskussie ingebracht, maar het is niet opgepakt. Ik wil way members niet uitsluiten, maar zou (mocht het zover komen) in mijn basisvoorstel kunnen stellen dat het niet gekombineerd kan worden met forward en backward zoals dat bij fietsrelaties wordt toegepast, en dat als dat toch zou moeten, aparte variant-relaties gemaakt kunnen worden.

Mijn pilotvoorstel in NL gaat alleen over relation members in wandelroutes, die toch al netjes onderverdeeld zijn. Ik ben wel goed maar niet gek!

Praktisch: ik heb met https://www.longdistancepaths.eu/laws/en/index.php de afspraak dat als zij hun routes weer eens willen verversen, dat ik dan de hele mikmak op onderbrekingen, volgorde etc. kontroleer en zonodig repareer. Kost me 5 a 15 minuten per LAW (tenzij er echt idiote dingen inzitten, maar dat komt eigenlijk niet voor). De volgende keer dat ik dat doe kan ik de members van een paar overkoepelende routerelaties makkelijk even een rol geven, dat kost me hooguit enkele minuten extra.

Voor zover het over een relatie met relaties als leden gaat, zie ik geen problemen. Dit zijn vaak goed gestructureerde relaties, waarbij deze rollen kunnen helpen om duidelijk te maken wat die subrelaties in de route doen. Ik ken meerdere wandelrondjes die aanvoerroutes hebben en dat is toch altijd vervelend om goed te taggen.*

Je spreekt bij forward- en backward-rollen alleen over fietsroutes, maar ik ben ze ook wel eens op wandelroutes tegengekomen. Bijvoorbeeld op een knooppuntenroute waar de stickers op de lantaarnpalen aan de rechterkant van de weg zijn geplakt en dus heen- en terugweg aan verschillende kanten de rotonde oversteken.

• Ze zijn soms ook slecht te volgen. Zo ken ik een route met rode paaltjes, waarbij de aanvoerroutes ook rode paaltjes hebben. Dan kom je op een kruising en gaat de route ineens twee kanten op.

Inderdaad, zelfde advies: zet die variant-roles niet op de losse wegen maar maak er een deelrelatie van.

Het viel me wel op dat veel mensen uit andere landen nog niet goed raad weten met hierarchisch opgebouwde routerelaties. Ze zijn er nu wel aan gewend dat het bestaat, maar zelf eraan beginnen, huuuu! Ik heb trouwens geen overzicht in hoeverre de meeste renderers/routers/data-users de hierarchie goed oplossen. OsmAnd in ieder geval niet, en die kan ook niet routeren langs onze perfekt getagde langeafstandsroutes. Garmin, ook niet.

Aangescherpt voorstel:

• role values alternative, excursion en approachkunnen toegekend worden aan varianten van alle soorten recreatieve routes.
• Hoofdroute krijgt geen rol (none = main)
• roles alleen zetten voor relation members. Daardoor geen conflicten met forward/backward roles van wegen.

(Ik heb het volgende op de tagging list gemeld)

I have tagged relation member roles for 3 recreational foot routes in Nederland:

1. The Roman LIMES trail https://hiking.waymarkedtrails.org/#route?id=9214891
   This national trail has several alternatives and one approach. The main route is the Dutch part of the international LIMES trail.

2. The Floris V trail https://hiking.waymarkedtrails.org/#route?id=9769895&map=9!51.9349!4.6883
   This national trail has three short alternatives and I added one section connecting this trail to the Dutch part of the GR5 (=E2).
   The connecting section has the “approach” role within the parent relation. The connection is signposted on both larger trails and waymarked with the same symbol as the parent trails.

3. Brabantse Vennenpad https://hiking.waymarkedtrails.org/#route?id=9500318
   This is a regional roundtrip trail, it is sectioned for daily stages and includes a number of waymarked approaches to/from train stations.

Dit kostte heel weinig tijd omdat de routes goed ingedeeld en gedokumenteerd zijn. Ik kan alle LAWen en SPen in een uur doen, mocht dit voorstel aanslaan. Andere routes zouden meer tijd kunnen vergen, vooral om ze goed in te delen. Het rollen toekennen gebeurt dan tussen neus en lippen door.

Rollen toekennen aan wegen in routerelaties zou veel tijdrovender en lastiger zijn. Vooral omdat de relatie-editor van JOSM moeilijk kan omgaan met niet-aaneensluitende ketens van wegen. Je zou functies moeten hebben zoals “group the members according to role and sort within the group” en/of “detect and sort chains of ways”. Ik zou eerst de indeling in losse deelrelaties aanpassen en dan rollen toekennen aan de deelrelaties binnen de overkoepelende relatie.

De rollen zoals hier toegekend beïnvloeden de bestaande rendering niet. Ze kunnen rustig blijven staan voor mensen die er mee willlen experimenteren, qua data-use of rendering.

Zelf zou ik al tevreden zijn als deelrelaties met een willekeurige rol (niet-main) ietsjes anders weergegeven worden. Een streepjeslijn voor alternatieven/extra’s is tamelijk gebruikelijk, maar als je een kaart maakt met alle routes dan lopen er soms rustig 8 verschilende routes (regionaal, lokaal, knooppunt, internationaal, landelijk) over 1 weg, en voor elk daarvan kan het de hoofroute of een alternatief zijn… ik zou het niet kunnen oplossen.

Een voortgangsbericht.
Het originele voorstel ligt helemaal stil, de voorsteller reageert niet eens meer. Ik heb nu een basisvoorstel als Feature Proposal op de wiki gezet en de RFC op de tagging mailing list geopend. Punten uit de diskussie hier zijn verwerkt. Punten kunnen natuurlijk hier besproken worden, maar de talkpagina bij het voorstel is de plek voor verbetersuggesties, op- en aanmerkingen.

https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Recreational_route_relation_roles

NB Voor de Nederlandse situatie komt het erop neer dat deze rollen niet aan wegen worden toegekend maar aan relaties (deelroutes). In andere landen zullen ze wel geregeld aan wegen worden toegekend, al denk ik dat de mappers dat snel zat zijn als het om flinke alternatieven gaat.

De RFC is geopend tot 4 juni, daarna ga ik proberen om het in stemming te brengen!

De stemming is geopend, onderstaand bericht is op de tagging-lijst geplaatst.

Hopelijk mag ik ook in dit forum op voldoende steun rekenen!

De toepassing die waarschijnlijk als eerste verbeteringen hierop gaat baseren is waymarkedtrails. Dit voorstel maakt verbeteringen mogelijk voor rendering van alle soorten recreatieve routes, plus een betere hoogtegrafiek en verbeterde gpx-uitvoer.

Voting has started! Voting is open till 2020-06-17.
https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles

The proposal will not change during voting. I will answer clarifying questions. Comments, even if it’s just about wording or examples and doesn’t change the proposed roles, will be considered after the voting.
Thanks everyone for useful comments and suggestions so far. I am confident we will get this improvement done.
I know some people had expected more. And I agree! Even then, please vote yes to this basic proposal, it lays the groundwork for things to come.

Best, Peter Elderson

Heb ik het op deze manier goed gedaan met de sub-relaties?
https://hiking.waymarkedtrails.org/#route?id=11166887&map=16!52.9057!6.3752

Prima, lijkt mij zo!