[Knooppuntnetwerken] 2020-11-01 Release Knooppuntnet 3.0 + Planner!

Vraagje aan mijn geachte medeknooppuntmappers: Hoe belangrijke is de volgorde van de wegen in de knooppuntrouterelatie? In principe wil je hem natuurlijk op volgorde hebben, dat beheert makkelijk, maar als het een keertje niet zo is, wie heeft er dan last van?

  • Waymarkedtrails rendert gewoon, en de gpx is wel op volgorde (tenzij er meerdere fouten en onderbrekingen inzitten, dan geeft de sorteerroutine het op). Met samengestelde/opgedeelde lange routes komt het best vaak voor dat de sorteerroutine het opgeeft, maar bij de relatief simpele knooppuntroutes zelden.

  • Knooppuntnet kijkt zelf hoe je over de gegeven wegen van start naar eind komt, voordat de route verder geanalyseerd wordt en planbaar op de Planner verschijnt

  • Routing engines werken met het “gewicht” van de route, en dat hangt niet af van de volgorde maar van de vraag of de weg uberhaupt lid is van een routerelatie.

Mis ik hier iets? Andere routing mechanismes, andere data users die de precieze volgorde in de relatie nodig hebben?
Ik denk met name aan fietskaarten en fietsrouters, die het verst zijn met het gebruiken van de OSM relaties voor eindgebruikers.

En nog een andere vraag: bij Holtum in Limburg zijn nog state=connection routes voor fietsen.
https://experimental.knooppuntnet.nl/en/analysis/route/6844235/map
https://experimental.knooppuntnet.nl/en/analysis/route/6844559/map
https://experimental.knooppuntnet.nl/en/analysis/route/6844236/map
https://experimental.knooppuntnet.nl/en/analysis/route/8466015/map
https://experimental.knooppuntnet.nl/en/analysis/route/1970111/map

Weet iemand hier meer van? Bijvoorbeeld, hoe dit precies op de weg is aangegeven?
Heeft Holtum inderdaad een knooppunt genaamd “Holtum”? Ik zie op het betreffende punt (opname 2016) wel een bordje dat naar 4 verschillende knooppunten verwijst, maar dat zelf geen knooppuntaanduiding heeft.

Op de punten waar de aantakroutes halverwege een gewone knooppuntroute aanknopen, kan ik geen duidelijke beelden krijgen. Met name hoe er op die punten naar het centrale punt verwezen wordt. Eentje kan ik zien op mapillary https://www.mapillary.com/app/?lat=51.05013299999996&lng=5.838341000000014&z=18.868728336706543&focus=photo&pKey=JgK-Dpp_YeMptepu7D9IIw
Dat lijken inderdaad knooppuntbordje, en als ik ver inzoom dan lijkt het dat ze niet naar het centrale punt, maar de punten daarvoorbij wijzen (16 naar links is de gewone knooppuntroute, naar rechts 23 en 13.
Je kijkt daar vanuit de richting 11->16. Maar bij knooppunt 11 wordt niet verwezen naar 23, dus er is daar geen verbinding 11-23 via Holtum aangegeven. Je ontdekt pas later dat er een tussenafslag naar 23 is.

Onderweg op de aantakroutes zie ik wel knooppuntbordjes richting knooppunten in de omgeving staan., waar telkens 2 nummers op staan, maar in de omgekeerde richting zie ik geen bordjes.

Konklusie
Zoals de tagging nu is, zijn de aantakroutes niet analyseerbaar en planbaar in Knooppuntnet. Het punt in Holtum heeft geen naam of nummer, en er wordt op de weg niet naar verwezen, dus eigenlijk is deze tagging fout. Al zit ik daar niet heel erg mee!
De bewegwijzering is wel zodanig dat ik denk: dit is onderdeel van het fietsnetwerk en zou ook in de planner bruikbaar moeten zijn.
Maar hoe?

Oplossingen?
Sinds enige tijd hebben we “splitspunten”, dat zijn punten zonder nummer waar twee routes onderweg splitsen. Deze punten mogen dus als extra punt binnen een knooppuntrouterelatie voorkomen. De aftakpunten voldoen hieraan. In Knooppuntnet Planner zie je ze wel maar kun je ze niet aanklikken als plan-punt. De aantakroutes hebben dan in ieder geval een network node om op te landen.

Het centrale punt is eigenlijk ook geen knooppunt, maar het is 1 punt in 1 dorp waar een serie routes samenkomen, ik denk dat we dat wel als knooppunt mogen laten staan. Planner output wordt dan iets als [ …06 11 * Holtum * 23 …] wat op zich klopt, maar als nadeel heeft dat de fietser bij 11 niet ziet dat zhij 16 moet volgen om naar het splitspunt voor Holtum te komen. Dat klopt dan wel weer met de bewegwijzering, want die zegt dat bij 11 ook niet!

*Zelf noteer ik dit soort gevallen op papier als … > 11 > (16) maar bij * > Holtum > 23 > …
Het getal tussen haakjes geeft aan: richting dat, maar niet helemaal ernaartoe. *

Samenvatting voorstel
Splitspunten (rcn_ref=*) maken van de aantaknodes.

Is dit iets?

Principieel gezien is een relatie een geordende lijst met dus een volgorde. Een route heeft ook een volgorde, dus de correcte manier is om deze volgorde ook in de relatie aan te houden.

Meer praktisch merk ik dat de volgordefouten de eerste stap zijn in het ontstaan van echte onderbrekingen. Wanneer onderbrekingen daadwerkelijk zijn onstaan, dan is de route in het relatievenster van JOSM zo’n rommel, wanneer de volgorde ook niet klopt, dat het veel tijd kost om de fout daadwerkelijk op te lossen.

Klopt helemaal, voor lineaire routerelaties. Dat is een beheerprobleem wat je niet even kan verhelpen. De vraag is hier meer, wat moet een checker doen. Onderbrekingen signaleren, ja. Dus als je een volgordefout hebt in kombinatie met onderbrekingen, dan wil je een rooie vlag zien. Maar als verder alles klopt, alleen de volgorde is verstoord, zijn de gevolgen voor data users / renderers / routers dan zodanig dat de noodklok geluid moet worden?

Overigens, sinds Id zijn relatiebijwerker onderhanden heeft genomen, komen dit soort problemen in mijn ervaring veel en veel minder voor. Ik baseer dat dan op de langeafstandsroutes, waarin dit op zich al veel vaker voorkwam. Volgens mij had het iets te maken met de grootte van het gebied wat je binnenhaalt voor het editen, als een relatie uitgestrekter is heb je meer kans dat hij onvolledig of niet beschikbaar is en wat er niet of onvolledig is kan de editor ook niet goed checken en bijwerken. Sinds de wijziging halen ze volgens mij meer relaties binnen, ook als er maar een klein deel binnen de bbox valt.

Ik vind het prima wat Knooppuntnet op dit moment doet, zodat we deze fouten op kunnen lossen. Alle fouten zijn gecategoriseerd en volgordefouten staan onderaan, zodat je ze goed kan onderscheiden van belangrijkere fouten zoals onderbroken routes. Ik zou het zeker niet ‘de noodklok luiden’ noemen, maar meer ‘het opmerken van een fout’.

Eerder maakte Knooppuntnet volgens mij onderscheid tussen fouten en waarschuwingen. Daarbij stonden volgordefouten bij de waarschuwingen. Dit onderscheid zou terug kunnen komen, al weet ik niet hoe nuttig het is. De indeling lijkt me ook wat subjectief en daardoor lastig te maken.

Volgordefouten altijd melden.
Ze zijn ook vaak een indicatie dat er meer mis is en ook de begeleidende routes, zoals, LF, fietsroutes, wandelroutes, etc kunnen verstoord zijn, ook kunnen ze signaleren dat er bussen verkeerd liggen.
Veel volgordefouten zijn het gevolg van doorknippen in ID en dan gaat er van alles mis met allerlei routes
Ook weet ID nog steeds niet hoe je forward/backward sorteert en dat wil ik graag verhelpen.

Mijn ervaring is, dat je routes heel moet houden, in de relatie-editor moet de routelijn continu zijn.
Als je volgordefouten laat zitten weet je op het laatst niet meer wat een volgordefout en wat een gat is.
Zoals knooppuntnet het nu meldt is uitstekend.

Wat de route bij Holtum betreft, ik heb daar vanmorgen naar gekeken en ik wil er gewone routes van maken, die elkaar dan in Holtum kruisen. In Limburg liggen nog de nodige onbenoemde splitspunten.

Die andere 2 kunnen ook gewone routes worden met een ster splitspunt

:thumbsup:

Nog een punt (ja, ik ben weer lekker bezig…):

Aansluiten van ln-knooppuntnetwerk op rn knooppuntnetwerk is mogelijk!

Waarschijnlijk weet iedereen dit al, maar ik ik ben er net achtergekomen.
Je kan voor wandelen rwn en lwn netwerken maken. Wij hebben alles rwn gehouden, maar in Frankrijke en Duitsland kiezen ze voor lwn voor de knooppuntnetwerken. Ze vinden de routes en knoppen allemaal lokaal. Dat is ook zo, alleen kan het zijn dat de netwerken regionaal en zelfs landelijk worden maar daar zijn ze nog niet aan toe. Sinds de invoering van network:type=node_network kunnen er in principe ook netwerken van verschillend scope zijn.

Ik was benieuwd/bezorgd of zulke lwn netwerken wel kunnen aansluiten op onze rwn netwerken. Want ik wil wel internationaal kunnen plannen, maar ik wil niet retaggen. Ik denk zomaar dat ik daar wel steun voor heb, voor niet retaggen.

Wat (zonder ingrijpende aanpassingen) niet kan is: een connection route tussen een lwn_ref node en een rwn_ref node. De connection route zou dan zowel rwn als lwn moeten zijn, en je hebt maar 1 network-tag.

Wat zonder meer wél kan is: een connection node maken met zowel een lwn_ref als een rwn_ref. Die heeft dan naar het ene netwerk 1 of meer lwn routes, naar het andere netwerk 1 of meer rwn-routes. De connection node zit in beide netwerkrelaties met de rol connection.

De Planner blijkt dat netjes af te beelden en je kan er knooppunttripjes overheen plannen. In principe gaat dat zelfs goed als je een lwn-netwerken en een rwn-ref netwerk in het zelfde gebied hebt, dus overlappend. Je moet wel per netwerk konsekwent zijn.

Dit vind ik heel bemoedigend voor de internationale ontwikkelingen!

Eindelijk, Drenthe zit erin, voor wat betreft wandelnet. Al zag ik dat er ook al edits in de buurt van Borger zijn gedaan, dus daar lopen we voor op wandelnet :smiley:

:thumbsup:

Volgens mij kun je nog even :open_mouth:
https://georsdrenthe.icdn.nl/geoserver/RSDrenthe/wms?service=WMS&version=1.1.0&request=GetMap&layers=RSDrenthe:OSM,RSDrenthe:KnpsWandelRoutes,RSDrenthe:KnpsWandelKnooppunten&styles=&bbox=190000,485000,280000,590000&width=600&height=768&srs=EPSG:28992&format=application/openlayers#toggle

En dit komt er nog aan….
https://georsdrenthe.icdn.nl/geoserver/RSDrenthe/wms?service=WMS&version=1.1.0&request=GetMap&layers=RSDrenthe:OSM,RSDrenthe:KnpsRoutesInOntwikkelingWandel&styles=&bbox=190000,485000,280000,590000&width=600&height=768&srs=EPSG:28992&format=application/openlayers

In Hoogeveen heb ik nog geen paaltjes gezien, in Meppel daarintegen wel, maar die staat nog helemaal niet op de planning?

Mijn ervaring in uitbreidingegebieden (Utrecht, Noord-Holland) is dat wat ze aan de planners en publiciteitskanalen doorgeven nogal afwijkt van de werkelijkheid.

Geplande (of alleen nog maar verzonnen) maar nog niet geplaatste stukken worden al als netwerk doorgegeven (vaak zonder nummers en nog zonder aansluiting op omringende bestaande netwerken), er staan verbindingen over paden die (nog) niet bestaan. Maar ook omgekeerd, netwerken die allang uitgerold zijn zijn nog niet in de diverse materialen, databases en planners opgenomen.

De landelijke routedatabank voor wandelnetwerken krijgt in principe periodiek verversingen van de afzonderlijke netwerken. Maar die hebben dezelfde problemen als wij hebben met imports: je kan niet zomaar even een deel vervangen. Het moet wel blijven kloppen en aansluiten, en als er iets weg is moet je dat ook apart weten want “het zit niet in de update dus ik gooi het weg” is geeen aanvaardbare werkwijze. Vind ik dan, he.

Import is zo gebeurd, maar het is de hersteloperatie daarna waar het werk en de problemen in zitten. Daarom zijn databestanden niet of nauwelijks bruikbaar voor onderhoud.

Ik hoop nog steeds om mensen tegen te komen die een “verschillenvinder” kunnen maken tussen een (bijvoorbeeld) in de vorm van shapefiles aangeleverd wandelnetwerk en het overeenkomstige in OSM geregistreerde wandelnetwerk. Oplossen van de verschillen zal nog steeds handwerk zijn, je moet bijvoorbeeld een “verwijdering” wel verifiëren want daar zitten ook de paaltjes bij die een mapper heeft aangetroffen en gemapt maar die nog niet in het databestand zitten. En toevoegingen: daar zitten ook de paaltjes bij die wel bedacht en alvast in het databestand gezet zijn, maar die er nog helemaal niet staan.
Maar nu ben ik de meeste tijd kwijt aan vergelijken en opsporen via kaartmateriaal, en ik besteed mijn tijd liever aan daadwerkelijke aanpassingen.

Ideaal zou zijn een JOSM plugin die de wandelnetwerk-informatie in twee lagen (een shapefileslaag en de OSM datalaag) vergelijkt en een lijst aandachtspunten genereert (zoals de validator).
Kriteria voor vergelijking zullen best lastig zijn… voor knooppunten zal een afstands-kriterium gelden in kombinatie met het kenmerk.
Voor de routes zal een percentage alignment gelden, denk ik.

Als het alleen al helpt om toegevoegde, verwijderde of aanzienlijk verplaatste/verlegde knooppunten/routes te detekteren, dan help dat echt enorm.

Hoi,
Ik ben opzoek naar het wandelknooppunten netwerk in Nederland in een standaard TMS of WMS tile URL

Ik heb daar zelf geen ervaring mee, bestaat dit?

groeten,
Ruben

Hi airwolf, dat is een oude serie toch ? Maar goed ooit al eens een gids of kaart geprobeerd en genoten van de ervaring ?
Maar werp ook eens een blik op OSM, daar staan al die routes al op, downloaden is dan een kleine moeite toch ? Of niet voor iets nieuws kiezen, toch ?

Hoi Hendrikklaas,

om een lang verhaal kort te maken,
Ik gebruik een toepassing genaamd https://dynamic.watch
Hiermee kan ik gemakkelijk routes maken gebaseerd op de OpenCycleMap en naar mijn Garmin horloge sturen, de fietsknooppunten van Vlaanderen en Nederland staan hier ook in maar niet de Wandelknooppunten van Nederland. Als ik een TMS of WMS tile URL heb die derde partijen mogen gebruiken dan kan ik de maker van dynamic watch vragen dit toe te voegen voor mij. Dit is bijzonder handig voor me.
De paden staan er inderdaad allemaal op, maar niet de knooppunten.

Enig idee?
alvast bedankt

https://hiking.waymarkedtrails.org/ is ongeveer de enige kaart die de wandelknooppunten geeft, maar ik heb geen idee of die in dynamic watch bruikbaar is. Afstandmeten.nl heeft hem toegevoegd als achtergrondkaart (de “Open Walk”-laag), en OsmAnd kan hem ook als laag tonen, misschien zegt dat wat.

Maar je kan hem dus niet als knooppuntenplanner gebruiken, je zal dan zelf je route moeten bedenken en tekenen.

Even een topickaapje: Tussen Wormer en Wormerveer is de Zaanbrug gesloten voor herbouw, er komt een tijdelijke (anderhalf jaar) brug zo’n 150m oostelijker [1,2].

Over de oude Zaanbrug liepen een aantal bus-, fiets-, en wandelroutes. De busroutes heb ik al omgelegd. (changeset met nieuwe brug, busroutes omgelegd en wandel-fietsroutes aangepast)

De wandel(knooppunt)route bestaat uit 84-38 die over de brug liep. Vervolgens loopt aan de noordkant een route 38-39 zo dat deze over de rotonde aan de noordkant langs de tijdelijke brug. De daadwerkelijke route is makkelijk te gokken, maar ik weet niet welke tussenpunten er zijn/gaan komen. Hoe tag ik dit?

Voor de fiets(knooppunt)routes bestond uit een node 92, met zes punten rondom de brug (4 aan de zuidkant, 2 noord. Ik heb uit alle fietsroutes de noordelijke 2 punten weggehaald en het deel van de route over de brug. Ik heb bovendien de route 92 (zuidkant)-94 (verderop noordkant) omgelegd over de tijdelijke brug. Dit heeft wel tot gevolg dat (vanuit het zuiden vanuit punt 92 komende mensen een stukje dubbel moeten fietsen (naar de oude brug, omkeren en via de nieuwe brug). Bovendien bestaat het knooppunt 92 aan de noordkant (de nodes network:type=node_network, rcn_ref=92) nog.

Zonder info over de nieuwe routes en knooppunten die hier wellicht (of wellicht niet want “tijdelijk”) gaan komen heb ik geen idee hoe het beter te doen, maar tips hoor ik graag.

Ik heb trouwens de oude brug (die nu dicht is maar nog wel bestaat) de wegen op highway=road en access=no gezet, dat is mijn methode voor recent-afgesloten wegen waarbij ik de nieuwe configuratie nog niet ken.

Hoi allemaal,

Ik heb me de laatste tijd geworpen op het knooppuntennetwerk rondom Wijk bij Duurstede. Ik ben daarmee dvdhovens persoonlijke knooppuntenterrorist geworden, want ik blijk telkenmale onvolkomenheden te hebben in mijn wijzigingensets. Hoewel hij erg behulpzaam is geweest en me goed op weg heeft geholpen, durf ik nu niet meer bij hem aan te kloppen en ben ik ietwat beschroomd nieuwe deelroutes toe te voegen.

Ofschoon ik telkens controleer op fouten gebeurt het toch weer geregeld dat ik wegen i.p.v. routes toevoeg aan het knooppuntennetwerk. Het gebeurt vooral op plekken waarbij de deelroute bestaat uit slechts 1 wegdeel.

Kan het zijn dat JOSM deelroutes bestaande uit 1 wegdeel stiekem toch als weg toevoegt i.p.v. relatie?