Node networks: proposal to normalise and improve tagging

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

In JOSM zou je de inderdaad de preset kunnen aanpassen, en ik denk ook de weergavestijl die nu de note rendert tijdens het mappen. Ik weet de naam niet uit mijn hoofd.

In NL zijn de wandelnetwerkjes allemaal lokaal apart begonnen, vervolgens gingen de dorpen samendoen of werden een uitbreiding van een bestaand netwerk. Nu zijn ze bijna allemaal provinciaal, en nu het landelijk dekkend begint te worden verschuift het zelfs naar landelijk. De veranderingen zijn zo snel dat OSM het niet kan volgen, en je kan het op de weg ook niet meer zien in welk netwerk je zit. Voor beheer heb je er ook weinig aan.

Dus de indeling in aparte netwerkjes is niet meer zinvol in NL. Het komt in ieder geval niet meer overeen met de situatie op de weg. Waarom zou je dan nog dat hele gedoe met connections en netwerkrelaties blijven doen? De netwerkrelaties zelf worden door niemand gebruikt, behalve op knooppuntnet.be en dan alleen om hanteerbare clusters te hebben.
Dus de gedachte is om het in OSM niet meer in netwerken te verdelen en op knooppuntnet een puur administratieve indeling te gebruiken waar geen tagging voor nodig is. De administratieve grenzen als boundary’s voor het onderhoudswerk gebruiken ligt dan voor de hand.

In Vlaanderen is het aan de namen te zien meer streekgebonden en met losse netwerken die apart beheerd worden en met weinig connecties ertussen? Dan is het logisch om het ook zo op knooppuntnet te willen onderhouden. Volgens mij was vmarc bezig om voor knoooppuntnet de indeling naar administratieve grens te testen en wil hij die aanbieden naast de indeling naar netwerk.

Overigens zijn NL gemeenten tegenwoordig verbanden met meerdere woonplaatsen erin. Zo woon ik in de gemeente Zuidplas, met de woonplaatsen Nieuwerkerk aan de IJssel, Zevenhuizen en Oud Verlaat, Moordrecht, en Moerkapelle. Ons wandelnetwerk heb ik (met een werkgroepje) ontwikkeld als Wandelnetwerk Zuidplas, maar bij de uitvoering is het als uitbreiding van een ander knooppuntnetwerk gedaan, en inmiddels zijn alle netwerkjes van de provincie Zuid-Holland 1 netwerk, waar een routebureau voor alle gemarkeerde netwerken en routes gaat zorgen. Andere provincies hebben ook routebureaus. Steeds meer routebureaus maken geen eigen planner meer maar linken de gebruikers door naar de inmiddels ontwikkelde landelijke knooppuntplanners en mobiele knooppunt-apps.
Streekgebonden of themagebonden aanbod doet men graag op de sites, als toeristentrekkers, maar dat wordt steeds vaker gedaan door aan de streek of het thema een gebied te verbinden en de routekaart daar te focussen, met de voor toerisme interessante POI’s erop.

Waar men vroeger steevast Google maps gebruikte als ondergrond, is dat tegenwoordig vrijwel altijd OpenStreetMap. Oorzaak: Google ging teveel geld vragen en OSM kost niks! Maar als je een route naar het beginpunt opvraagt dan verschijnt Google maps ineens weer. Kennelijk is dat nog gratis!

In Vlaanderen worden de netwerken (de meeste toch) door de provicies aangelegd. Er zijn een paar netwerken die door gemeenten zijn aangelegd.

Het meest uitgebreide netwerk is Antwerpse Kempen (zo aangegeven op de paaltjes), maar bestaat uit deelnetwerken. Deze zijn terug te vinden op de officiële brochures en kaarten langs de weg, alsook op wandelknooppunt.be Die zijn wel bijna allemaal onderling verbonden.

Ook Rivierenland sluit aan op Land van Stille waters. Sinds dit jaar is in het zuiden het netwerk Brabantse Kouters erbij gekomen (deels digitaal), die op die 2 aansluit. Dus met de jaren zullen er wel meer verbindingen komen. Maar het gaat steeds over grote netwerken die erbij komen. Dus een iets andere ontstaansgeschiedenis dan in Nederland.

Ik heb het idee dat het toch dezelfde kant opgaat…