Vraag over rollen in road route relaties

Ik ben bezig om wat A en N wegen in een road route relatie te zetten. Ik loop bij de N-wegen alleen een beetje vast op de rollen backward en forward. Zie bijvoorbeeld onderstaand voorbeeld.

De N-wegen zijn op veel plekken als 1 lijn getekend ipv 1 lijn voor beide rijrichtingen. Logischer wijs voeg ik de wegen in een relatie dan van een kant toe, dus van rechts naar links over de weg in onderstaand geval. In het geval van zo’n splitsing (meestal bij rotondes en midden-eilanden) moet je dan met rollen werken. Omdat ik ze in dit geval van rechts naar links toevoeg moet als ik goed redeneer de bovenste lijn op onderstaand voorbeeld de rol forward krijgen en de onderste lijn backward (als je van rechts naar links denkt is de onderste lijn terug dus backward). Als ik echter naar de symbolen kijk in de rechter kolom lijkt JOSM ze goed weer te geven als ze beide forward zijn.

Kan iemand mij uitleggen hoe ik de rollen goed toepas hier?

Onderstaande afbeelding is deze relatie: https://www.openstreetmap.org/relation/13094754 op deze plek: https://www.openstreetmap.org/#map=19/51.24727/5.74512

Het moet een forward zijn in beide richtingen.
forward en backward slaan altijd op de tekenrichting van de weg, dus hoe rij je tov de tekenrichting van de weg
In dit geval heb je 2 eenrichting wegen, dus in beide richtingen rij je in dezelfde richting als de tekenrichting van de weg, alleen bij oneway=-1 gaat dit niet op, maar die moet je asap elimineren.

Dus zodra je eenrichting wegen hebt, is de rol per definitie forward.

Verder begin je altijd met de heenrichting en begint de terugrichting op dezelfde plek als de heenrichting, dus de volgorde van de wegen in de terugrichting gaat in de routerelatie tegen de rijrichting in, maar wel met de juiste forward/backward richtingen.

Ah, oke. Duidelijk. Maakt het trouwens niet uit in welke richting in de wegen aan de relatie toevoeg? Nu doe ik ze van rechts naar links maar het kan natuurlijk ook anders om. Is daar een (ongeschreven?) afspraak voor? Ik voeg ze meestal van toe afhankelijk van wat ik bij de tags from=* and to=* zet.

Dat zou ik niet weten, ik werk alleen met fiets- en wandelroutes en daar ligt de volgorde meestal vast.

In jouw geval zou ik ook voor from richting to als richting kiezen.

Dankje voor de uitleg. Hier kan ik even mee vooruit. Nu volgen de symbolen in de rechter kolom elkaar ook goed op wat ook het valideren makkelijker maakt.

Wat is de reden hiervoor eigenlijk? Heb laatst een ringweg toegevoegd als relatie, maar dat niet zo gedaan volgens mij…

Wat de reden is, weet ik niet.
Dat is ooit in een ver OSM verleden door mensen bedacht, die de eerste routes in OSM hebben ingetekend.

Dat je het nu zo moet doen, is dat dan het relatiewindow aan de rechterkant sluitende lijntjes weergeeft, waardoor je een route snel visueel kunt controleren.
knooppuntnet.nl hanteert voor de controle ook deze regel.

De meest plausibele verklaring in mijn ogen is, dat het routerelatiewindow van boven naar onderen werkt en je dus beide “takken” ook van boven naar onderen wilt hebben. Anders wordt het lastiger om het einde te vinden.

Ah, dus dat rechter op onderstaande afbeelding is wat je wilt krijgen. Ik had er idd al een aantal gemaakt die niet aan de zelfde kant begonnen. Opzich niet zo’n probleem als beide rijrichtingen dan maar wel sluitend zijn. Dan kun je beide rijrichtingen alsnog goed valideren. Maar goed, zal het ook aanpassen als dat de standaard is.

Mag ik vragen wat het nut is om een dergelijke relatie te maken? 1 weg 1 relatie.

Je hebt dan 1 object voor een weg. Dan kun je dus gemakkelijk met 1 object de hele weg zien zoals dit voorbeeld: https://www.openstreetmap.org/relation/13091420
Daarnaast heb je dan ook 1 object om bijvoorbeeld je wikidata aan toe te voegen. Dus dan heb je je wikipedia data + de geometrie in OSM die het wiki verhaal dan verbeeld.

Daarnaast biedt dit mogelijkheden om bijvoorbeeld met een dergelijke tool de weg te valideren: https://k1wiosm.github.io/checkautopista2/?id=13091420&lat=51.3126&lon=5.6096&z=11

Daarnaast kun je hiermee een beetje filteren en bijvoorbeeld knooppunten eenvoudiger weergeven. Op de zijarmen daar zitten veel refs van de snelwegen. Dit is dan een vereenvoudigde, opgeschoonde weergave.

Ook kan dit schonere resultaten opleveren (alleen snapt nominatim dat niet voor wegen). Zoek maar eens op “Nederrijn”. Dan krijg je 1 zoekresultaat terug ipv meerdere, kleine losse stukjes.

De heenrichting/rechterweghelft heeft oplopende hectometrering, waarbij de hoofdrijbaan is aangeduid met Re. De terugrichting/linkerweghelft heeft aflopende hectometrering, waarbij de hoofdrijbaan is aangeduid met Li. Als er geen hectometerbordjes staan, kun je in NWB opzoeken wat rechts en links is.

Dat wou ik eigenlijk ook vragen. Het Relations are not categories-principe schrijft voor dat zo’n relatie op een of andere manier meerwaarde moet hebben boven een simpele zoekopdracht voor ways met bepaalde ref/official_ref/carriageway_ref/operator-attributen. Het wegfilteren van zijtakken is op zich meerwaarde, maar dan moet wel duidelijk zijn gedocumenteerd hoe dergelijke relaties getagd moeten worden:

  • Ik zie network=NL:N-road, terwijl A- en N-wegen geen gescheiden netwerken zijn: ze maken deel uit van dezelfde nummering, en sommige routes zijn zowel deels A-weg als deels N-weg.

  • Ik zie name=N280 en ref=N280, maar deze systematiek werkt in het algemeen dus niet omdat sommige routes zowel A- als N-weg zijn.

  • Sommige routes hebben bovendien gedeeltes met verschillende wegbeheerders, dus name=Rijksweg 15 klopt bijvoorbeeld ook niet.

  • Sommige routes hebben gaten waarin een dubbelgenummerd stuk weg van een ander officieel wegnummer wordt geleend om het gat op te vullen. Het lijkt logisch om die geleende stukken mee te nemen, maar dan moet je wel verbindingsbogen meenemen in de relatie die officieel geen hoofdrijbaan zijn.

Ik zou dan uitkomen op iets als network=NL:national en ref=280 (zonder A of N). Voor S-wegen en andere regionaal genummerde netwerken kun je dan een andere waarde voor network=* nemen.

Dat artikel is gericht aan wikipedianen.
Wat hebben wij daar mee te maken?

… dat het hiervoor bedoeld is? Staat letterlijk op die pagina genoemd als voorbeeld:

Voor ik hiermee begon heb ik gekeken of er al bestaande relaties waren, en die waren er in Groningen. Ik kon er niets over vinden op wiki dus ik heb die network values overgenomen. Ik heb er geen problemen mee zo. Het is een netwerk van autowegen en niet-autowegen. Ik voeg alles aan een relatie toe op basis van de ref code (en letter) op lijnen.

Maar dan kloppen de ref’s op de individuele lijnen toch ook niet. Wil je daar dan ook alle letters weghalen? Dat een N-weg een stukje autoweg heeft daar zou ik me voor dit niets van aantrekken. Ik zou kijken naar de ref.

Daarom voeg ik ook niet zo snel operator toe aan een N-weg.

Een mogelijk nadeel van het toevoegen van routedelen (o.a. van A- en N-wegen) in een relatie is de grote(re) kans op beschadiging van de relatie na edit-sessies met een minder geschikte editor daarvoor (ID?) en/of mappers die niet in de gaten hebben dat de wegdelen in een relatie zitten. Of hoeven de wegdelen in in dit geval niet netjes gesorteerd te zijn?
Nut en/of noodzaak van het opnemen van wegdelen in een relatie ten opzichte van dat juist niet doen - ik neig naar dat laatste…

Ze moeten wel gesorteerd worden. Maar mijns inzien is het risico op vernieling net zo groot als met bus en andere route relaties. Daar zijn er overigens veel meer van, per weg. Je hebt maar “een paar” A- en N-wegen.

Het beschadigen van routerelaties is een dagelijks terugkerend fenomeen.
Vandaag al weer 11 flixbus routes gerepareerd.
Bij bus 298 Rijnsweerd-Woudenberg zijn zelfs hele wegen uit de relatie verdwenen.
En in Z-Limburg zijn er zo te zien ook nog wel een stuk of 6 beschadigd.

Het opsplitsen van wegen met editor ID is de grote boosdoener in combinatie met de onwetendheid van de mapper.

We zullen er mee moeten leven.

Zo’n relatie van een weg heeft dus geen lang leven.
Wie bewaakt en repareert de beschadigde weg-relaties?

Wegen de voordelen (voor wie?) van de relatie op tegen de voortdurende beschadigingen ?

Mijn advies zou zijn: Niet aan beginnen !!

Ik zie echt het nut en noodzaak van het gebruik voor routes in, daar waar een route ook als zodanig gebruikt kan worden: bus, MTB, knooppunt etc. Zelfs route=road is nuttig daar waar je grensoverschrijdende routes hebt zie:
https://wiki.openstreetmap.org/wiki/Tag%3Aroute%3Droad
Bijvoorbeeld:
https://www.openstreetmap.org/relation/78271#map=9/52.7712/7.7261

Maar om (een stuk van) de n34 in een route te vangen
https://www.openstreetmap.org/relation/8439416#map=10/52.9023/7.1054
zie ik net nut niet van in en hiervoor is m.i. de road route relatie ook nooit bedoeld zie:
https://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

Dagelijks zie ik bij startende mappers onbedoelde beschadigingen aan de routerelaties opduiken.
Het is met OV-, wandel- en fietsroutes al ingewikkeld genoeg om het te onderhouden c.q. te repareren. Laten we het niet ingewikkelder maken dan het al is.

edit… en niet alleen startende mappers zien routerelaties over het hoofd…

Er zijn zo te zien best een aantal landen die ook hun hoofdwegennet in routerelaties hebben gezet. En of een route nu grensoverschijdend is of niet maakt niet zoveel uit. Beide hebben net zoveel nut. Namelijk duidelijk maken welke individuele stukken samen een weg vormen. Hier kun je dan ook aanvullende tags aan hangen zoals wikidata of ze categoriseren in een network=*

En als ID zo’n probleem is met relaties dan moet daar de oplossing worden gezocht. Dan moeten zij duidelijker maken dat er een relatie over een weg loopt en net als JOSM de relatie zelf repareren bij een opsplitsing. Bij JOSM als ik een weg opsplits regelt JOSM zelf alles op de achtergrond. Krijg alleen de melding dat er een route is aangepast. A- en N-wegen worden toch minder vaak bewerkt dan alle kleinere wegen waar bus/wandel/fiets routes overheen gaan.

Ze zoeken voor ID een betaalde developer. Misschien dat die eens naar relaties kan kijken.