Node networks: proposal to normalise and improve tagging

LS
Sorry to do this in English! I have posted this same proposal in the German forum and on github.

In Nederland, network=rwn and rcn have been (ab)used to accommodate walking node networks and cycling node networks. We would like to repair this, by proposing an alternative way to indicate that routes belong to a node network. I know this was discussed in the German forum as well.

The Dutch have discussed this at length. Bottom line we propose simply to
add a tag network_type=node_network to the route relations of the node
networks.
Nodes do not need this tag, the fact that they have the xxn_ref tag says it
all.

This allows node networks to be defined for all modes of transportation and
all geographical scopes. The setup can handle other network_types should
they arise; other modes of transportation; and other geographical scopes if
necessary (so intercontinental drone hub_networks, no problem!)

Node network checking-site knooppuntnet.be/knooppuntnet.nl (the site
formerly known as vmarc.be, i.e. user vmarc) has indicated it is an
easy-to-implement solution and it would allow the site to facilitate german node networks as well.

From statements of waymarkedtrails we understand that they can work with this too; we have asked them (on github) to confirm this.

We think maybe the network relation with all the routes and nodes in it is
no longer necessary. That is in the current system the main
pain-in-the-butt for node network maintenance, and nobody really used it.

Existing base does not need retagging, just add the extra tag to the individual node
route relations. In Nederland this can be done quick and easy because we
have no regional linear routes defined: all rwn routes are node_network
routes.

In Germany I think there is a mix of linear and node rwn routes, so
it’s a project but I think not a large or difficult one. I would be glad to help out if necessary. Maybe this proposal even helps in separating rXn node routes from "real " rXn routes. I am not sure about the Belgian situation, but I hope it sort of resembes the Dutch situation!

Adding the extra tag changes nothing for the current rendering, so existing
data users can keep their system in place while developing handling of the
new system, then changeover at their own time. If they don’t, nothing changes for them.

I would like to hear your questions and comments on this proposal. We have considered a lot of arguments to get to this simple result, but please, surprise me with things we haven’t thought of!

The idea is to get to one common proposal (DE+BE+NL), then present this to the tagging list as the way we want to normalise/undo the exception we created to accommodate the rising node network system in a more generic way.

Fr gr Peter Elderson

LS
Het is als volgt geworden:

network:type=node_network toevoegen aan alle knooppunten, knooppuntroutes en de knooppuntnetwerkrelaties.

Dit geldt voor alle recreatieve knooppuntnetwerken.

Daardoor staat bv network=rcn zonder de nieuwe tag niet meer voor een fietsknooppuntnetwerk, maar voor een gewone regionale fietsroute.

Dit houdt tevens in dat er lXn, nXn en iXn knooppuntnetwerken getagd zouden kunnen worden.
Indien er andere systemen in gebruik komen, bv kleurkeuzenetwerk (ik verzin maar iets) dan kan dat getagd worden dmv andere waarden van network:type.

Een logische vraag is: waarom ook de knooppunten meetaggen, dat zijn immers nodes met een knooppuntref erin, dus dan weet je het al! Antwoord: het blijkt behoorlijk vaak voor te komen dat nodes met een XXn_ref getagd worden terwijl ze níet in een knooppuntnetwerk zitten. Daar zijn zeker wat fouten bij, maar ook series waar het niet onlogisch is, bijvoorbeeld genummerde paaltjes die een kanoroute in volgorde passeert, getagd met lpn_ref=*. Vandaar.

Waarom is het niet voldoende dit enkel aan de relaties toe te voegen ? Die knopen en routes zitten in die relaties en dus kan je de informatie toch ook via die relatie afleiden ? Het feit dat de data incorrect is (knopen die niet in een relatie zitten), lijkt me een zwak excuus.

Bovendien hebben knopen geen network-tag, dus komt het mij vreemd over om de “network”-eigenschap daar verder te specificeren.

Als ik verder denk, is het niet voldoende om te weten dat er een knooppuntnetwerk relatie is ? Is dit niet hetzelfde als alles aan te passen met die extra tag ?

Aan de andere kant, er is ook al wat kritiek geweest op die netwerk relaties, omdat die feitelijk collecties voorstellen, iets wat we normaal gezien niet mappen in OSM.

Maar ik snap nog niet waarom de lpn_ref een argument zou zijn om rwn_ref niet altijd te beschouwen als deel van een knooppuntnetwerk. Het zijn toch 2 verschillende tags ?

Klopt. In theorie zou je aan het lidmaatschap van de relatie kunnen zien dat een node een knooppunt is voor dat netwerk, en dat geldt ook voor de routes. Maar
a. verwerkers zeggen dat dat veel lastiger is om te coderen dan een kenmerk van de objecten zelf. Nou taggen we niet voor de dataverwerkeing, maar we kunnne er wel rekening mee houden door eea zo eenvoudig mogelijk op te lossen
b. De netwerkrelaties (collecties) en de connections zorgen voor veel onderhoudswerk, terwijl (a) niemand er echt op zit te wachten!
c. Alle kleinere netwerkjes smelten in fases samen tot één groot netwerk. In NoordBrabant zitten we voor wandelen nu met elkaar overlappende plaatselijke, regionale en gemeentelijke netwerkjes. Dit is niet bij te houden.

daarom denken we er sterk over om de netwerkrelaties te laten vall, en voor beheer/adminstratie/checken een indeling naar gemeentegrenzen te doen (op vmarc’s knooppuntnet). De gemeentegrenze staan in OSM dus dat zou helemaal zonder tagging moeten kunnen. Taggen wordt daardoor een stuk eenvoudiger!

Ik heb me denk ik niet duidelijk uitgedrukt. lpn_ref was maar een voorbeeld; hetzelfde is aan de hand voor fietsreferentiepunten, en het kan evengoed voor andere recreatieve routes van alle geografische scopes. Je kan niet zeggen dat dat helemaal verkeerd is; het is een logisch gebruik van de XXn_ref keys, alleen hadden we het zo niet bedoeld. Dit onvoorziene gebruik kan nu gewoon behouden blijven want we geven met de network:type=node_network tag aan of het om een echt knooppunt van een knooppuntnetwerk gaat. Generiek opgelost.

Op deze manier kan het systeem ingevoerd worden zonder wijzigingen van bestaande tagging. Alles blijft zowizo werken.

Welk netwerk het is (network=XXn) staat ook in de XXn_ref=* tag. Daarom hoeft die network-tag niet nog eens in de nodes. Dat was denk ik de destijds gekozen oplossing voor het feit dat nodes in meerdere netwerken kunnen zitten: je kan niet twee keer de network-key gebruiken.

PS Goeie vragen, trouwens!

Dus als de network relaties teveel werk zijn, het zijn toch “collecties”, kunnen we ze dan niet

  • ze beter afschaffen
  • nodes toevoegen aan de route relaties
  • de tags van de network relatie op de route relatie zetten (hoewel sommige verzonnen tags zijn (zoals ref). Verder zou je dan enkel de operator en de naam van het netwerk copiëren.
  • jullie nieuwe tag enkel op de route zetten.

Heb je enkel een probleem met de role “connection”. Maar dat is ook weer zoiets waarvan ik me afvraag, wat is het nut ? Is dat ech “iets”, of hebben we dat als mappers maar verzonnen. Maar die kan je ook op de route zetten via “connection=yes” of zo.

**Afschaffen netwerkrelaties? **
Er is ooit besloten om de (toen nog losse) knooppuntnetwerken als relaties in te voeren. Logisch, want je zag ze op de weg: de netwerknaam stond meestal opde paaltjes en de infoborden. Via de relatie kon je ze beheren. vmarc heeft daar zijn vmarc.be site (nu: knooppuntnet.be en knooppuntnet.nl) op gebouwd, die de integriteit van de netwerken kontroleert. Nu groeien ze steeds meer samen tot één groot netwerk. Een aantal mappers vinden ze onhanteerbaar, maar een aantal werkt juist vanuit knooppuntnet per netwerk om de boel te onderhouden. We hebben dus geen consensus over afschaffen. Ik hoor zelf bij de groep: “afschaffen als we een werkbaar alternatief hebben”.
vmarc kijkt nu of het mogelijk is om voor beheer/checken/verbeteren een indeling naar gemeente (of andere administratieve grens) te hanteren. Dat kan in principe gewoon uit de OSM data gehaald worden. Als dat tot stand komt denk ik dat afschaffen van de netwerkrelaties redelijk is.

Nodes toevoegen aan de routes
Sommige mappers doen dat, het is voor hun een houvast bij het invoeren/onderhouden van het netwerk. Zelf doe ik het niet, maar ik heb er ook geen last van dus als ze er zijn laat ik ze staan. Voor het gebruik van het netwerk (renderen en andere data use) is het niet nodig; de nodes staan er impliciet al in als eind/startpunt van een way. Als het nuttig zou zijn voor bv een knooppuntrouteplanner dan zou ik ze er met alle plezier ook aan toe gaan voegen.

Taggen routerelaties met naam en operator
Op de weg vind je in NL tegenwoordig meestal de naam van het netwerk en de operator niet meer terug op de paaltjes en pijltjes. Af en toe nog wel, maar dan klopt het vaak niet meer. Op de spaarzame informatieborden onderweg vind je ze meestal wel, maar om dan alle node2node routes ermee te taggen, de meesten gaan dat niet doen. As de netwerkrelatie wordt afgeschaft moeten we daar nog 's over praten.

network:type niet op de nodes zetten?
Zoals gezegd, het feit dat de nodes een XXn_ref hebben is niet voldoende informatie dat ze bij een knooppuntnetwerk horen. Er zijn inmiddels veel nodes behorend bij routes van verschillende transportmodes die zo’n _ref hebben waarbij dat niet als fout gezien kan worden, meer als onbedoeld maar logisch gebruik. Het zijn namelijk genummerde referentiepunten op de routes. Dus zetten we de node_network tag op de echte knooppunten. Persoonlijk ben ik ervoor om de nodes níet bij te taggen, ik denk namelijk dat er in feite weinig verschil is in behandeling door renderers, data users en eindgebruikers. Zowel knooppunten als referentiepunten zijn punten waar je onderweg langs komt. Je gaat van start via een aantal nummerpunten naar je bestemming en dat je bij de nummers geen andere richting kan kiezen boeit eigenlijk niet! Maar anderen denken daar anders over, en dit is wat we voor nu afgesproken hebben. Mochten we er in de (hopelijk nabije) toekomst anders over beslen, dan zijn die tags snel weer weggehaald, nog sneller dan we ze er nu bijzetten.

Samengevat: persoonlijk ben ik het met je eens, maar we bereiken over een aantal punten nu geen consensus en we willlen daar de hoofdpunten niet pop laten struikelen:

  • duidelijke scheiding tussen knooppuntnetwerken en reguliere recreatieve routes
  • ongedaan maken van de uitzondering voor NL/BE (en halfhalf voor DE) wat betreft het exclusieve gebruik van rXn voor knooppuntnetwerken. rXn komt weer beschikbaar voor reguliere streekroutes.

De belangrijkste bijwerkingen van de gekozen weg zijn:

  • Knooppuntnetwerken kunnen nu voor alle geografische scopes worden geregistreerd
  • Andere netwerkmethoden/setups/configs kunnen ook worden verwerkt.

Wat betreft dat laatste: gisteren was er een vraag op de tagging lijst over een netwerk van fiets-hoofdroutes (voorkeursroutes) in/rond een stad. Het is een duidelijk netwerk met signposts en pijlbordjes speciaal voor fietsers, maar geen knooppunten. Dat zou een kandidaat kunnen zijn: een voorkeursroutenetwerk. In/rond Amsterdam en andere grote steden heb je zoiets ook voor vrachtwagenroutes.

Status report
All elements of all recreational node networks in the Netherlands now have the tag network:type=node_network. The maintenance site https://www.knooppuntnet.nl is being modified to check for the tag.
I think it is up to the German and Belgian communities to add the tag to ‘their’ node networks. Of course, we would be glad to help out, when asked.

Blijkbaar is er ook al hier en daar iets in België gewijzigd door u, niet ?

Toch nog een vraagje ivm met die tag op knopen, ik begrijp daar het nut nog niet van (en het lijkt me zelfs fout).

Je schrijft:

Dus stel dat een knoop 2 XXn_refs heeft, eentje van een node-netwerk (bv. rwn_ref) en eentje van een niet node-netwerk (zal voorlopig iets fictiefs zijn yyy_ref).

Als ik nu network:type=node_network op die node zet, maak ik van zowel van rwn_ref als yyy_ref een network node. Dat kan toch niet de bedoeling zijn ?

Dus ik blijf erbij dat dit op de relatie-niveau moet opgelost worden en niet op de nodes.
Routes zijn “uniek” binnen een netwerk en daar kan die dubbelzinnigheid niet optreden

Ik heb dacht ik niet aan de Belgische netwerken gezeten! Maar er waren een paar erg enthousiaste mensen bezig om alles even te organiseren terwijl ik nog overleg aan het voeren was.

Wat betreft de knooppunten. Dit is de onderbouwing:

  1. Een knooppunt vermeldt zijn ref, en het is herkenbaar door vormgeving en opstelling als een knooppunt. Je ziet daar niet aan welk netwerk en welke operator.
  2. Alleen het feit dat er een xxn_de ref betekent niet dat het om een knooppuntnetwerk gaat.

Wegens 2. was er een extra kenmerk nodig. Wegens 1. is het zichtaar dat het om een knooppunt gaat. Dat is dus een verifieerbare eigenschap van het fysieke object.

Inderdaad is het zo dat een node een knooppunt in een knooppuntnetwerk kan zijn terwijl het tegelijk een genummerd punt in een ander systeem kan zijn.
Wij denken nu dat dit niet veel voor zal komen, maar het is niet uitgesloten en het gebruik van xxn_ref buiten knooppuntnetwerken komt al voor.

De oplossing die wij zien is dat er in dat geval twee nodes gemaakt worden. Dat is niet heel gek, want in alle gevallen die wij nu kennen zijn het ook fysiek aparte paaltjes/borden. Het kombineren wat nu gebeurt (Fkp’s zijn in OSM vaak dezelfde nodes als Wkp’s) betekent meestal niet dat het hetzelfde paaltje is. Meestal wordt voor beide de verbindende node van kruisende wegen gebruikt ipv een aparte node.

De niet-knooppunt xxn_refs die wij nu kennen, zijn genummerde punten waar je langskomt zonder af te slaan. Die zullen dus juist niet op afslagen staan.

Waymarkedtrails heeft speciale knooppuntnetwerkrendering geïmplementeerd. Zie https://hiking.waymarkedtrails.org/#?map=14!51.5521!5.2183
De logika is: als er een tag network:type=node_network is, wordt network=* genegeerd en wordt de knooppuntnetwerkrendering gebruikt.

Het is nu mogelijk om echte regionale routes te mappen en die ook duidelijk op de kaart te onderscheiden.

@vmarc heeft voortgang gemeld:

Wel jammer dat ze die logica dan niet gebruiken om onder “Routes” de note (bv 03-07) te tonen ipv van id van de relatie.

Ik heb in github gevraagd of ze kunnen doen: a. naam indien aanwezig, anders b. note indien aanwezig, anders c. objectnummer van de relatie.

We zouden ook kunnen bespreken om name=xx-zz te gebruiken ipv note=xx-zz. Ons gebruik van note is niet konform de wiki. Ik begrijp ook niet waarom deze keuze gemaakt is, want het is gewoon een naam: [knooppuntroute] xx-zz. Een andere naam hoeft zo’n route’tje ook niet te hebben. Dus MI is dit ook een uitzondering die opgeheven zou kunnen worden. Maar ik heb dat nog niet aanhangig gemaakt.

die discussie is wel een paar keer op de Belgische mailing list gehouden. Er was telkens heftige tegenstand om name te gebruiken. Het is dan ook geen naam, ref zou nog wel kunnen voor mij.
Maar waarom weer iets wijzigen dat al jaren in gebruik is, er valt nog zoveel te doen. Wijzigen van tags lijkt me gewoon bezigheidstherapie :slight_smile:

Hm, ik begrijp die tegenstand niet zo goed. Als ik het bij plannen, bespreken of gebruiken met iemand erover heb, noemen we de route naar de knooppunten die hij verbindt. Dat is dus de naam. Hij staat niet onderweg op straat, maar is direkt verbonden met de knooppunten die hij verbindt, dus hij is op de weg net zo aanwezig als de route zelf.

ref is wat mij betreft ook prima, ook dat is direkt verbonden met de (refs van de) knooppunten. Waarom wijzigen? Nou, je kwam er zelf mee n.a.v. de knullige display van de relatienummers op waymarkedtrails. Waymarkedtrails heeft mij gemeld dat ze de note niet voor display gaan gebruiken. Ons gebruik van note hiervoor is rechtstreeks in strijd met de bedoeling van het veld: vrijetekst-aantekeningen over het mappen van het object, ten behoeve van het mappen. Wat dus voor knooppuntroutes nu niet kan.

Het gaat dus om een correctie waarmee een uitzondering wordt opgeheven. Het is wel een klus, maar niet onwijs veel werk, en dan zitten we terug binnen de OSM-dokumentatie. Wie het niet wil doen, ook geen probleem. Er gaat niks fout.

Waarom is het geen naam? Iedereen die het over die relatie heeft noemt de route naar de knooppunten die hij verbindt. Op de weg is hij ook te vinden: op beide genummerde knooppunten staat een pijl met een nummer naar het andere knooppunt. 10-11 staat dus feitelijk op knooppunten 10 en 11. Dus dat is de naam.
Een volkse naam heeft zo’n route niet, in tegenstelling tot de reguliere routes die vaak een themanaam of een bedachte naam hebben. Is dat het?

Omdat de knooppunten zelf alleen een ref hebben (XXn_ref) is het ook logisch om 10-11 als een ref te zien. Anderen vinden ref ook acceptabel, alleen Sarah Hoffman van waymarkedtrails noemt het “abuse” van de ref-tag, nog erger dan het gebruiken van de note-tag, zonder verdere uitleg. Snap jij dat?

Inmiddels hebben we wat geexperimenteerd. Een aantal mappers zijn de ref gaan taggen met precies dezelfde waarde als note. Bovendien hebben we streekpaden rwn gemaakt, immers dat kan nu omdat de knooppuntnetwerken losgemaakt zijn van de geografische scope.

Het resultaat van de drie operaties (network:type=node_network, streekpaden->rwn en ref=xx-yy) op waymared trails is hier te zien:

https://hiking.waymarkedtrails.org/#routelist?map=13!51.9607!4.6226

knooppuntnet.be is geheel aangepast aan de nieuwe tagging. (terzijde: Daar wordt nu gekeken of het mogelijk is om zonder de netwerkrelaties te gaan werken. De verdeling in subnetwerken is dan gebaseerd op de bestuurlijke grenzen (gemeentegrenzen in NL), wat gewoon uit de database bepaald kan worden zodat er geen tags en roles voor nodig zijn.)

Id gaat een paar presets aanpassen, en OsmAnd heeft een wijziging in rendering van fiets- en wandelroutes geïmplementeerd voor de geplande release van 1 feb 2020.

Dus ik kan best de “Mapping in België” JOSM preset aanpassen en ref ipv note gebruiken ?
network:type had ik eerder al eens toegevoegd.

In België zou een verdeling naar gemeente nogal vreemd zijn. Niemand doet dat hier voor zover ik weet.

Misschien omdat 10-11 feitelijk een aanduiding is dat de route knopen 10 en 11 verbind. Het is geen referentie nummer, noch een naam. Het is de route van 10 naar 11, net zoals je kan zeggen dat de E19 van Antwerpen naar Breda loopt. Die mappen we ook niet als ref=“Antwerpen-Breda”, noch name=“Antwerpen-Breda” (voor de ene richting)

En aangezien we weten tussen welke 2 knooppunten een route loopt, hoef je er feitelijk niets op te zetten. Het is enkel voor het gemak om een relatie te selecteren in je editor dat het ding een naam of label moet hebben. Volgens mij tonen de (sommige/ de meeste ?) officiële kaarten in Vlaanderen helemaal geen label bij de routes.

In dat opzicht is het inderdaad een “note”, een veld dat het leven van de mapper gemakkelijker maakt, maar het stelt niets voor in werkelijkheid