Het is in de basis redelijk eenvoudig om aan een rwn relatie een kleur toe te voegen. Dat kan met de colour tag.
Problemen zijn dan meerdere kleuren en dubbele kleur. Hier in Deventer heb je sinds kort een route, die heeft groen-wit als kleur, dus net zo als een lange afstandsroute rood-wit heeft en een streek-pad rood-geel. Verder zijn er routes als de Sallandse Zandloper met ? en het Schipbeekpad en het Reggepad met blauw-wit.
En wat doe je met verbindingsroutes, die grijs hebben maar een lange afstandspad begeleiden?
Kijk maar eens noord van Deventer, http://www.openstreetmap.org/note/1095981#map=17/52.30501/6.20151&layers=N , vanaf het landgoed Kranenkamp loopt vanaf J15 een grijze route samen met het Marskramerpad naar E58, tussen E58 en E59 loopt de rode route, van E59 naar M25 is het weer grijs, na M25 krijg je een gele route.
Ik snap dat er heel veel werk in is gaan zitten. Mijn hele punt is nu juist dat het dubbel invoeren van dingen zo gruwelijk veel tijd kost en dat dat niet nodig is.
Ook dit is precies het punt dat ik wil maken. Met twee parallelle netwerken krijg je ze nooit met elkaar gesynchroniseerd.
Klopt, maar dit zijn wel 4 features. Op elk paaltje zie je dan ook 4 vierkante bordjes. Je ziet dus in werkelijk 4 features, dus kun je die ook als 4 elementen mappen. Een weg kan prima bij meerdere features horen. Over sommige wegen leiden nu eenmaal meerdere fiets, wandel, MTB en ruiterroutes. Dit zijn wel degelijk meerdere features.
Consensus hoort in de wiki thuis. Ik heb nu al verschillende keren gevraagd om daaruit te citeren, maar niemand die mij kan wijzen op specifieke gedeeltes uit de wiki waarom optie 1 niet goed zou zijn.
Jammer dat je niet open staat voor verdere discussie. Gelijk dreigen met reverts en mij aangeven bij de DWG werken niet heel motiverend. Zelf eerst al mijn werk massaal omtaggen en als ik daar dan vraagtekens bij zet, gelijk met reverts en met de DWG gaan dreigen zelfs nog voordat ik iets van jouw werk heb aangepast. De toon die jij soms aanslaat staat mij tegen. Met boos worden en met hoofdletters gaan schreeuwen is niet de manier om met de community te overleggen. Neem een voorbeeld aan multimodaal. Die stelt eerst wat opties voor en geeft de voors- en tegens weer. Wij willen beide eerst consensus voordat we dingen gaan veranderen.
Voor mij is het redelijk makkelijk om dit wat afstandelijker te blijven zien omdat ik in de wandelnetwerken in het oosten nog geen tijd heb geïnvesteerd en het echt een regionale bijzonderheid is. Ik snap dat als je ergens vele uren werk in hebt zitten dat het dan eerder gevoelig ligt, dat heb ik zelf ook (hoewel ik hier veel minder tijd aan besteed).
Tegelijk ligt er een praktische vraag open om te beantwoorden (dat was voor mij de aanleiding, ik wilde wat data invoeren en weet niet hoe ik dat het beste kan doen) en is het ook wel een mooie puzzel, ingegeven door een inrichting van de knooppunten die afwijkt van wat landelijk gebruikelijk is (en die ik stiekem op zich qua concept wel aardig, en de knooppunten waren zelf ooit ook nieuw).
Maar ondertussen is er al enorm veel werk verricht op de klassieke methode en zitten wij met de hoofdbrekers en zijn we aan de ene kant gebaat bij consistentie en wil je het aan de andere kant niet moeilijker maken dan het is (ik moet me er altijd weer toe zetten om verder te gaan met invoeren knooppuntnetwerken…)
Over de quote van de Wiki, ik doelde op deze:
https://wiki.openstreetmap.org/wiki/Fietsroutes#Regionale_Fietsroutes_.2F_Fietsknooppuntennetwerk (laatste aanpassing: 2015)
Maar zoals gezegd vindt ik het zelf zwaarder wegen dat dit niet alleen uit de wiki-tekst blijkt, maar ook volgt uit de context op OSM: het wordt in de praktijk ook zo gedaan (knp-knp), iedereen kan immers snel achter die zin in de wiki toevoegen “of een rondje” (-:
Tegelijkertijd kan hier ook evolutie plaatsvinden, zeker in het licht van nieuwe ontwikkelingen. En daar hink ik zelf op twee gedachten. Eigenlijk vindt ik -als ik me een virtuele situatie voorstel waarin er nog geen netwerken waren ingevoerd- het wel elegant om het netwerk te vullen met rondjes, die komen overeen met wat daar in het veld het meest kenmerkend is en mappen makkelijk. Als het mooi rondgaat zou het al snel goed kunnen zijn in de validatie (evt een variabele opnemen op de knooppunten die je tegen moet komen), aangevuld met verbindingsroutes op de klassieke manier? Maar de praktijksituatie is anders met al wel heel veel ingevoerde klassieke knooppuntroutes (en nog veel werk te doen, zowel in onderhoud als uitbreiding), en daar vind ik dat Dick ook een punt heeft.
Eerder merkten we dat de superrelatie per saldo op de meeste stemmen van jullie kan rekenen. Als ik zelf veel zou mappen in het oosten, dan zou dat niet mijn eigen favoriet zijn (lijkt me lastig), maar dat doe ik niet en zoals gezegd pas ik me in dit geval graag aan.
-
Zal ik een paar proefstukjes met een superrelatie doen op basis van mijn verzamelde data om eens te kijken hoe dat uitpakt (invoeren, validatie, rendering?
Zoiets? (concrete verbetersuggesties zijn welkom) :
(1) klassieke knp-knp relatie:
-
type=route; network=rwn
-
is lid van bestaande relatie type=network ; network=rwn ( https://www.openstreetmap.org/relation/1341166 )
aangevuld met
(2) superrelatie voor klassieke knp-knp relatie:
-
type=route; network=lwn
(een superrelatie hoeft toch niet per se ook een type=superroute te hebben als ik de wiki zie, eerst kijken of de eenvoudige weg werkt?) -
deze is net als (1)- lid van het de relatie rwn *type=network ; network=rwn *, want zij vormen net zo goed als de knp-knp verbindingen het netwerk
Hoe onderscheiden we de vele lussen met dezelfde kleuren in hetzelfde netwerk?
-Misschien met een ref= met daarin de kleur en het laagste knooppuntcode dat (tot dan toe, work in progress is idd van belang bij veldwerk) bent tegengekomen in het netwerk
-Nog een note= (zoals bij klassieke knp-knp) met de nummers van de knooppunten die in de lus zouden moeten zitten, startend bij het knooppunt met de laagste code (of startpunt met naam die het eerst in het alfabet zit?), zodat je kan checken of alle nodes met knooppunten nog in de route zitten (indirect via de relaties-> wegen die lid zijn) ?
Inderdaad, momenteel worden enkel netwerktypes rwn en rcn verwerkt (geen lwn). Relaties die verzamelingen zijn van netwerk relaties worden momenteel expliciet buiten de analyse gehouden.
Laat de keuze over hoe te taggen liefst niet te veel afhangen van hoe de analyse op http://osma.vmarc.be/ vandaag werkt. Ik sta open voor aanpassingen, bijvoorbeeld ondersteuning van rwn lus-relaties (verzameling van rwn route relaties) binnen rwn netwerk relaties, of iets anders waar concensus over bereikt wordt.
Strikt genomen staat hier niet dat die twee netwerkpunten verschillend moeten zijn. Sterker nog voor een rondje waar je slechts 1 knooppuntnummer tegenkomt, moet je het wel als rondje taggen.
Even voor de duidelijkheid. De bedoeling van (2) is toch dat je per rondwandeling één lwn-superrelatie maakt met als leden de rwn-knooppunt-knooppunt relaties? Dan bestaat het onderscheid tussen gelijk gekleurde lussen uit het feit dat het verschillende relaties zijn.
Een proef kan denk ik geen kwaad. Dan krijg je feeling met hoeveel werk het is, hoe het overal rendered, hoe relatie-checkers ermee omgaan en hoe makkelijk/moeilijk het is om met een editor als josm het in te voeren en te valideren. Ik zou het wel in overleg doen met Dick, zodat hij het niet, zoals hij aankondigde, alles direct gaat reverten.
@(V)Marc: Dank voor je reactie, je bereidwilligheid om mee te denken over actualisatie en voor de nu ook al bijzonder handige site!
@overigen:
Heb twee lwn-proeflussen gemaakt obv optie 4 (superrelatie):
eentje waar de volgorde waarin een relatie-lid gelezen moet worden wel met forward/backward expliciet is gemaakt en eentje waar dat niet het geval is
http://www.openstreetmap.org/relation/7769722
http://www.openstreetmap.org/relation/7769965
Heb deze zowel aan het rwn-netwerk als aan een apart lwn-netwerk toegevoegd
Wat direct al opvalt:
**Rendering **
-Op OSM.org wordt de superrelatie niet gevisualiseerd (zie bovenstaande links), terwijl als je op een van de leden klikt (een relatie die zelf weer ways als leden heeft), dat wel gebeurt (bijvoorbeeld http://www.openstreetmap.org/relation/7769719 )
-Waymarkedtrails toont beide lwn-routes wel gewoon:
https://hiking.waymarkedtrails.org/#?map=15!52.5226!6.4738
-Maar ook de aangepaste Hiking-versie van d=het BTM-kaartje (oorspronkelijk van Ligfietser) en mijn ‘eigen’ renderer (gemaakt met veel programmeerhulp, ik ken dus niet de fijnste technische details) krijgen de lwn-superrelatie niet gevisualiseerd (wel de gewone LWN die er al liep):
http://www.openkaart.net/wandel/lvww-overpass/#map=15/52.5198/6.4797&overlays=lwn
http://www.openkaart.net/wandel/hiking-tags/?map=route&zoom=14&lat=52.52588&lon=6.47808&layers=B00000FFFTFFFFFFFF
-Validatie
De bovenstaande twee routes staan op moment van schrijven nog niet in Vmarc,
maar die lijkt in ieder geval niet blij om relaties in een relatie (obv aanzet van aanzet van andere route eerder vanavond - daar had ik daar door combineren niet een hele lus gelopen):
http://osma.vmarc.be/nl/network/1341166
Voor de bovenstaande twee routes zal morgenochtend denk ik ook wel zo’n boodschap verschijnen
-De OSM Relation analyzer lijkt hier vooralsnog ook weinig mee te kunnen
http://ra.osmsurround.org/analyzeRelation?relationId=7769722&_noCache=on
Invoeren
Nu ik ze ga invoeren begin ik die gekleurde lussen door al het overlappen opeens een stuk minder sympathiek te vinden, vooral als je compleet zou willen zijn 
Heb me nu dan ook maar beperkt tot een lus per keer ,maar je komt steeds meer tegen onderweg…
Als je alleen veldwerk hebt en geen kant en klare kaart ernaast als referentie voor het totaalplaatje is het toch wel erg lastig (en veel data verzamelen, meer dan bij knp-knp).
Wat ik vooral lastig vindt is dat je in JOSM in het relatievenster niet ziet of de boel mooi aansluit als je relaties invoert als lid van je relatie, terwijl dat met ways mooi wordt gevisualisserd, waardoor gaten, overlappingen en omdraaiingen gelijk opvallen.
Genoeg voor nu, wellicht kennen jullie andere validators en hebben jullei nog ideeën
Dank voor het uitvoeren van de test. Het heeft de nodige handige informatie opgeleverd.
De punten die je noemt onder rendering en validatie zou je af kunnen doen als “dat is de taak van de renderer / validator en niet van de mapper”. Echter, ken ik vrijwel geen enkele tool die iets met netwerk relaties doet. Je kunt moeilijk verwachten van al die software bouwers dat ze hun tools en renderers maar moeten ombouwen, omdat wij als mappers een ingewikkeld systeem hebben bedacht van wegen en knooppunten in relaties ((1) knp-knp) in relaties ((2) lwn lus) in relaties ((3) lwn superrelatie), waarbij (1) dan ook nog eens zit in een andere relatie ((4) rwn superrelatie). Zo’n systeem is voor de doorgewinterde mapper zoals wij nog wel te bevatten, maar voor de gemiddelde mapper gaat dat vrees ik boven z’n pet. Het kan gewoon op teveel manieren onbedoeld stukraken.
Ik vind daarom je bevindingen onder je kopje “invoeren” ook de belangrijkste bezwaren tegen optie 4. Als je bij het invoeren al niet kan zien of je alles correct hebt ingevuld, dan gaan er al bij het invoeren dingen fout, vooral omdat je aan veel dingen moeten denken omdat het zo ingewikkeld in elkaar steekt.
Overigens ben ik nog wat andere bezwaren tegen het knp-knp-systeem tegengekomen:
- begin stukjes die beginnen vanaf een punt zonder knooppuntnummer naar de rondwandeling kunnen niet gemapt worden (immers het loopt niet van knooppunt naar knooppunt), terwijl ze in het veld wel met bordjes zijn gemarkeerd. Zie bijvoorbeeld het paarse beginstukje: https://hiking.waymarkedtrails.org/#?map=17!52.1854!6.8906
- rondjes met slechts 1 of 2 knooppunten kunnen niet gemapt worden. Voorbeeld, hoe zou je de gele route (https://hiking.waymarkedtrails.org/#route?id=2571522) moeten taggen met enkel knp-knp stukjes? Je ziet hier dat de onderste X11-X14 wel gemapped is maar het bovenste X11-X14 niet. Twee maal een relatie X11-X14 opnemen lijkt me erg verwarrend. Als je slechts 1 knooppuntnummer in een lus hebt zitten, ben je helemaal de sjaak.
- splitsingen gebeuren soms ook zonder dat op dat punt een knooppuntnummer staat. Dit is met mappen van enkel knp-knp-relaties niet te mappen (zonder overlap). Kijk bijvoorbeeld naar de rode en groene routes die tussen Y78 en Y79 lopen (https://hiking.waymarkedtrails.org/#?map=15!52.1428!6.7281)
Elk startpunt heeft een knooppunt. Dus piefjes kunnen ook getekend worden.
In het voorbeeld gaat het om het startpunt Smalenbroek met knooppunt Z87 volgens de nieuwste kaart.
Buiten moet nog gekeken of dat klopt. De nieuwste kaarten blijken niet bepaald foutloos
Tussen 2 knooppunten kunnen meerdere relaties lopen, dat komt vaker voor ook in het rcn. Voorbeeld: In Zeeland heb je routes binnendiijks en buitendijks.
Ik heb gisteren nog “dubbele” routes ingetekend, gaat prima.
Je ziet buiten aan de bordjes of de paaltjes wel hoe je moet lopen.
Je zit zelf in de IT, dus weet je dat onder water met ID’s wordt gewerkt. Die relaties hebben een verschillend ID. Dus de software kan er prima mee omgaan.
De naam van de relatie staat in een note tag. En note tags worden niet gerenderd. Dat is heel slim bedacht toen men met het rcn begon. Dan zie je op de kaart geen relatienamen verschijnen. Dus ook daar geen verwarring.
Een rondje vanuit 1 knooppunt naar hetzelfde knooppunt is een probleem, dat klopt. Dat moet je oplossen met een virtueel knooppunt. Niet de fraaiste oplossing maar het kan wel.
Overlappen zijn geen probleem of fout van het knooppuntensysteem.
Dat is pure baggerconfiguratie. Als de netwerkbeheerder verzuimt op die plekken een keuzepunt te leggen, is dat zijn fout. Niet van het knooppuntensysteem.
Als je de gekleurde routes gaat gebruiken als netwerkrelatie, heb je hier net zo goed een probleem mee. Ook dan mis je het keuzepunt.
Bij de manier van invoeren van het knooppuntensysteem in OSM, hebben we er overigens geen last van. Je legt gewoon twee relaties over elkaar heen.
In het rcn hebben we daar ook last van. Met name in Zuid Limburg waar vaak 2 knooppuntrelaties kilometers gelijk op gaan om dan ergens te splitsen zonder een knooppunt. Het ergste geval is ergens tegen de Belgische grens aan waar 5 knooppuntroutes over elkaar heen liggen.
Van overlappen hebben we ook last als 2 netwerken over elkaar heen liggen.
Achterhoek en Salland overlappen elkaar en hebben ieder hun eigen keuzepunten. Ja, ook dat is een kwestie van niet afstemmen tussen de beheerders. En wat buiten krom is, kun je binnen niet meer rechtbuigen.
Dus in dit geval worden de keuzepunten aan zowel Salland en de Achterhoek toe gekend.
Het knooppuntensysteem is geen vervanging van de gekleurde routes. Het is er complementair aan. Het geeft de basisrelaties aan tussen de knooppunten. Niet meer en niet minder. In feite de atomaire deeltjes van het systeem. En vanuit die deeltjes kun je zaken opbouwen, zoals routes. En je kunt er ook prima GPS tracks mee maken.
Als je een wandeling plant via overstappen van de ene gekleurde route op een andere, dan kom je met het probleem te zitten, dat je bijv. via Waymarked trails alleen een complete GPS track kunt krijgen van de hele route. Vervolgens kun je dan met bijv Basecamp of Mapsource die tracks in stukjes gaan knippen en dan weer stukjes aan elkaar gaan plakken.
De stap van het knippen kun je je besparen door GPS tracks van de onderliggende knooppuntrelaties te maken en die aan elkaar te verbinden. Dat zou een planner applicatie ook kunnen doen, maar helaas is zo’n planner - voor zover ik weet - nog niet.
Er is wel een planner van Waypoint, die werkt met tracks van knooppunt naar knooppunt, net zoals in OSM de knooppuntrelaties, maar volgens mij ligt het werk daaraan stil.
Ik heb zelf zo’n ruime 30 jaar ervaring in IT, voornamelijk als developer en 2e lijns ondersteuner.
Ik heb vaker zitten denken hoe om te gaan met die gekleurde routes.
Als ik een planner op basis van die routes zou moeten maken, dan zou ik als eerste de routes opdelen in hun samenstellende delen, de stukken tussen de keuzepunten.
Als ik daarover nog wat langer nadenk, wordt ik al gillend gek.
Immers er is geen enkel verband vast gelegd tussen de route en de keuzepunten waar hij langs loopt. De keuzepunten zijn niet in de route vast gelegd, dus route en keuzepunten kunnen compleet out of sync raken. Ook kunnen de wegen wel doorlopen over de keuzepunten heen. Allemaal punten, die het lastig maken om de route als knooppuntroute te gebruiken. En er zal vast nog wel veel meer zijn.
Daarom is het - volgens mij - handiger om de relaties tussen de knooppunten apart vast te leggen. Dan heb je nog wel de problemen, die jij schetst, maar die heb je bij de gekleurde routes ook. Ook als je die chopt in de kleine stukjes, krijg je het probleem, ga ik linksom of rechtsom als de route rondloopt tussen 2 keuzepunten.
Het grote punt is en blijft, dat men verzuimt heeft bij de keuzepunten een verwijzing naar het volgende keuzepunt op te nemen. Een groot manco naar mijn idee en ik begrijp ook niet waarom de bedenker daarvoor gekozen heeft.
Ik vind het uitermatig prettig om met de losse relaties te werken. Dan heb je geen grote moppen zoals een hele route.
En je kunt het stukje bij beetje doen. Je kunt ook kleine gebiedjes doen.
En mijn idee is nog steeds om gekleurde routes te maken vanuit de netwerkrelaties. Het mooist is een superrelaties, maar als dat niet lukt, kan de gewone methode ook nog. Je pakt een netwerkrelatie, zet het blok wegen erbuiten, en hangt die in de routerelatie van de gekleurde route. Eventueel nog omkeren. Klaar. Volgende netwerkrelatie. Groot voordeel tov rcn is, is dat je geen forward/backward hebt.
Zo doe ik het bij rcn ook als er fkp omgelegd en LF routes omgelegd moeten worden. En zo moeten er ook nog fietsroutes worden gemaakt die het rcn volgen.
Helaas komen de genoemde situaties ook in de knooppunt netwerken voor.
-
begin stukjes die beginnen vanaf een punt zonder knooppuntnummer naar de rondwandeling.
Dit komt voor vanaf bv. een station of camping.
De validaties is een probleem, maar het is zoals de werkelijkheid is.
Soms zie je dat later nog een knoopppunt paaltje toegevoegd wordt. -
rondjes met slechts 1 of 2 knooppunten kunnen niet gemapt worden.
Dit komt af en toe voor. Een rondje om een vijver terug naar het beginpunt.
Of beide richtingen om de vijver zijn gemarkeerd. Dit levert dan 2 relaties op met hetzelfde begin en eind punt. -
splitsingen gebeuren soms ook zonder dat op dat punt een knooppuntnummer staat. Dit is met mappen van enkel knp-knp-relaties niet te mappen (zonder overlap).
Dit komt regelmatig voor. Soms wordt het later verbeterd met een nieuw knooppunt paaltje.
Hier gebruik ik de overlap om het beter controleerbaar te houden.
Bij online routeplanners zie ik een extra knooppunt zonder nummer (wat handiger is voor het invoeren en onderhoud).
Liever zou ik ook naar een virtueel knooopppunt overgaan, maar dan moet hier wel consensus over bestaan.
Zie https://forum.openstreetmap.org/viewtopic.php?pid=675138#p675138 voor iets dat misschien van pas kan komen 
(nadere reactie volgt later)
Ik heb een pad bij de watermolen van haaksbergen geedit, kan iemand die van wandelnetwerken weet kijken of ik niks gebroken heb?
https://www.openstreetmap.org/way/373900429
Op het pad zelf liggen geen routes en op de Watermolenweg is alles in orde
Bedankt voor de controle. Het pad was dubbel en de aansluiting met de weg was fout, dus hele pad maar verwijderd.
Deze is wel goed
https://www.openstreetmap.org/way/142177344
Voor zover ik weet worden in Vlaanderen de lussen en de netwerken gescheiden gehouden.
Voor de lussen gebruiken we lwn, voor de netwerken rwn.
In de lussen stoppen we net zoals voor de netwerken de wegen en de paden. Aangezien een lus los van een netwerk kan evolueren, lijkt het mij logischer om geen routes van de ene in de andere te plaatsen.
Nu is het wel zo dat in Vlaanderen er nog hele gebieden zijn waar geen netwerk is vastgelegd, en er enkel lussen zijn.
Routes zien er allemaal goed uit.
Kan iemand met verstand van wandelnetwerken naar deze knoop kijken?
https://www.openstreetmap.org/node/5290445918
Ik heb een brug over het water gemaakt maar de gele route gaat nu heen en weer over de brug.
https://www.openstreetmap.org/relation/3899283#map=15/52.1337/6.7263
Kan iemand knoop 5290445918 aan de noordkant van de brug leggen met behoud van de relaties?
Een en ander is hersteld.
Het was een verwarrende boel waarbij een pad, een pad op een brug en een track op elkaar lagen. Alles was verder verknoopt met landuses en de brug ook nog met het water.
Paden en wegen mogen niet met landuses verknoopt worden. Bruggen mogen niet met het onderliggende water verknoopt worden.
Ik heb nu het pad en de track weg gehaald, het pad op de brug laten liggen en alle relaties en dat was een hele bundel, hersteld.
Mijn dringend advies wees voorzichtig met het inleggen, je kunt snel zaken aan elkaar verknopen en ook snel wegen tegen zichzelf in op elkaar plakken, wat hier ook gebeurt was. Doe telkens kleine stukjes en check of alles nog klopt.
En als eenmaal de boel als een klont aan elkaar zit, is het uitermate lastig om de zaak te herstellen.
Hartelijk dank! Ik werk met ID en die snapt heel gemakkelijk aan landuse polygonen.
Ik heb deze hele diskussie gelezen. Had ik al eerder gedaan, maar toen snapte ik driekwart van de punten niet. Nu wel, heb inmiddels veel ervaring opgedaan en ik snap zelfs de situatie in de Achterhoek…
Maar ik mis nog een konsensus die je in een wiki kan vastleggen. Omdat ik nu min of meer de wandelwiki doe en daarin de tag-afspraken voor NL staan, zou ik het wel fijn vinden als we een tekst kunnen maken waar iedereen zich in kan vinden.
Om een voorzet te doen over een paar bediskusieerde punten:
Tekstvoorstel wandelwiki
Themaroutes met blijvende eigen beschrijving en beheer, maar geen eigen markering op de weg:
Niet in OSM, behalve als ze als permanente knooppuntroute beschreven zijn.
Permanente knooppuntgebaseerde routes: Netwerk kan lwm, nwn, of zelfs iwn zijn, maar niet rwn dat is gereserveerd voor knooppunttrajekten en knooppuntnetwerken. Er moet vast beheer zijn en een website of geldend boekje waarin de knooppuntenreeks beschreven staat, en liefst hier en daar een infopaneel op de weg bij een opstappunt (trailhead, TOP, toegangspoort).
NB Het komt veel voor dat er toch delen zijn die niet of niet eenduidig via knooppunten lopen. Aanlooproutes, lusjes, er bestaan meerdere routes tussen twee knooppunten. In dat geval maak je van de extra delen aparte routerelaties, waarvan het netwerktype overeenkomt met de route waar ze onderdeel van zijn.
Tot netwerk verknoopte langere routes: Worden beschouwd als knooppuntgebaseerde routes, ook als ze op de weg hun eigen markeringen gebruiken ipv een aparte knooppuntnetwerkmarkering.
Dus de langere routes zijn lwn (bv rondwandelingen, dagwandelingen) opgebouwd uit een serie knooppuntrelaties (die zelf rwn zijn). De markering van de langere route tag je op de routerelatie.
NB Het is niet aanbevolen om een superroutenetwerk te maken van lokale routes die op zich al uit knooppunttrajekten opgebouwd zijn. Alle kruispunten en gezamenlijke routedelen zijn immers al opgenomen in het knooppuntennetwerk. Als je een route wil maken samengesteld uit verschillende delen van verschillende langere wandelingen, dan plan je die via de knooppunten. Een gpx van zo’n geplande mengroute zou door een knooppuntenplanner moeten worden geproduceerd, zoals dat geldt voor alle knooppuntenroutes. Bijvoorbeeld http://www.wandelen123.nl/ biedt deze mogelijkheid.