Die overlappen zijn niet te vermijden en worden in knooppuntnet niet gemeld, gelukkig maar.
Bij het rcn heb je ze ook, in sommige netwerken over kilometers, bijv. in Limburg en Brabant.
En bij de oosterburen is het zeer gebruikelijk. Daar staan lang niet overal knooppunten, er zijn ook veel punten waar het knooppuntnetwerk splitst, maar geen knooppunt staat. Dat is daar geen probleem door de andere manier van bewegwijzeren. Bij een knooppunt wordt dan naar 2 knooppunten verwezen en ergens onderweg splitsen de routes.
Ah op die manier, dan zijn het dus eerder mikpunten dan knooppunten 
Inmiddels heb ik op verzoek van een Brabander het wandelknooppuntnetwerk rond Veghel (Meierijstad) ingevoerd. Ik zag dat er ook alweer kleine verbeteringen aangebracht zijn, foutjes van mij verbeterd, bedankt daarvoor! Daarna heb ik gezorgd dat knooppuntnet.nl geen fouten/feiten meer geeft. Top-tool!
Dus ik heb netjes alle netwerkrelaties en connecties bijgewerkt, de volgorde aangehouden en zo.
Knooppunten in de relatie opnemen en expected zetten heb ik vrijwel nergens gedaan, de meeste omringende netwerken hadden dat ook niet (alleen Uden wel, dacht ik).
Ik heb ingevoerd tot en met de connections, dus ik heb niet alle aangrenzende netwerkjes aangevuld. In totaal is Brabant nog lang niet klaar!
Het tijdrovendste en foutgevoeligste deel van het werk is het gedoe met verschillende netwerken en met connections. Sorteren/omdraaien van losse knoop-knoopverbindingen is in JOSM geen enkel probleem.
Ik ben eens dat het Tentakel model te ingewikkeld is voor wat nodig is.
Wat betreft afschaffen van de netwerkrelatie zie is als voordeel makkelijker beheer maar qua data model, vindt ik dat een netwerkrelatie precies klopt.
De alternatieven om in de routes en een knooppunten een tag op te nemen met de naam van het netwerk vindt ik niet kloppen (je krijgt geheid spellingverschillen en te veel redundantie vind ik), als het toch moet dan wat mij betreft werken met een boundary, alle knoppunten en routes binnen die boundary zijn onderdeel van het netwerk, routes die over de boundary gaan zijn connecties, maar zogezegd niet mijn voorkeur.
De naam van het netwerk in de elementen opnemen zou ik mordicus tegen zijn. Veel werk en foutgevoelig is één reden, maar vooral dat je aan de knooppunten en routepijltjes helemaal niet ziet welk netwerk het is. Bij voorkeur hou je het zo simpel dat een individuele mapper die iets tegenkomt het er gewoon in kan zetten zonder zoektochten naar externe informatie.
Bij wandelknooppuntnetwerken is het zo dat de netwerken allemaal aan elkaar groeien en ook in steeds grotere clusters beheerd worden waarbij de oorspronkelijke begrenzingen en namen veranderen. Op de weg zie je daar vrijwel nooit iets van, hooguit op de informatieborden die af en toe lukraak her en der staan. Voor de wandelaars is er 1 meldpunt: Meldpunt Wandelen van Wandelnet.
Bekende renderers doen niets met de netwerkrelatie. Voor hen is het een onwerkbare zak met routetjes en nodes die ze op grond van de routetags en nodetags toch al kunnen weergeven, dus de netwerkrelatie voegt niets toe.
**Routers **kunnen ook met de routes zelf werken. Als je kan zien dat het knooppuntenroutes zijn, kan je ze in een routeerpofiel zwaarder gewicht geven. Zo bereik je dat plannen van A naar B met een profiel bv. KnooppuntWandelen, vooral of knooppuntroutes gekozen worden.
Planners waarbij je zelf de knooppunten aanwijst waar je langswil, daar heb ik nog minder verstand van. Ik zie er veel, maar die gebruiken op de OSM-ondergrond een eigen knooppunten/routedatabase met een planningsapplikatie. Misschien dat een echte OSM-knooppuntenplanner een netwerkrelatie kan gebruiken? Of misschien is dit hetzelfde als routeren: je geeft aan dat je wil knooppuntrouteren (Profiel), dan klik je een reeks kaartlokaties aan (al dan niet knooppunten) en vervolgens routeert hij je van Start naar Eind via de aangeklikte punten met voorkeur (hoog gewicht) voor knooppuntroutes. Dan is het wel fijn als hij de knooppunten vervolgens opsomt in de aanwijzingenlijst en eventueel de stembegeleiding als je ermee navigeert, maar ook daar heb je de netwerkrelatie niet voor nodig.
Blijft over: beheer en controle lees: knooppuntnet (vmarc) en JOSM.
Het is natuurlijk gemakkelijk als je een indeling in losse netwerken hebt, maar dan moet dat wel enigszins stabiel blijven en op de werkelijkheid gebaseerd zijn. Zoals het nu is, bij wandelknooppuntnetwerken, is het heel vaak niet meer konform de realiteit op de weg, en het verandert ook nog voortdurend en zonder dat het zichtbaar is, niet bij te houden dus!
Kortom, als we voor beheer en controle toekunnen met een administratieve indeling die uit de lokatie en OSM af te leiden is, dan vind ik dat al bij al een veel betere oplossing. In OSM heb je dan geen netwerknaam, maar in toepassingen kan je de naam van het administratieve gebied (zal bij ons wel gemeente zijn, voor wandelen) gebruiken: het Wandelknooppuntennetwerk van Krimpenerwaard bevat alle knooppunten en knooppuntroutes in het grondgebied van de gemeente Krimpenerwaard. Grensoverschrijdende routes neem je gewoon in beide selecties op. Oftewel, je kan instant een netwerkrelatie maken voor zolang als je hem nodig hebt.
Het hele connection gedoe verdwijnt dan. De dubbele vastlegging dat een route of knooppunt een netwerkelement is (namelijk in de tags én in de netwerkrelatie) verdwijnt ook. Daar hoef je dan ook niet meer op te kontroleren. Je kan nog wel andere kontroles doen, bijvoorbeeld: waar twee knooppuntroutes samenkomen zou een knooppunt moeten zijn (en dus minimaal getagd moeten zijn met…). Een knooppuntroute hoort te beginnen en eindigen met een knooppunt. Een knooppunt zou als eindpunt aan minstens 1 knooppuntroute moeten zitten. Etc.
Als je bij zo’n administratief “netwerk” in knooppuntnet ook nog die handige “Edit met JOSM” knop hebt, kan je een gemeentegebied ook in één keer in JOSM binnenhalen voor onderhoud.
Waarschijnlijk zijn er ook nadelen of kunnen er dingen niet die mij mogelijk lijken? Ik hoor het graag!