Wie kan er wat met Shapefiles (Wandelknooppuntennetwerk Noord-Brabant)

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

• een route moet altijd van een laag knooppunt naar een hoog knooppunt lopen. Waarom? Ik besteed heel veel tijd aan het weer omdraaien en nog eens omdraaien vanwege deze eis. Waarom moet een route van 10 naar 12 lopen en waarom is 12 naar 10 fout?
• het tentakel gedoe. Onmiddelijk afschaffen. Nutteloos. Laat routes gewoon netjes over kruispunten en rotondes lopen en daarmee klaar.

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?

• Nodes met een tag, die aangeeft dat het een knooppunt is.
• Routes, die, om reden van hanteerbaarheid van een knooppunt naar een knooppunt lopen en die alle wegsegmenten “bedekken” waar het knooppuntnetwerk overheen loopt.

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.

Daar heb ik het toch totaal niet over gehad?
En ik heb toch aangegeven dat routes compleet en goed moeten zijn?

Natuurlijlk moeten er foutcontroles zijn. Ik heb nergens gezegd dat die weg moeten.
In ieder geval moeten gaten in routes gedetecteerd worden. En eigenlijk niet alleen in knooppuntroutes, maar ook andere routes.
Ik ben de laatste tijd in Duitsland aan het werk geweest en als daar de diverse routes ziet, is het om te huilen. Heel veel gaten en repareren is een bijna onbegonnen klus.
Ook blijft de volgorde belangrijk, zeker bij forward/backward, dus ook dat controleren.
Maar of een route van hoog naar laag of van laag naar hoog loopt, is niet spannend.
Om de routes niet onhandelbaar te maken, kun je het beste routes van knoop naar knoop maken, dus ook controle op overbodige segmenten, dus of je over de knoop heen gaat, of dat ergens onderweg een weg niet doorgeknipt is
Of een route tot aan zijn knopen loopt is ook belangrijk, er wordt nog wel eens een stukje vergeten
Ook de controle op toegankelijkheid is belangrijk. Er wordt nu gecontroleerd of er geen bicycle=no of use_sidepath in de route voorkomt en bij rwn op foot=no
Ook de controle of alle routedelen een highway= tag hebben, is nuttig

Maar vooral dat checken volgens het tentakelmodel moet er naar mijn idee uit.

helemaal eens dus! Ik heb de duitse E8 onderhanden gehad, dat was nog niet eens zo heel slecht (redelijk kompleet) maar het totaal had toch flink wat onderhoud nodig. Nu waarschijnlijk weer, ik zal eens kijken.

Dat zegt mij niet zoveel.

Mee eens.

De controles in knooppuntnet zijn oorspronkelijk gebaseerd op de suggesties in de OSM wiki over hoe knooppuntnetwerken gemapped kunnen worden. Als hier zaken bij zijn die niet meer relevant blijken, of die eerder tegenwerken dan helpen, dan wil ik daar zeker aanpassingen voor doen.

Een eerste aanpassing ga ik direct aanpakken: Issue: Remove RouteReversed rule.

Het laten vallen van het concept “netwerk” in knooppuntnet zou een grote verandering zijn, maar zeker ook een flinke vereenvoudiging van de analyse logica. Route wezen zouden niet meer bestaan. Er hoeft niet meer gekeken te worden naar verbindingen tussen netwerken. De logica rond expected_rcn_route_relations zal dan wel vereenvoudigd moeten worden ten opzichte van de beschrijving in de wiki (niet langer geweten of knooppunten binnen hetzelfde netwerk liggen).

Maar: zonder netwerk informatie worden wijzigingen niet meer gerapporteerd met vermelding van het netwerk waar de wijzigingen binnen vallen, ook niet in de detail pagina van een wijzigingenset. Dit maakt het denk ik wel moeilijker om te zien waar een bepaalde wijziging gebeurd is.

Is er iemand die het concept “netwerk” in knooppuntnet zou missen?

Er is een knooppuntnet route planner in opbouw, gebaseerd op de knooppuntdata in OpenStreetMap.

Je kan hier al eens een blik werpen op het “work-in-progress”.

Deze is in voorbereiding voor versie 3.0.0 (gebaseerd op survey:date).

Ok, als hier een vereenvoudiging mogelijk is, wil ik dit graag doen. Het lijkt me misschien wel nodig dat “tentakels” geinterpreteerd kunnen worden zolang ze er zijn in de OSM data?

Dick, kun je een link geven naar een route waar ik dit probeem kan zien?

Lijkt me een interessante oefening.