Talk:Cycle Node Network Tagging

knooppuntennetwerken (Dutch)

Aangezien de netwerken hoofdzakelijk in Vlaanderen en Nederland liggen, ga ik de discussie in het Nederlands aankaarten.

Ik ben alle knooppuntennetwerken aan het nakijken. Daarbij zou het handig zijn, als we het erover eens zouden zijn om dat allemaal op de dezelfde wijze te doen.

Het lijkt me ook belangrijk om het in de bredere context van alle knooppuntennetwerken te zien. Dus ook die voor wandelaars en ruiters.

Splitsen van knooppunten

Op zich lijken knooppuntennetwerken vrij simpel. En als er 3 routes in 1 punt samenkomen is dat ook zo. Als 1 of meerdere van deze 3 routes starten over gescheiden fietspaden - dus als een vork- of als er 4 routes zijn die niet op dezelfde OSM-node bij elkaar komen, dan wordt het nodig om deze knooppunten te splitsen.

De routes eindigen dan met het gedeelte tussen deze gesplitste punten, met de nodige rollen erop zodat fietsers van de ene node naar de andere worden geleid, voordat de eigenlijke route begint.

Als de route eindigt in een vork, dan eindigt ze van zodra de eerste node met daarop een rcn_ref bereikt wordt. Van daaraf worden de fietsers dan verder geleid naar de andere gesplitste knooppunten in de andere knooppuntenrouterelaties.

Het staat uitvoerig geïllustreerd op deze pagina.

Nu zijn er mappers die zeggen: waar de kaart staat met daarop het nummer, dat is waar het knooppunt ligt en iedereen moet daar maar langsrijden, ook al moeten ze dezelfde weg dan 2x afleggen. De discussie daarover werd vorig jaar al gevoerd en ik dacht dat deze achter ons lag, maar blijkbaar is dat niet zo. Dus gelieve daarover hier uw mening te geven.

Omdat ik mij voornamelijk met wandelennetwerken bezig houd, heb ik het splitsen van knooppunten niet helemaal gevolgd. Voor wandelnetwerken heb je niets met de richting van de weg te maken en zou mijn voorstel zijn om elk knooppunt als een rwn_ref te plaatsen op de plek waar het plaatje staat (splitsing/kruising). Sommige netwerken splitsen een knooppunt door 2x een knooppunt paaltje te zetten. Dan heb ik er ook steeds 2x (of zelfs meer) rwn_ref gezet op elke splitsing. Andere netwerken zetten maar 1x een knooppunt paaltje en op het tweede staat geen nummer. Dan leid ik steeds elke route naar het knooppuntje paaltje toe. Het zijn vaak maar een tiental meters extra. Als je het echt gaat lopen kun je dan alsnog de afkorting nemen. JanWandelaar 19:17, 25 September 2012 (BST)

Allereerst; ik ben alleen bekend met de fiets knooppuntnetwerken van de Stadsregio Arnhem/Nijmegen (SRAN) en Achterhoek. Op zich ben ik het er helemaal mee eens dat knooppunten gesplitst moeten worden. De borden met de verwijziging naar het volgende knooppunt suggereren ook dat dit zo is. Maar een uitzondering is het gedeelte van SRAN dat zich in Duitsland bevind. De bebording is daar op een dusdanige wijze gedaan, dat het niet meer klopt als je knooppunten gaat splitsen. Als je in Kleve van knooppunt 26 naar 5 fietst, zie je pas bij het knooppunt bord van 5 dat je moet omkeren als je daarna naar knooppunt 4 wilt. Vanaf knooppunt 3 bij Emmerich kun je naar 88 (richting noorden) en 2 (richting westen). Maar er is ook een route aangegeven van [[::File:Emmerich_knotenpunkt_88.JPG|knooppunt 88]] naar 2, als je knooppunt 3 zou splitsen, zou de route 88-2 via knooppunt 3 gaan. Dan is die route dus overbodig, want 88-3 en 3-2 is ook aangegeven. Ik ben het er overigens zonder meer mee eens dat deze manier onlogisch is, maar mij is altijd verteld dat ik moet mappen wat ik op straat zie. En dus niet iets moet weglaten of erbij verzinnen omdat het logischer is. Overigens is het gedeelte van het netwerk achterhoek dat zich in Duitsland bevind, op de Nederlandse manier aangegeven. Daar speelt dat probleem zich dus niet. --Wimmel 18:04, 29 September 2012 (BST)

UPDATE: De afgelopen twee dagen ben ik het Duitse routenetwerk langsgefietst. Ik moet nu toch mijn mening herzien. Op de "tentakel" kruispunten blijkt wel degelijk overal aangegeven hoe je direct naar het volgende knooppunt kunt, alleen je moet wel even stoppen op het kruispunt om de borden goed te kunnen bekijken. Er staat in Duitsland in dat soort gevallen geen borden voordat je het kruispunt bereikt. Blijft wel een feit dat sommige routes dan opeens via een ander knooppunt gaan, terwijl die dus in werkelijkheid niet via dat knooppunt gaan, het knooppunt was immers een kruispunt verderop. Voorbeeld: 1066151. Tevens ben ik erachter gekomen dat een soortgelijke situatie zich ook op het Nederlandse deel voordoet, ten zuiden van Groesbeek. Dat wordt op de plattegrond weergegeven als een knooppunt zonder nummer. Zodra ik eea heb geupdate, kan ik nog voor enkele voorbeelden zorgen. --Wimmel 19:08, 11 October 2012 (BST)

Route terug naar vorige knooppunt

Volgens de huidige beschrijving worden bij een gesplitst knooppunt er wel routes toegevoegd vanaf de andere knooppunt nodes, maar niet (persé) vanaf de node waarop je het knooppunt bereikt vanaf diezelfde route. Het gevolg is, dat je in die gevallen niet terug kunt naar het knooppunt waar je vandaan kwam. Zie deze twee voorbeelden: File:JOSM26-27Draw.png en File:JOSM26-30.png; Als je vanaf respectievelijk knooppunt 27 en 30 op knooppunt 26 uitkomt, kun je niet gebruik makend van dezefde route relatie teruggaan. Nu zal dat meestal ook niet nodig zijn, maar ik kan me voorstellen dat als er iets bijzonders langs die route is, je dat toch zou willen. Hoe denken jullie daar over, is het nodig daar rekening mee te houden? --Wimmel 19:45, 13 October 2012 (BST)

Ik ben er steeds vanuit gegaan dat het niet nodig is om de gebruikers van het netwerk op weg te zetten naar waar ze vandaan kwamen. Zijn er routeplanners die een sequentie nummers geven om van het ene punt naar het andere te gaan en daarbij 2 keer nagenoeg dezelfde weg laten afleggen? Ga naar KP 64 en keer daar op je passen terug, want je hebt iets bezienswaardig gemist net op dat stukje weg waar de route gesplitst was. We weten wel dat je van punt A naar punt B wilde, maar dit willen we je echt niet onthouden... Wat mij betreft, lijkt dat me dus niet nodig.

Polyglot 22:11, 13 October 2012 (BST)

Opnemen van de knooppunten in de routerelaties

Volgens mij is dit niet nodig, aangezien ze deel uitmaken van de ways. Ik zou het datamodel zo licht mogelijk willen houden. Sommigen schijnen daar echter op te steunen. Al begrijp ik niet goed waarom. Indien nodig wil ik iedereen wegwijs maken in het gebruik van MAPCSS in JOSM. Dat zorgt ervoor dat de knooppuntnummers 'oplichten'. (Zoals te zien is in de screenshots op deze pagina.

Dit kan een kwestie van smaak genoemd worden en ik zou er kunnen omheen werken. Als het echter de bedoeling is dat ze erin zitten, moet ik mijn script aanpassen zodat nagekeken wordt of alle (gesplitste) knooppunten wel aanwezig zijn en dat zou ik willen vermijden. Vandaar dat ik liever zou zien dat de knooppunten enkel in de networkrelaties worden opgenomen.

Dat dit kan werken, wordt bewezen door het feit dat in België en grote delen van Nederland niemand deze knooppunten aan de routerelaties meer toevoegt.

Anderzijds merk ik dat ze nu ook in wandelknooppuntenroutes worden toegevoegd in sommige Nederlandse wandelknooppuntennetwerken.

Lang geleden moest het niet, daarna moest het wel. Inmiddels is het voor veel mappers de gewoonte om het wel te doen. Sommige omdat ze dat zo geleerd hebben. Anderen die dat nu eenmaal handig vinden tijdens het bewerken van de kaart. Nu hebben een maand of twee gelden drie mensen op de mailinglijst besloten dat het niet meer moet en gaan ze klagen dat niet iedereen daar hetzelfde over denkt. Laat staan dat iedereen al weet dat het tegenwoordig weer anders moet. Zucht --Cartinus 18:43, 25 September 2012 (BST)

Zelf voeg ik de knooppunten toe omdat het mij ooit verteld was. Je had dan ook een duidelijk gedefinieerd punt waar de route begint en eindigt. Ways kunnen aangepast worden, maar de punt blijft meestal liggen. Als er consensus is dat het niet hoeft pas ik mij aan. Voor mijn gevoel zijn de relaties met maar 1 way erg kwetsbaar zo. Er hoeft maar iemand de relatie te verwijderen van de way en daarna heeft de relatie geen members. En een bot of controletool komt langs en verwijderd dan de lege relatie. Geen flauw idee hoe groot de kans hierop is. JanWandelaar 19:15, 25 September 2012 (BST)

Mijn ervaring is dat het punt nogal eens verplaatst moet worden. Bijvoorbeeld als het eerst op het kruispunt van autowegen lag en nadat de fietspaden werden toegevoegd er een verschuiving naar het kruispunt van de fietspaden en de zijwegen nodig is.

Dit speelt inderdaad minder bij wandelroutes. Verder komt het niet vaak voor dat iemand een relatie verwijdert bij een weg. Wat wel voorkomt is dat wegen worden samengevoegd, zonder rekening te houden met relaties, waardoor de route uitschieters krijgt. Of dat wegen worden vervangen, al is dat normaal gesproken niet de bedoeling.

Het script dat ik maakte vindt al dit soort problemen en rapporteert ze. Het rapporteert ook als er bij knooppunten minder dan 3 routes aanwezig zijn. Polyglot 11:46, 26 September 2012 (BST)

Ik ben het eens met Cartinus en JanWandelaar, ik doe dat omdat ik het zo geleerd heb, en ik kijk niet steeds op de wiki of er wijzigingen zijn. Het is soms handig dat je in josm op een node kunt klikken en dan meteen ziet welke routes er naar die node gaan, maar dat is ook op een andere manier op te lossen. Ik heb dus geen bezwaar om de knooppunten niet meer in de routes op te nemen. --Wimmel 18:08, 29 September 2012 (BST)

Zoals anderen hier neem ik de knooppunten op in de routerelaties en niet alleen in de netwerkrelatie. Dat was de regel voordat de wiki weer aangepast werd. En ondertussen maak ik daar dankbaar gebruik van als ik aan de relaties werk. Dus a.u.b. niet gaan slopen uit de relaties. Ga er niet van uit dat iedereen JOSM gebruikt (ik heb zelf de meeste relaties op de Betuwe met Potlatch 1.4 gemaakt). Frankl2009 06:01, 30 September 2012 (BST)

M.a.w. maak het niet onmogelijk voor mensen die met Potlatch of andere editors willen werken. Frankl2009 13:22, 1 October 2012 (BST)

Sorteren van ways in de routerelaties

Ik zou ook willen voorstellen om de ways in de routerelaties gesorteerd te houden en wel zo dat ze vertrekken van het laaggenummerde KP naar het hooggenummerde knooppunt (Tegen dat ik er klaar mee ben, zijn ze toch zo). Dit maakt het geautomatiseerd checken van de continuïteit veel eenvoudiger. JOSM biedt de mogelijkheid om dit automatisch te doen en dat verbazingwekkend heel goed, als de rollen correct toegewezen zijn en als de route niet te complex geworden is (Het loopt fout bij routes die starten of eindigen in een vork). In veel gevallen is het in JOSM dan ook mogelijk om op het zicht te zien dat de routes correct en continu zijn.

Ik denk niet dat er mensen zijn die de volgorde expres door de war gooien. Maar als iemand, die helemaal niet geïntereseerd is in fietsroutes, een weg splitst, omdat hij bijv. maximumsnelheden aan het taggen is, dan is er geen enkele garantie dat de editor de "juiste" volgorde voor de members handhaaft. Relaties zijn in de huidige api versie per definitie ongeordend. Het is slechts aanbevolen de volgorde te handhaven. --Cartinus 18:54, 25 September 2012 (BST)

Naamgeving

Op de informatieborden staat de naam van het netwerk. Zelfs in [[::File:Emmerich_knotenpunkt_3_info.JPG|Duitsland]] staat daar de naam in het Nederlands op. Zou de naam van het netwerk dan ook niet exact zo moeten heten? Nu heet het netwerk "Fietsroutenetwerk NL Stadsregio Arnhem Nijmegen". Of moet er een aparte netwerk relatie komen voor het gedeelte in Duitsland? --Wimmel 18:19, 29 September 2012 (BST)

Al zou er een aparte netwerkrelatie komen voor het Duitse gedeelte (en waarom eigenlijk?) dan nog zou het m.i. moeten heten zoals op de informatiepanelen (en alle andere stukken). D.w.z. zonder extra toevoeging “NL”. Frankl2009 13:19, 1 October 2012 (BST)

Ik heb nu nieuwe borden gezien in Duitsland waarop "Fietsroutenetwerk" wel degelijk vertaald is. Dan maar name:de en name:nl toevoegen op de netwerkrelatie? --Wimmel 19:13, 11 October 2012 (BST)

---

De knooppunten in de SRAN en Achterhoek hebben vaak een naam. Daarom voeg ik name= toe aan de nodes die een rcn_ref hebben. Ik zie dat die naam ook soms weer wordt verwijderd. Misschien omdat die zo prominent in JOSM gerenderd wordt? (Hetgeen ik dus juist weer handig vind.) Daarom de vraag, hoe gaan we om met die naam. Gebruiken we een nieuwe tag bijv. rcn_ref_name? --Wimmel 18:19, 29 September 2012 (BST)

In SRAN hebben de knooppunten ALTIJD een naam (te vinden op het informatiepaneel met een korte beschrijving van wat er te zien is in de omgeving). Het lijkt me juist om hiervoor name= te gebruiken, zoals tot nu toe gebruikelijk. Het is immers gewoon de naam die hoort bij dat rcn_ref. Een name= op een node met rcn_ref wordt in Mapnik niet getoond (het “vervuilt” het kaartbeeld dus niet). Ik zie geen voordeel in een aparte key zoals rcn_ref_name=.

Frankl2009 05:53, 30 September 2012 (BST)

Op sommige knooppunten ontbrak het onderbord van het informatiepaneel toen ik er langs kwam. Juist op dat onderbord staat de naam en enkele wetenswaardigheden over dat knooppunt. Maar ik weet niet of dat vandalisme was, of dat het nog nageleverd moest worden. --Wimmel 08:49, 30 September 2012 (BST)

Ja, ik ben ook hier en daar een paar tegengekomen waar er alleen het geraamte is zonder onderbord (of zelfs kaart). En hier dichtbij op de Linge een die helemaal ontbreekt. Wie zal zeggen waarom dat zo is. Ik heb echter ondertussen zo veel bekeken dat ik er zeker van ben dat er altijd een “eigen” naam gegeven wordt in SRAN. Ik ben tot nu toe ook maar een keer hetzelfde naam tegengekomen (en ik vermoed dat het een fout is geweest).Frankl2009 13:19, 1 October 2012 (BST)

Verbeteren van de tagging

De manier waarop het knooppunten netwerk wordt getagd introduceert een groot probleem voor mensen die niet zo in nummerfietsen geinteresseerd zijn. Het is onmogelijk normale regionale fietsroutes op te halen zonder allerlei fragmenten van de knooppunten op te halen omdat er geen onderschijdende tag is. In de uitleg wordt al even aan de Duitse routes gerefereerd met de opmerking 'dat die niet weg gaan'. Gelukkig niet zou ik zo zeggen. Nu zou het strikt genomen niet zo'n probleem zijn als je op de 'ref' tag kon filteren. Immers, regionale fietsroutes hebben een 'ref' tag, bijvoorbeeld AML, DOL of DEK etc. Maar veel relaties van knooppuntroutes hebben ook een willekeurig ingevulde 'ref' tag ( waar eigenlijk beter de 'note' tag had moeten worden gebruikt ), ondanks dat die tag niet in de wiki wordt aanbevolen. Waarom is er niet gekozen voor een duidelijke onderscheidende tagging door bijvoorbeeld af te spreken de knooppuntrelaties een ref/note=knpt oid mee te geven zodat je bij het ophalen van netwerken uit de database onderscheid kunt maken tussen knooppunten en normale fietsroutes?--Noordfiets 10:28, 16 December 2012 (UTC)

Hallo Noordfiets,

Ik kan met de Overpass API alle routes ophalen die deel uitmaken van knooppuntennetwerken, dus het omgekeerde moet ook kunnen met de huidige manier van taggen. Kan je laten weten in welke routes je geïnteresseerd bent? lwn, nwn, of iwn? En in welke regio. Dan bezorg ik jou een query waarmee je (enkel) die kan ophalen.

Waar ik ook voor kan zorgen is een mapcss-bestandje dat ervoor zorgt dat enkel de routes van een bepaald niveau 'eruit gelicht worden' in JOSM.

Polyglot 12:48, 16 December 2012 (UTC)

Zoals Noordfiets schrijft is hij geïnteresseerd in alle rcn's die geen knooppuntroute zijn, dus ik denk niet dat de aanpak die jij hierboven beschrijft gaat werken. Zie bijvoorbeeld de UCTS die hier de Duits-Nederlandse grens oversteekt: [1] --Cartinus 18:58, 16 December 2012 (UTC)

Ik vermoed dat je rcn bedoelde? Het zou kunnen dat ik de vraag inderdaad verkeerd begrepen heb, maar dat is waarom ik om een specifieker voorbeeld vroeg. Om die ucts-route op te halen geef je de volgende query in op http://overpass-api.de/query_form.html:

<union>
   <query type="relation" into="routes">
     <has-kv k="type" v="route"/>
     <has-kv k="network" v="rcn"/>
     <has-kv k="ref" regv="UCT"/>
   </query>
   <recurse type="relation-way" from="routes"/>
   <recurse type="way-node"/>
</union>
<print mode="meta"/>

Aangezien ik een regular expression gebruikt heb, zijn er nog 2 andere routes opgehaald waarvan de ref ook met UCT begint.

De manier waarop ik het onderscheid maak tussen rcn-routes die wel of niet tot het knooppuntennetwerk behoren is precies omdat die van het knooppuntennetwerk geen ref-tags hebben. Totnogtoe volstond dit. Als dat niet zo is, kunnen we eventueel nog wel een tag toevoegen, maar enkel als het echt niet anders kan, aangezien er enorm veel van die routes zijn die deel uitmaken van knooppuntennetwerken en er komen er voortdurend bij.

Om alle routes op te halen in een bepaald gebied met network=rcn en een ref:

<union>
   <query type="relation" into="routes">
     <bbox-query s="49.64" n="53.51" w="2.46" e="7.54"/>
     <has-kv k="type" v="route"/>
     <has-kv k="network" v="rcn"/>
     <has-kv k="ref"/>
   </query>
   <recurse type="relation-way" from="routes"/>
   <recurse type="way-node"/>
</union>
<print mode="meta"/>

Dat levert echter 80MB aan data op, dus is het waarschijnlijk beter om dat voor een wat kleiner gebied te doen...

Op zich zou ik er wel voor openstaan om ipv rcn, rwn en rhn bijv. kcn, kwn en khn te gaan gebruiken, als extra niveau. (n van node is al gebruikt voor national, dus waarom niet k van knooppunt/Knoten?). Dan moeten we enkel de renderers ervan overtuigen dat we dat gaan doen... Eerlijk gezegd zou ik dat veel zuiverder vinden. Polyglot 23:14, 16 December 2012 (UTC)

Hallo Polyglot

"omdat die van het knooppuntennetwerk geen ref-tags hebben" .. Helaas wel dus. Dat was ook mijn uitgangspunt maar blijkt in de praktijk dus niet te kloppen.

 <relation id="8410">
   <tag k="addr:country" v="NL"/>
   <tag k="addr:province" v="Noord-Holland"/>
   <tag k="name" v="Amstelland - Meerlanden"/>
   <tag k="network" v="rcn"/>
   <tag k="ref" v="AmstMrl"/>
   <tag k="type" v="network"/>
 </relation>

Zo zijn alle sub-netwerken die onderdeel van de hoofdrelatie knooppunten zijn. De overeenkomst is dat ze allemaal een addr tag hebben, en dat je ze zelf ingevoerd hebt. Die addr kun je op filteren maar dat is niet echt een bestendig iets, want ook andere routes kunnen die tags vrij gebruiken ( en zouden dat ook moeten doen ). De ref tag is steeds een afkorting van de name tag. Het invoeren van kcn lijkt me te ver te gaan, het zou wel mooi zijn maar zoveel landen met knooppunten zijn er niet. Mijn idee is die ref in een note veranderen of nog liever een extra note 'kcn' toevoegen. Dan kun je toch onderscheid maken tussen knooppunten en klassieke routes. Een extra note 'kcn' op de relatie levert ook geen problemen met renderers en al bestaand gebruik van de knooppunten.--Noordfiets 08:17, 17 December 2012 (UTC)

Dat voorbeeld heeft inderdaad een ref-tag, maar het gaat daar om de networkrelatie (type=network). Als ik het goed begrepen heb, had jij het in eerste instantie om routerelaties (type=route) die geen deel uitmaken van het knooppuntennetwerk.

Als het je inderdaad om de networkrelaties gaat, dan kunnen we daar nog wel een tag aan toevoegen om ze te onderscheiden. network_type=node_network o.i.d. Al wordt network_type op dit moment blijkbaar eerder voor GSM-netwerken gebruikt.

Anderzijds zijn die ref-tags iets dat ik heb 'verzonnen', met de bedoeling om die weer te geven als deel van de naam in JOSM. Als we daar iets anders voor moeten gebruiken, dan kan dat ook. abbreviation o.i.d. zou ook passen. Het zorgt er enerzijds voor dat alle routerelaties van hetzelfde netwerk bij elkaar gesorteerd worden in de relatielijst. Anderzijds helpt het me om snel te zien dat zo'n route een connectie is tussen twee netwerken en dus een role=connection nodig heeft. Polyglot 08:58, 17 December 2012 (UTC)

Using a node_network for other activities

I think this is an excellent way to portray routes and their route-finding aids. I'm wondering if it could be used for nordic ski routes, as well. They're fairly common in my area with numeric signs that mark important intersections. I'm finding that `rcn_ref` is overly specific since they may not be "regional cycling network" specific, and there isn't a similar convention for "Piste maps".

Using ref instead of note

I counted relations with 'type=route' and 'network:type=node_network':

95% use ref, only 5% use note. That's why i changed the wiki in this point.

26.844 relations with 'ref' like 'ref=01-02' (95%)

26.420 without 'note'

166 with 'note' not like 'note=01-02'

258 with 'ref' and 'note' like 'ref/note=01-02'

1.369 relations with 'note' like 'note=01-02' (5%)

1.111 without 'ref'

0 with 'ref' not like 'ref=01-02'

258 with 'ref' and 'note' like 'ref/note=01-02'

--Jo (talk) 22:49, 16 January 2021 (UTC)