Ik heb QGIS opgehaald en gekeken wat ik er direkt vanuit de GUI mee kan. Leuke dingen allemaal maar ik schiet er voor dit doel niet veel mee op. Wel als ik zou kunnen programmeren, dan kan ik shapefiles als laag openen en zo. Maar dan heb ik nog steeds geen matching.
Het komt dus toch neer op handwerk, met de knooppuntenlaag als visueel hulpmiddel. Vergelijkbaar met routes maken langs een gpx.
Uiteindelijk is de eenvoudigste methode: in de planner van VisitBrabant https://www.visitbrabant.com/nl/routes/wandelen#maak-je-eigen-route-met-de-routeplanner een route maken langs een serie knooppunten in een gebied waar je wat wil kontroleren of toevoegen, en die downloaden als gpx.
Dat opent prima in JOSM en toont zowel knooppunten als track. Met downloaden langs de track krijg je precies de osm-data die je nodig hebt.
Alleen de netwerkindeling heb je dan niet. Volgens Visitbrabant gaat het per gemeente, maar in OSM staat dan bijvoorbeeld “Brabantse Wal”. Bij Visitbrabant kan je ook niet zien welk knooppunt in welk deelnetwerk hoort. Ik vraag me af of het uberhaupt nog zin heeft om het in deelnetwerken onder te verdelen.
Ik zou de tussenstukjes zeker niet automatiseren. In de praktijk blijken namelijk veel paden nog niet te zijn ingetekend op OSM. Binnen routenetwerk Twente komt het zelden voor dat ik een rondwandeling volledig kan mappen op de bestaande wegen. Vrijwel altijd moet ik nog ergens een pad, weggetje of verbinding op een kruispunt intekenen. Ik zou dus ZEER terughoudend zijn met dit soort mass-imports. Ook merk ik vaak dat de routes net iets anders lopen dan hoe ze op de plattegronden die je onderweg af en toe tegenkomt zijn ingetekend. Dus ook zo’n officieel lijkende bron zal afwijkingen bevatten t.o.v. de werkelijkheid.
Het heeft niet veel zin, maar om nu nog te veranderen, is ook een heel lastig en tijdrovend issue.
Je kunt knooppuntnet.nl gebruiken. Die maakt kaartjes voor alle netwerken en daarmee kun je zien in welk netwerk je zit. Ook de al bestaande knooppunten en routes geven houvast en verder is het een beetje pionieren.
Een grote op knooppuntnet is “Brabantse Wal”. Dat bestaat op Visitbrabant niet. Historie van een paar netwerktrajekten zijn alweer 5 jaar geleden., zo te zien gemaakt rond de eerste invoering.
Visitbrabant geeft een gemeentenaam aan waar het paaltje in staat. Volgens mij heeft dat alleen maar te maken met de administratieve inbedding, want voor alle praktische doelen is het routebureau zelf de beheerder.
ff bedenken: De hele boel 1 netwerk maken is niet moeilijk te doen. Alles in één grote relatie dumpen, dubbelen verwijderen (de connections). De connections naar ander netwerken buiten brabant blijven bestaan. Het ding wordt wat groot, maar per saldo wodt het geheel eenvoudiger denk ik.
Inmiddels is in OSM heel Brabant ingedeeld in gemeentenetwerken. Brabantse Wal is een soort dubbelgetagd netwerk dat eroverheen ligt. Daarom zou ik gewoon de gemeentegrenzen aanhouden, wat ook handig is aangezien die in OSM staan.
Er is destijds niet voor één grote relatie gekozen, omdat OSM niet goed met grote relaties van +/- 2000 leden om kan gaan. Het zou wel het beste overeenkomen met de werkelijkheid, maar OSM kan het eigenlijk niet aan.
Op de paaltjes die ik rond Bergen op Zoom gefotografeerd heb, zit bovenaan een plaatje met de tekst “regio West-Brabant”. Ook bij nieuwe paaltjes die dit jaar zijn toegevoegd is dit het geval. Ook het enige informatiebord dat ik ooit op de foto heb gezet, heeft bovenaan de tekst “Wandelroutenetwerk West-Brabant”. Als we ons aan de regel “Map what’s on the ground” willen houden, is dat een juiste naam. Bergen op Zoom, Noord-Brabant of Brabantse Wal is in het veld niet terug te vinden bij de wandelknooppunten.
Ik heb wel een plattegrond uit 2012 met het “Wandelroutenetwerk Brabantse Wal”, uitgegeven door Regio West-Brabant, maar dat lijkt mij geen geschikte bron.
Ik weet niet hoe ver West-Brabant zich in dit geval uitstrekt, maar ik neem aan dat je makkelijk over de 2000 leden heen gaat, dus dan is indelen naar gemeente de beste oplossing naar mijn idee. Eventueel kunnen er nog superrelaties voor West-Brabant en andere regio gemaakt worden, maar het nut daarvan lijkt mij niet groot. Het netwerk Brabantse Wal kan mijns inziens gewist worden. En dan maar hopen dat herindeling van gemeentes voorlopig niet aan de orde is in Noord-Brabant.
Aha, goed om te weten. Tegelijk ben ik dan klaar, want ik ben niet van plan om tientallen netwerken aan te maken en te koppelen. Ik bemoeide me er alleen maar mee omdat ik veldrapportenkrijg van iemand die het Zuiderwaterliniepad loopt. Het loopt in principe geheel via knooppunten, dus ik bouw het op uit de opeenvolgende knooppunttrajekten. Knooppunten en knooppunttrajekten die ontbreken voer ik om die reden in.
Van een andere brabander kreeg ik vervolgens de vraag waarom osm zijn knooppunten niet gewoon automatisch ontleent aan de officiele bron: het routebureau. Ik weet nu waarom: zelfs als je de bronbestanden hebt en een hanteerbare omzetting zou kunnen maken, gaat het niet op een handige manier lukken. Onder meer wegens andere indelingen, andere historie, andere technische opbouw, bestaande gegevens.
Dus het is aan mappers ter plekke die een binding hebben met het gebied, om dit uit te breiden en bij te houden. Daarbij lijkt me de website van visitbrabant wel een goed hulpmiddel. Tijdens het stoeien heb ik een hoop verschillen gezien, maar zonder veldwerk heb ik onvoldoende verificatie om ze door te voeren.
IK neem mij daarentegen wel voor om ZuidHolland integraal aan te pakken, op het moment dat het routebureau Zuidholland daadwerkelijk de touwtjes in handen neemt. Wat ik in ieder geval ga proberen is een afspraak dat er een attendering komt van alle mutaties zodra die aangebracht zijn. Moeten ze voor de diverse planners tenslotte ook doorgeven.
Ik heb ook een deel van een tabel gezien bij Visitbrabant van alle gemeenten + de regio waar ze onder vallen. West-Brabant was er een van. Als ik erom vraag krijg ik die tabel wel van hun. Maar zoals gezegd, ik neem hier niet het voortouw. Als iemand het doet en daarbij handjes of info nodig heeft, prima dan doe ik mee.
Die netwerkrelaties per gemeente bestaan al. Op de Wandelwiki staan ze in één tabel.
Aha, Visitbrabant gebruikt niet de gemeenten maar de woonplaatsen/woonkernen. Zij voegen ze niet samen tot gemeenten maar tot subregio’s west, noord etc. Dat maakt het er als bron niet makkelijker op. Gemeente en woonplaats staan niet op de paaltjes, dat helpt ook niet. Gemeenten, dat zijn er zo’n 60, subregio’s hebben ze er 5 of 6 van dacht ik.
Het blijft raar aandoen om iets in te voeren wat op de weg niet meer te vinden is. Een afslag-gemist-gevoel.
Ik had iemand beloofd een stuk rond Veghel in te vullen, ik ben daarmee begonnen en zal het om te beginnen toe gaan voegen aan het knooppuntnetwerk Meijerijstad ipv Veghel wat daaronder valt. Op zich kan je de gemeentegrenzen wel goed zien, dus de connectietrajekten zouden goed moeten gaan.
Voegen we nog steeds de knooppunten zelf zowel aan de trajekten als aan de netwerkrelatie toe? Een knooppunt met 4 relaties staat dan in feite 9x in het netwerk, namelijk 1x zelf, 4x als lid van 4 trajektrelaties, en 4x omdat het punt ook altijd in de eerste of laatste way van de trajektrelatie staat.
Dat laatste punt, mag je zelf weten. Knooppunten hoef je niet aan de relatie toe te voegen. Alleen zijn er diverse mappers, die het persé willen, met name bij de wandelnetwerken.
Nodig is het niet omdat de knopen via de way’s al deel uitmaken van de route.
Onhandig is het ook, omdat die losse node’s nogal eens gaan zwerven in de route en knooppuntnet dan denkt dat er een volgorde probleem is. En ook bij aanpassen van de routes is het niet handig.
Ik vond het handig toen ik net begon en een heel netwerk mijn eentje zat in te voeren. Nu doe ik nieuw spul in Veghel en kan ik mij niet herinneren wat daar zo handig aan was! Dus ik laat ze in ieder geval weg uit de trajektrelaties. Als ze in de netwerkrelatie ook niet hoeven (voor knooppuntnet) dan laat ik ze daar ook weg.
Voor waymarkedtrails maakt het niks uit, die rendert alleen de afzonderlijke trajekten en apart de knooppunten. De netwerkrelatie wordt niet gebruikt. Knooppuntrouters voor osm zijn er dacht ik niet, maar ook voor knooppuntrouteren is volgens mij de netwerkrelatie niet nodig.
netwerkrelatie moeten ze wel in. Anders meldt knooppuntnet zich wel bij deze categorie OntbrekendKnooppuntLid
Dat zie ik, maar als het verder geen nut heeft dan heeft zo’n check ook geen nut! Dan is het een typisch geval van “Nou en?”.
Anders gezegd, als alleen de checker er een probleem mee heeft, check dan niet! Ik krijg een beetje het gevoel dat er mooie dingen bedacht zijn die in de praktijk niet gebeuren.
Of zie ik dat verkeerd?
De knooppunten horen in een netwerk. De routes horen ofwel in één netwerk, ofwel in twee netwerken als het een connection is. Zo is de structuur ook opgezet en wordt het in de OSM-praktijk in Nederland ook toegepast.
Weet ik, maar het lijkt alleen een mappers/controleding te zijn en ik vraag me af of het aan de gebruikerskant ook ergens goed voor is. Waymarkedtrails gebruikt de netwerkrelatie helemaal niet, OsmAnd ook niet, en alle knooppuntplanners hebben hun eigen netwerksysteem.
Ik ben het me je eens Peter.
Het argument van zo is het en zo doen we het en zo hebben we het altijd gedaan bevalt me niet. Als je dat volgt liepen we nu nog met een knots rond 
Na meerdere jaren intensief met het knooppuntnetwerk bezig te zijn geweest, begin ik me ook steeds meer af te vragen waar we me bezig zijn. Ik steek heel veel tijd in het repareren van fouten, waar ik me afvraag hoe fout is dit nu eigenlijk?
Veel zaken rondom het knooppuntnetwerk zijn - naar mijn idee - gebaseerd op dromen. Dromen van een eigen navigator. Maar het resultaat is dat er een systeem opgetuigd is, dat voor een hoop mensen niet meer te begrijpen is en dat ervaren mensen soms tot wanhoop drijft omdat er een controlesysteem is dat allerlei regels heeft waaraan je coute que coute moet voldoen. Ik doel hiermee vooral op het tentakelsysteem, dat totaal ondoorgrondelijk is en nauwelijks te begrijpen. Waarschijnlijk gebaseerd op de droom van een eigen navigator.
Even een voorbeeld. Ik leg een route keurig over een rotonde, die een knooppunt is. Vervolgens begint knooppuntnet.nl foutmeldingen te produceren dat er overbodige segmenten zijn. Gewoon omdat dat tentakelmodel dat vindt.
Op dit moment kan ik een situatie in Bornerbroek niet goed intekenen omdat ik overbodige segmenten produceer. Ja, ik kan het er wel in krijgen, maar dan niet op een nette manier met mooi afgeronde routes.
Wat er volgens mij nodig is in OSM voor de huidige afnemers is een vrij basic model:
Simpel er horen routes op de wegen te lopen en op de juiste plekken hoort een knoopunt te staan. That’s it
En om het netjes te houden in de relatie editor werk je op eenrichting stukken keurig met forward/backward
Maar netwerken zijn in feite niet nodig.
Er is een Duitse mapper, die ook fel ageert tegen onder andere netwerken. Volgens hem is het een categorie.
Netwerken kunnen wel handig zijn om een aantal gegevens, die voor alle routes gelden, op één plaats te bewaren
Maar een aantal zaken zijn in mijn idee gewoon overbodig zoals
Even een uitstapje naar de buren, de Fietsersbond.
Die hebben het een stuk makkelijker, het fkp is daar een kenmerk van de weg. En verder worden daar de wegen in tweeën gedeeld, zodat je fkp keurig op de juiste weghelft kunt leggen.
Wat knooppunten betreft, is er een kenmerk van de knoop, is fietsknooppunt. En die moet ja staan voor elk splitspunt. Voor de knooppuntnummers is er een POI met een bereik van 1 km. Elk knooppunt met fietsknooppunt=ja binnen 1 km van die POI krijgt dat nummer.
Wel is het zo dat bij FB het verwijderen van een route een hele klus is en bij OSM is het een fluitje van een cent.
Omgekeerd ben je bij inleggen bij FB veel sneller klaar dan bij OSM
Maar dit geeft voor mij aan wat in feite essentieel is. Dat die weggedeeltes waar knooppuntnetwerk overheen loopt in een route worden opgenomen. Je kunt dat ook aan bijv. Waymarked Trails en OFM zien, die wegen krijgen een bepaald kleurtje. En dat is genoeg.
Wij kunnen het knooppuntnetwerk nu eenmaal niet in een tag van de weg opnemen, dus moeten we routes maken.
En die routes moeten gewoon netjes op volgorde liggen, dat is wel belangrijk omdat je anders door de gaten niet meer ziet hoe het moet lopen.
Dus samenvattend, wat is nodig?
Al het andere is ballast, franje en werkverschaffing
+1
Niet helemaal mee eens. Het is in OSM erg belangrijk om een goede foutdetectie en kwaliteitsborging te hebben. Liefst ook een automatische verouderingsdetectie. Anders holt het achteruit. Dus knooppuntnet vind ik heel belangrijk. Dat je dan wat afspraken maakt en kenmerken gebruikt om dat te laten werken is prima, zolang het óók een daadwerkelijke functie heeft.
Misschien zouden we eens op een rijtje moeten zetten welke kontroles echt zo’n nuttige funktie hebben. MI kan het eenvoudiger en daardoor effektiever.
Bijvoorbeeld de kontrole op verwacht aantal relaties. Dat moet je zelf taggen, en als het niet klopt volgt een “feit”. In de praktijk doen sommigen het wel en sommigen niet, en wie het wel doet zet de waarde vaak gewoon op het aantal relaties wat er op dat moment is. Mij lijkt het voldoende als het punt in de checker opvalt als er twee of minder relaties aan vast zitten, en dat je dan bij 1 of 2 kan aangeven als het echt zo hoort.