Wikipagina over node networks

Ik heb de verouderde wikipagina over fietsknooppuntnetwerken omgeschreven voor alle knooppuntnetwerken. De nieuwe pagina is

https://wiki.openstreetmap.org/wiki/Node_Networks
(werk in uitvoering)

Ik hou me aanbevolen voor kommentaar!

Zeker wb het stuk over tweezijdige fietsroutes, ik weet niet of ik dat helemaal goed heb.

Daarna wil ik verder gaan met de eenvoudigere opzet in plaats van het beruchte tentakelmodel. Namelijk met korte tussenroutes tussen de gesplitste punten. Daar kan ik wel wat hulp bij gebruiken! In principe kan ik het wel verzinnen, maar om het ut te leggen dat andeen het snappen, dat is nog een brug te ver.

Ik wil in eder geval niet die draadmodellen gebruiken. Iets schematischer doen en daaarna een paar echte voorbeelden lijkt me toch beter.

Paar opmerkingen bij een eerste blik:
Onderaan die examples van networks kan wat mij betreft weg. Dat is nog van 2010 of zo. Niet meer relevant.
Voorbeelden vind je genoeg via knooppunt.nl

Helemaal onderaan dat Python script kan ook weg. Nog nooit gebruikt en volgens mij ook verouderd.

Wat tentakels betreft, dat wordt een lastige zolang het nog in knooppuntnet.nl zit.

Ik doe het meestal zo bij een rotonde of kruispunt:
Ik zet een rcn_ref op die nodes waar je werkelijk een beslissing kunt nemen welke kant je uitgaat, dus waar een route aftakt. Dat wijkt af van de tentakel-doctrine, die zegt dat je de eerste node moet hebben van de rotonde of kruispunt. Ik vind dat onzinnig, vaak moet je eerst een stuk de kruising of rotonde over voor je kunt afslaan

Er van uitgaande dat je met forward/backward op die rotonde/kruising aankomt:

  • de heenroute stopt bij de eerste rcn_ref
  • de terugroute loopt dan de rotonde/kruising rond tot aan deze eerste aankomst rcn_ref Dat kan soms flink puzzelen zijn, meestal is het straight forward

Er van uitgaande dat je met forward/backward vanaf een rotonde/kruising vertrekt:

  • de start rcn_ref van de heenroute is diegene, die het dichtst bij het eindknooppunt van de route ligt.
  • de terugroute begint dan bij deze rcn_ref en loopt weer de rotonde of kruising rond.

Forward/backward

forward/backward is tov de tekenrichting van de way en heeft niets te maken met heen- of terugrichting
Je kunt dus het ene stukje weg forward krijgen en het volgende stukje backward en dan weer forward.

  • Eerst de heenroute in de rijrichting
  • Dan de terugroute vanaf datzelfde splitspunt, tegen de rijrichting in, maar wel forward/backward zo gebruiken dat het goed ligt voor de rijrichtng

Het relationwindow in JOSM heeft rechts een routelijn, die bij forward/backward splitst in 2 lijnen en daaraan kun je goed zien of je de route goed gelegd hebt.

Bij een verdeeld knooppunt kun je het beste een knoop-knoop route maken, waarbij begin- en eindknooppunt dezelfde waarde hebben.

Echter bij een verdeeld knooppunt met meerdere kruispunten/rotondes erin met eenrichting paden werkt dat vaak niet. knooppuntnet.nl valideert op de tentakelmethode en zal dan vaak aanslaan op overbodige segmenten.

Je kunt dan ook een route gewoon doortrekken over meerdere kruispunten/rotondes. Dat gaat meestal wel goed. In Rotterdam kun je daarvan een aantal voorbeelden zien, maar in Rotterdam liggen ook nog diverse tentakelroutes.

Mijn adigium is bij forward/backward routes, altijd “rondbreien” De gesplitste routelijn moet in de relation window keurig eindigen in een schuin streepje.

Overigens gebruik ik nog vaak mini tentakels.
Situatie:

  • weg met parallel fietspaden, dus eenrichting paden.
  • aftakkende zijweg
    Dan zet ik 2 rcn_refs, aan beide kanten van de weg op elk fietspad één.
    De route vanaf de zijweg naar het fietspad aan de andere kant zet ik dan in de route met forward/backward

Maar echt nodig is dit niet, we kunnen ook afspreken de route 2 richting te laten doorlopen

  • Ik heb de oude stukjes verwijderd, ik was even blijven hangen bij de tentakels…
  • De standaarduitleg voor routes met backward/forward en de continuity line in JOSM staat er volgens mij wel goed in
  • Knooppuntnet validaties: als er een wezenlijke verbetering is, moet je die niet tegenhouden alleen vanwege knooppuntnet. Wel afstemmen natuurlijk.

Waar logische nodes plaatsen?
"Ik zet een rcn_ref op die nodes waar je werkelijk een beslissing kunt nemen welke kant je uitgaat, dus waar een route aftakt. "
Dus op alle punten waar ofwel een heenroute ofwel een terugroute een splitsing heeft voor diezelfde rijrichting?
En is dat los van waar de paaltjes echt staan?

Omkeren?
Moet je ook rekenen dat je op een kruispunt zou willen omkeren naar de terugroute? Want dan moet er altijd een route van eindknooppunt van de heenweg naar beginknooppunt van de terugweg zijn.

Eenrichting
Als ik een knoop-knoop-routetje maak, weet ik eigenlijk niet hoe toepassingen de eenrichting bekijken. Kijken die naar de way of naar de route?

Het punt met de routes is, dat ze, voor zover ik weet, niet echt als route worden gebruikt. Ik weet niet wat Marc doet met zijn planner in ontwikkeling, maar de gebruikers, die mij regelmatig contacteren over routes kijken alleen of een weg een knooppuntroute heeft. Dus eigenlijk een soort “kleurtje”, niet hoe de route exact loopt of welke richting hij heeft.

Dus niet moeilijker maken dan het al is, geen rekening houden met omkeren of zoiets.

Knopen zetten op kruispunt of rotonde:
Ik kijk dus welke routes ik heb en waar je kunt afslaan naar een andere route.
Zo droog, sec met woorden is dat lastig uit te leggen.
Kijk bijv. hier: https://www.openstreetmap.org/#map=19/53.20429/5.78780&layers=N
De knooppunten 63 staan op de punten waar je kunt kiezen voor een andere route

En hier https://www.openstreetmap.org/#map=19/53.20596/5.80117&layers=N
is het in het extreme doorgevoerd, alle knopen 25 staan op de afslagmogelijkheden

Ik heb even gekeken: Visualisatie nummers
http://mijndev.openstreetmap.nl/~ligfietser/fiets/?map=route&zoom=19&lat=53.20399&lon=5.78755&layers=B000000FTTFTFFFFFFFFFFFF

http://mijndev.openstreetmap.nl/~ligfietser/fiets/?map=route&zoom=19&lat=53.20551&lon=5.80113&layers=B000000FTTFTFFFFFFFFFFFF

Ik gebruik eigenlijk altijd Waymarked Trails, die geeft veel meer mogelijkheden:
25,91 en 64: https://cycling.waymarkedtrails.org/#?map=18!53.2059!5.8011
63: https://cycling.waymarkedtrails.org/#?map=18!53.2049!5.7891
57: https://cycling.waymarkedtrails.org/#?map=18!53.1962!5.8002
21: https://cycling.waymarkedtrails.org/#?map=18!53.2085!5.8211

Bij Waymarked Trails kun je op een route klikken of hem selecteren in een routelijst en dan wordt hij keurig gehighlight en kun je zien dat een route keurig rond gebreid wordt.
Rechts onderaan heeft Waymarked Trails een knopje routes en dat geeft een keurige routelijst.
Je kunt dan ook alle tags van een route bekijken en ook heel mooi de routerelatie in OSM bekijken, bovenaan de route staat een link naar OSM

Bedankt, nog betere visualisatie.

Ik snap het belang van knooppunten op het punt waar je een beslissing neemt, maar het botst soms met andere dingen. Bijvoorbeeld als op de kruising een highway=crossing thuishoort, of een traffic_calming=*. Als de kruising al ‘bezet’ is, dan wil dat even niet (One feature, one OSM element). Dat probleem kom ik geregeld tegen.
Ik heb geen goede oplossing. Dacht ik merk het even op. Wat denken jullie?

@dvdhoven In het eerste voorbeeld, drie keer 63, zie ik dat je geen korte tussenverbindingen gebruikt maar overlappende stukjes route. Eén stukje rotonde heef zelfs drie routes eroverheen. De routes zijn doorgetrokken over knooppunten heen. Dat is toch het tentakelmodel?

Waarom zou een crossing of een assenbreker niet tegelijk een knooppunt kunnen zijn? We taggen toch zowizo niet de paaltjes zelf, maar de intersections waar de routes elkaar treffen?

Een node op een kruising met:

  • highway=crossing
  • rcn_ref=xx
  • network:type=node_netwerk

Dat is een geldige manier van taggen. Je kan de kruising zelf zien als de feature, dan klopt de regel one feature = one element gewoon, en dan is die kruising zowel een oversteekplaats als een fietsknooppunt.

Dat klopt, maar is niet het tentakelmodel. Elke route wordt “rondgebreid”, dus sluitend gemaakt. In het tentakelmodel zijn de routes niet sluitend. Het beste kun je de routes in JOSM in de route editor bekijken.
Maar inderdaad lopen er meerdere routes over de rotonde over elkaar heen.

Dit is nu helemaal de grap, ik maak netjes sluitende routes, ziet er in de route-editor keurig uit, knooppuntnet denkt net als jij dat zijn tentakels en vindt het goed. Bij de tentakels ziet het er niet uit in het relatie-window, daar denk je dat er gaten in de routes zitten.

Prima, doe ik dat! Geen probleem, dus.

Okee, duidelijk. Is inderdaad sluitend voor elke route elke richting zo. Nu snap ik wat je bedoelt met “rondbreien”.

Voor de gedachtengang.

Stel je maakt drie simpele tussenroutetjes, 63-63 (links-onder), 63-63 (onder-boven) en 63-63 (boven-links)
61-63 heen landt op 63O en terug begint bij 63L
17-63 heen landt op 63B en terug begint bij 63O
63-64 landt op 63L en vertrekt van 63B

Dan zouden MI

  • de aansluitingen ook kloppen,
  • er loopt geen enkele route over een knooppunt heen,
  • de echte routes overlappen elkaar nergens
  • en er zijn nog maar drie overlapstukjes van telkens een echte route en een verbindingsstukje.

Volgens mij gaat knooppuntnet dat helemaal goed vinden en ook netjes eroverheen plannen. In de resultaten van de planner zie je dan max 2x hetzelfde nummer verschijnen, en vermoedelijk klopt dat wel met de werkelijkheid op de weg.

Als een route op het ene punt eindigt en op een ander punt begint, heb je weer de situatie, die je met tentakels ook hebt, de routes lopen in de relatie editor niet rond, dus half af en dat wil ik niet. Ik vind mijn methode nu juist simpel en ook makkelijk te leren en je ziet in de relatie editor geen onechte fouten.
Met extra tussenroutes maak je het alleen maar extra moeilijk en ook moeilijker onderhoudbaar.
En verder moet je die tussenroutes ook nog truuken, zo’n rotonde is vaak eenrichting en een eenrichting route kan normaal niet. Nu kun je tegenwoordig oneway=yes in een route zetten, maar ook dat is weer een extra tag.
En ik begrijp niet waar die tussenroutes goed voor zijn.
Die overlap op zo’n rotonde is toch niet erg vind ik.

Ik probeer eea zo te begrijpen dat ik het anderen weer kan uitleggen. Het tentakelmodel kan ik niet uitleggen, jij doet het anders maar je gebruikt het model deels toch wel, dat vind ik ook lastig uit te leggen.

Bijvoorbeeld, normaal gesproken landt een route waar de volgende begint, en niet op een punt ergens langs de route. Maar hier is dat ineens goed. Dat is toch niet simpel?

“Rondbreien” kan ik ook lastig uitleggen. Eigenlijk geef je zo iedere route zijn eigen tussenroutetjes. Sommige stukjes weg staan in twee relaties, andere in drie:

Een route eindigt op een ander punt dan de terugweg begint, dat vind ik dan wel heel makkeljk uit te leggen, want zo is het op de weg ook. k zie daar geen principële fout in, eigenlijk.

Ja, maar dat gebeurt hier toch ook? Route 61 eindigt bij 63, alleen zijn er 3 63’s en die wil je het liefst allemaal bereiken. En bij al die 63’s start weer een volgende route.

En ik vind niet dat ik de tentakelmethode gebruik, echt niet.

Het probleem is, dat je iets op de rotonde moet hebben aan rcn en dat de routes gesloten moeten blijven.

Even het voorbeeld:
Ik kom met de heenroute van 61 bij 63 aan. Die heenroute moet ergens eindigen. Dan is - voor mij - een logische plek de eerste 63.
Dan kom de terugroute en die komt vanaf dezelfde kant als de heenroute en die moet wel de hele rotonde rond om aan te sluiten op de heenroute. De route moet gesloten blijven, dat is het punt en dat is het meest wezenlijke onderscheid tov de tentakelmethode, die de routes open houdt.

Het probleem is hier dat jij niet gewend bent om met heen- en terugroutes te werken.
Voor mij is dat eten en drinken, zo ongeveer.

Inderdaad, dat ben ik niet gewensd en ik prober me uit alle macht in te leven.
Waarom moet elke route persee gesloten zijn? Ze zijn toch ook verschillend voor heen en terug?
Als ik een lange route in stukken hak dan kan zo’n stuk toch ook op een split eindigen, als hij dan daarna weer gewoon op de volgende begin-split aansluit?

Als je geen gesloten routelijn in de route-editor krijgt, weet je gewoon niet of de route stuk is of dat het een bedoelde fout is. En het is gewoon lastig om dat uit te zoeken.
Bij een gesloten route zie je in één oogopslag, dat de route heel is.

Okee, duidelijk.

Ik wil een testje doen. Ik heb een lokatie met drie gelijke punten 63 (toevallig!) en 5 verbonden routes, wat best ingewikkeld getagd is nu, maar na Dick’s uitleg begrijp ik dat nu wel. De drie punten liggen best ver van elkaar, ze kunnen elkaar niet zomaar “zien”. Er is geen heen en terug gedoe daar, dus dat speelt niet mee, de routelijnen in JOSM zijn kompleet.

Als het lukt heeft het de volgende gevolgen:

Knooppuntnet/Planner: Die lijkt nu elk van de 3 63’s als een apart knooppunt te beschouwen en elke tussenverbinding al een apart routetje. Het lijkt erop dat hij zelf de constructie in samenstellende delen hakt en dan pas op de planner zet. Een route eroverheen geeft in het resultaat 3x 63 in de knooppuntenlijst.
De planner zal geen verschil merken van mijn actie.

Waymarkedtrails: toont nu 5 routes die alle 5 alle 3 de knooppunten 63 en de verbindende stukken in zich hebben.
Na mijn actie zal waymarkedtrails elke route laten eindigen bij de eerste 63 die hij tegenkomt (geen split op dat punt) en de 2 verbindingsstukken zijn aparte routetjes.

OSM Fietslaag: Die is nu heel druk, want langs de verbindingsstukken staan al de 5 routerefs die elk 2 nummers hebben. Bovendien staat er een onterechte eenrichtingsarcering op een paar stukken, maar ik vermoed dat dat een andere oorzaak heeft en zowizo verbeterd zou moeten worden.
Na de actie zou er bij elke route 1 routeref moeten staan. (En s kijken of ik de eenrichtingsarcering weg kan krijgen waar die niet hoort)

Knooppuntnet/Analyse is nu best ingewikkeld. Ik zie ergens dat hij de 3 punten als 63a, 63b en 63c beschouwt, en dan mogen ze kennelijk samen in 1 route voorkomen. De exp_rcn_route_rel staat voor het gezamenlijke knp 63 op 5 terwijl elke deelknoop er op het oog maar 3 heeft.
Na de actie zou hij 3 knooppunten 63 moeten zien, elk met exp_… 3.

**“Gewone” fietsrouting **moet hier geen probleem mee ondervinden, want de wegen en de routes zelf veranderen niet, De LF die daar ook loopt kom ik niet aan.

JOSM heeft nu 5 routerelaties. Na de actie heeft hij twee relaties erbij, maar 5 andere bevatten geen extra knopen en overlappende wegen meer.

Ik zal de oude settings bewaren, of de changeset reverten als het ergens verkeerd uitpakt.