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

Leg eens uit, wat kan ik met mapcomplete, wat niet op knooppuntnet te zien is?

Ik begrijp hier even niets van, hoezo zou je de knooppunten “los” moeten laten? Ik heb het hele Amstelland-Netwerk ook “tijdens het nalopen” al ingevoegd. Weliswaar met een aantal facts, maar ja.

Hoe heb je dat precies gedaan?

  1. Ik wandel met OSMand die een GPX opneemt. Als ik een paaltje tegenkom, neem ik een audionote op met “Dit is node X”.
  2. Als ik thuiskom download ik GPX-track en AVnotes. De GPX-track sleep ik in JOSM
  3. In JOSM maak ik de routes aan langs (wandel)wegen. De nodes zet ik dus op de kruispunten van de routes, dit is dus altijd een node op de wegen

Dus ik snap niet waarom je nodes náást de wegen zouden moeten liggen.

Nee, dat moet niet. Maar als je een “onschuldige wandelaar” met MapComplete op pad stuurt, dan kan die alleen bestaande knooppunten aanpassen, of nieuwe toevoegen. De nieuwe is altijd een losse node. Dat is niet erg, mij helpt het bij het invoeren. De losse node even precies op de goede plek zetten en M doen is geen moeite.

Want aan de tracks kan ik niet zien waar precies een knooppunt zit.

Kennelijk kan jij dat aan de audionote zien/horen? Want die kende ik nog niet. Wil ik ook wel eens proberen.

Vandaag eens uitgetest. Ik kan inderdaad een audio/videonotitie plaatsen, ook een foto maken, maar ik zie geen mogelijkheid om dat aan de track te koppelen of naar OSM te uploaden (kan met een track wel, dus misschien mis ik een optie?). Dat maakt het wat lastiger, want dan moet ik bij het verwerken het kleine OsmAnd-schermpje ernaast houden en meeschuiven.

Als iemand anders dit doet en dan aanlevert aan mij voor invoer, dan wordt het nog lastiger. Ik schiet dan meer op met bv. een mapillary serie.

Maar daarvoor moet de “verkenner” dan wel een leercurve doormaken. Wat ik probeer is dat een willekeurige persoon op zeer eenvoudige wijze voorwerk doet op de wegwat mij helpt bij het invoeren. Dat kan met een tool als MapComplete plus een domme tracker zoals Geo Tracker. Ik werk samen met vrijwilligers wandelen-oude-stijl, en die kan ik onmogelijk OsmAnd en Mapillary aansmeren, maar een simpel (1 object) mapcomplete-thema en Geo Tracker lukt bij (bijna) allemaal.

Ik heb eerder een kontaktpersoon gehad die met Id de knooppunten plaatste en de tracks aanleverde, maar Id was een brug te ver: het lukte wel, maar hij haakte of wegens de tool zelf, die is veel e uitgebreid, te technisch en zonder kursus onbegrijpelijk.

Maar ik ben nog in gesprek met mijn kontaktpersoon voor het wandelnetwerk Noord-Holland (beneden de lijn A’dam-Haarlem, grenzend aan Zuid-Holland.) Kijken waar we op uitkomen! Op dit moment vraagt hij zich nog af wat het het verschil tussen OSM en de routedatabank, tussen tracks, wegen en routes, en waarom je shapefiles niet automatisch kan omzetten naar OSM.

Ik gebruik hiervoor twee plugins: de track recording plugin en de Audio/Video notes.
Als ik een audio note maak terwijl er een track opgenomen wordt, dan komt er in die track een waypoint.

Als ik vervolgens thuis ben dan haal ik de audio notes en tracks van mijn telefoon en zet ze in dezelfde directory op mijn computer.
In mijn geval (Linux/KDE/verbinding via USB-kabel) staan de audio notes op de telefoon in mtp:/Moto G (5) Plus/SD card/Android/data/net.osmand.plus/files/avnotes/ en de tracks in mtp:/Moto G (5) Plus/SD card/Android/data/net.osmand.plus/files/tracks/rec/.
Ik kopieer deze naar mijn computer naar een map, bijvoorbeeld /home/tijmen/Hobby/OSM/script/AVnotesTodo/ - dus de audio notes (.3gp-bestanden) en de tracks (.gpx-bestanden) naar dezelfde directory - in mijn geval /home/tijmen/Hobby/OSM/script/AVnotesTodo/

Als je nu een GPX-track opent in JOSM (kan met sleur&pleur) dan zie je alle opgenomen audio nodes in de laag “markers for ”. Als je op zo’n marker klikt dan wordt het audiobestandje afgespeeld.

Als je naar de audiobestandjes kijkt, deze heten allemaal iets als 0E6UELlA–.1.3gp. De “naam” (het 0E6UELlA) is een codering van de locatie, shortcode. Ik heb een script geschreven dat van deze audiobestandjes een gpx-track maakt, zonder daadwerkelijke track maar met alleen deze markers erin, die je dan ook in JOSM kan zetten.

Hoe dat te doen heb ik bescrheven in deze post, ik zal binnenkort, als ik tijd heb, daar een deugdelijker blogpost van maken en proberen het geheel in één perl-bestand te frutten, zodat het ook voor windows-gebruikers werkbaar is. Ik ben daar echter geen held in, dus als iemand daar goed in is hou ik me aanbevolen!

Ik gebruik een Columbus V-990 voor verkenningen, die kan ik terwijl ik fiets inspreken en zo in JOSM laden. Je hebt wel een apart apparaat nodig en de audio-kwaliteit is niet geweldig.

Wandelend is die werkwijze van IIVQ ook prima lijkt me.

Wat betreft het script om die audio notes en de track te combineren, misschien is het wel beter om het in een “Columbus” formaat weg te schrijven, dat wordt door JOSM ondersteund en laat zowel de track als afspeelbare audio waypoints zien.

Klinkt allemaal goed voor een mapper met passie, maar ik ga dat een Willekeurige Wandelaar die wel wat wil helpen, niet vragen. En daar is het mij om begonnen: hoe kan je uit die duizenden wandelaars informatie krijgen over de routes en de andere interessantre objecten, in dit geval knooppuntpaaltjes.

Wandeling tracken met een simpele aan/uit tracker, ja, dat lukt met bijna iedereen die bereid is met een mobieltje te wandelen. In 5 jaar dat is dat omgeslagen van bijna niemand naar bijna iedereen.
Van elk paaltje een foto nemen, ja, maar dan moet-ie het met lokatieinformatie aanleveren, en dat blijkt lastig. Maar het helpt mij meer als-ie de node gelijk al in OSM zet met behulp van een simpel zet-pin kaartje. Dan hoef ik niks te koppelen, de track hoeft niks te bevatten, ik loop gewoon de track na in josm en kom vanzelf langs de nieuwe punten, ff mergen met de juiste intersectie en boem!

Ik vind dat een prima samenwerking, ieder doet wat-ie kan en niemand wordt overvraagd. Anders gezegd: je kan dit van veel meer mensen vragen dan dingen met plugins in OsmAnd, laat staan python scripts of speciale apparatuur.

MapComplete maakt dit mogelijk. Er zijn nog wat onvolwassenheden als het gaat om de “gebruikerservaring”, en het opzetten van een MapComplete-thema is, hoe zal ik het zeggen, knutselwerk met vallen en opstaan dus typisch OSM zeg maar, maar het heeft ook een listig voordeel: op elk punt ziet de gebruiker iets en kan-ie iets doen waardoor zhij een stapje dichter bij OSM komt. Dus het kan nieuwe mappers opleveren.

Dat is dus kompleet anders dan bij bv Maproulette, daarvoor moet je een mapper zijn die OSM al snapt. StreetComplete is nog zo’n ïedereen kan het"-tool, maar dat gaat dan bijvoorbeeld om mensen die graag hun eigen buurt heel gedetailleerd in kaart willen brengen. Daar zit dat fuikmechanisme -pardon ik bedoel, het stapsgewijs aanbieden van de gelegenheid om meer betrokken te raken- trouwens ook wel ingebouwd en als toepassing is het veel volwassener.

Zo, ik heb me even kwaad gemaakt, en gister en vandaag ook de oostelijke helft van het Wandelnetwerk Amstelland (onderdeel van Wandelnetwerk Noord-Holland maar ivm de beheersbaarheid apart gezet) in Openstreetmap gegooid. Dit grotendeels op basis van wandelnet.

In het zuidwestelijke puntje had Peter Elderson al wat gedaan, waarvoor dank. Jij had het in Wandelnetwerk Noord-Holland gezet, ik heb dat naar Amstelland verplaatst.

Wat mij wel opvalt is dat het netwerk van Wandelnet niet 100% overeenkomt met die van wandelnetwerknoordhollandnoord.nl (WNNH). Met name aan de noordwestoever van de Amstel tussen zeg maar Nieuwveen (bij node 61) en Uithoorn mist wat - ik heb de nodes 62,36,35, laten staan zoals Peter ze er in gezet had, maar nodes 22 en 23 staan niet op Wandelnet en mag ik ivm zonder toestemmign niet overnemen van WNNH. Peter, als je daar ooit in de buurt bent voor survey, hou ik me aanbevolen.

Helaas nog 9 facts, allen vanwege incomplete routes, maar die zijn ook daadwerkelijk incompleet. 1 is niet in het veld te zien (al zou het hersteld zijn, maar ik mag er pas na broedseizoen lopen), 2 zijn nog niet open ivm werkzaamheden Gaasperdammertunnel, 3 omdat node 69 bij Holendrecht fysiek ontbreekt, 2 omdat de route bij Ouderkerk fysiek onbegaanbaar is ivm brugwerkzaamheden, 1 vanwege werkzaamheden bij station Diemen.

Dan nog een vraag over knooppuntnet: waarom slagen de nodes aan de “verre” kant van een “connection” niet voor de integrety check? Die node moet ik toch juist niet opnemen in mijn routerelatie? Of wel, maar dan met rol connection?

Nog een vraag: ik zit toch nog een beetje met het massieve netwerk Noord-Holland. Dat bestaat volgens WNNH uit 7 regio’s, ik heb 2 (Amstelland en Gooi- & Vechtstreek) eruit gehaald, en de andere er in laten zitten. Dat is natuurlijk een beetje raar. Maar de naamgeving is nu ook wat raar. Zal ik van die eerste twee iets als “Wandelnetwerk Noord-Holland - Amstelland” maken zodat duidelijk is dat het onderdeel is van NH?

Super!
Ik heb kontakt gehad met het routebureau in NoordHolland over verschillen tussen hun planner, de wandelnet planner en de feiten op de grond; Knooppunten met nummer 0 die er helemaal niet zijn, routes die elkaar kruisen zonder knooppunt en routes die niet aansluiten of dubbel zijn en niet willen plannen, etc. Geen woord over OSM gezegd trouwens.
Eerst wilden ze me afschepen met “meld het bij meldpunt routes”, ik hield aan omdat dit de losse melding toch echt te boven gaat. Nu wisten ze te melden dat er op veel plaatsen aangevuld, aangepast en verbeterd wordt, en dat klopt. Daarna wordt alles goed geregistreerd en daarna aangeleverd aan Wandelnet. Mijn lijstje is doorgegeven aan de uitvoerende tak. Dus ergens in 2022 alles op orde moet haalbaar zijn, schat ik in.

Daarnaast heeft een NoordHollander zich gemeld, rjvdboon, ik heb hem met MapComplete op pad laten gaan en nu zit hij al zelf in JOSM te mappen, af en toe wat aanwijzingen en hopla! Die kan natuurlijk niet heel Noord-Holland doen maar alles helpt. Ik loop zelf nu meer in bossen en heuvels, in aanloop naar een tocht door Zwitserland, dus NoordHolland zit er voorlopig niet in.

Als je een connection route hebt van een node in het ene netwerk naar een node in het andere, en je hebt de route in beide netwerken met rol connection staan, dan horen de integrity checks van de nodes te kloppen, of de nodes nou in de routerelaties staan of niet. Hij telt gewoon het aantal routes dat op een knoop landt en dat moet gelijk zijn aan de expected… waarde. Moet ik s kijken? Welke route gaat het om?

PS vmarc is lekker bezig met de issues! Als dat doorgevoerd verdwijnen er een stel feitmeldingen.

Op welke manier / wanneer is dat een probleem?

Ik vind dat ze soms vreemde keuzes maken en idd snel afwimpelen naar meldpuntroutes. Routes die wel op hun kaart staan maar in het veld er niet zijn, routes die gewoon op paaltjes staan terwijl de onderliggende weg nog niet gemaakt is (“zak ze dan even af” zou ik in OV-termen zeggen), lange verbindingsroutes die langs een IC-station gaan (Duivendrecht) en daar geen node (laat staan een startpunt) hebben en gister zag ik dat ze een aantal keer een dubbele route X-Y hebben met dezelfde 2 nodes (bijv 2 routes 52-58 of 84-86). Daarnaast hebben ze de zeer obvious route over de Oranjesluizen in Amsterdam niet aangelegd, wat jammer is, want daarmee (en het ontbreken van Kennemerland) is er nu géén route van ten noorden naar ten zuiden van het Noordzeekanaal - ja een kronkelroute door Kennemerland die er ongetwijfeld in het echt niet is.

Fijn dat je contact hebt en wat constructieve zaken bij ze kan aandragen.
En ergens jammer, dat er dus (minstens) 3 verschillende dataversies bestaan: die van WNNH, van Wandelnet en van OSM/Knooppuntnet, die ongetwijfeld verschillend zijn.

https://knooppuntnet.nl/en/analysis/network/12222574/nodes en dan filteren op integrity check = no. Dit is volgens mij de “lichte” integrety check. Al deze connection nodes zijn dus nodes aan de “verre” kant zitten, waar de dichtbijzijnde kant Amstelland is.
Ik zie hier (N) R C (C) (E), waarbij
(N) = OK - Not defined in network relation
R = OK - Defined in route relation
C = OK - Connection
(C) = OK - No connection role
(E) = OK - expected route count missing
Dus volgens mij zijn alle zaken ok, want de “missende” zaken zijn optioneel
Overigens begrijp ik die laatste niet: Bij bijvoorbeeld punt 12 staat dat de expected_rwn_route_relations ontbreekt (E) maar die staat er gewoon in.

Ik vind het onbeheersbaar. Je hebt een relatie met bijna 4000 items, het hele netwerk met “download all children” binnenhalen duurt ruim 4 minuten.
Als Amstelland (700) en G&V (750) en het toekomstige Kennemerland-Haarlemmermeer (zeg 300) er bij komen zit je op 6000 items in de relatie.
Volgens mij is er een richtlijn dat relaties liever onder de 3000 items moeten blijven.
Overigens is NH niet de worst offender, Frŷslan zit net over de 5000.
Het lijkt me voor de OSM-servers ook minder prettig, voor elke wijziging wordt de hele relatie opnieuw opgeslagen.
Amstelland heb ik afgesplitst omdat dat in ontwikkeling was en G&V toen ook maar omdat dat anders helemaal los hing van de rest van NHN - de andere 4 regio’s hebben minder duidelijke grenzen.

Eigenlijk is Overijssel de worst offender :slight_smile:
Maar die is altijd al in deelnetwerken opgedeeld.
Netwerk Twente heeft ongeveer evenveel members als Fryslân
En dan komen de overige netwerken er nog bij.
Maar goed de deelnetwerken van Overijssel zijn zeer duidelijk in het veld te herkennen, dus een provinciaal netwerk is absoluut niet zinvol.

Je hoeft die hele netwerkrelatie nooit te gebruiken. Voor beheer (binnenhalen) kan je via de admin-hierarchie bijvoorbeeld een gemeente openen, en dan kun je nog kiezen of hij alleen de punten en de relaties binnenhaalt, of ook de leden van de relaties. Je kunt de details, feiten, kaart en wijzigingen ook per gemeente bekijken, dat is goed te overzien.

Zelf ga ik vaak via de planner, met control-klik op een knooppunt of route en dan details en Openen in JOSM. Of wel via de analyse en de feiten, vervolgens vanuit 1 feit naar het element, en daar weer Openen in JOSM.

Hm, s kijken… de eerste is wkp 12, verbonden met 36.
Knooppunt 12 zit in 2 netwerken, namelijk Rijn- en Veenstreek en Utrecht Groene hart. Een knooppunt precies op de grens, dat kan, maar dan moet het in beide netwerken een rol connection hebben. In feite hoort het alleen in Rijn en Veenstreek, dus zonder connection rol.
36 zit in Amstelland.

12-36 zit alleen in Amstelland, rol connection. Maar dan zou die ook in Rijn- en Veenstreek moeten zitten met rol connection. Dit is denk ik waarom de interiteitscheck niet klopt: hij telt deze verbinding niet mee omdat die niet in de netwerkrelatie zit.

11-12 zit alleen in Rijn en Veenstreek, goed.
12-13 zit in Rijn en Veenstreek én Utrecht Groene Hart, beide met rol connection. Goed.

Dus: wkp 12 uit Utrecht Groene Hart weghalen, en 12-36 toevoegen in Rijn en Veenstreek met rol connection, dan zou het goed moeten zijn!

Ik had dat per gemeente nog niet gedaan.
Vmarc: Overigens krijg ik daar foutmeldingen die ik in de “Per Netwerk”-view niet krijg. Bijvoobeeld Amsterdam, relatie 12-13: RouteNotForward There is no path in the forward direction (from start node to end node).
Terwijl die ook onder RouteIncomplete The route is marked as having an incomplete definition. A route definition is explicitely marked incomplete by adding a tag “fixme” with value “incomplete” in the route relation. staat. Ofwel, we weten dat de route incompleet is, en toch geven we aan dat de route incompleet is.

De reden waarom ik een netwerk binnenhaal in JOSM (niet in knooppuntnet) is dat ik het wel handig vind om het netwerk in JOSM te vergelijken met het netwerk wat je ziet op wandelnet.

Beter in 12-13? (experimental.knooppuntnet.nl toont momenteel veranderingen aan de analyse logica die nog in de test fase zijn)

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.