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

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 :slight_smile:

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.

Het betreft Bornerbroek https://www.openstreetmap.org/note/1888999#map=19/52.30846/6.65649&layers=N Bij de schapendrift ligt ook nog een knooppunt 67. Echter dat krijg ik er niet in zonder meldingen over overbodige segmenten. Meestal maak ik in zo’n situatie een route van hetzelfde knooppunt naar het zelfde knooppunt, dus 67-67 in dit geval. Zoals altijd wil ik dan de route “rond breien” op de rotonde, maar dat levert overbodige segmenten op. Alleen op te lossen door een deel er tussen uit te halen, maar dat wil ik niet. Ik wil complete en hele routes. Ook geprobeerd bij de Schapendrift een knooppunt 67 neer te leggen en het met de routes 67-68, 67-92 op te lossen, maar niets.

Veel tentakels heb ik al opgeruimd in de afgelopen jaren.
Wat er nog veel over is, zijn mini tentakels. Vaak heb je 2 eenrichting fietspaden en een knooppunt bij een wegkruising. Dan leg ik op beide fietspaden een knooppunt en de routes die op de kruisende weg lopen, krijgen een mini tentakel over de oversteek heen. Dat ziet er ook keurig uit in de route editor.

Bij rotondes en kruisingen hanteer meestal de methode van “rond breien” Ik ga de rotonde of kruising rond met forward/backward zodat de route mooi afgerond wordt in de route editor. De logica ziet dit als tentakels, maar dat zijn het niet echt.
Bij de rotonde of kruising zet ik knooppunten op elke splitsing waar je kunt afslaan. Dat is ook anders dan het oorspronkelijke tentakel model aan geeft. Als ik op zo’n rotonde of kruising aankom, stop ik de route meestal bij het eerste knooppunt en maak de rest als een terugrichting.

Wat een groot probleem is, zijn knooppunten, die samengesteld zijn uit een kruising of rotonde en dan nog een stuk tweerichting met het volgende splitsing(en) van hetzelfde knooppunt. Zie bijv. 67 in Bornerbroek.

Verdeelde knooppunten, met een of meer gewone wegen ertussen geef ik meestal een knoop-knoop route, waarbij beide knopen hetzelfde nummer hebben.
Dit heeft het voordeel dat er dan geen dikke bundel routes met forward/backward meer over een aantal wegen loopt. Je hoeft dan nog maar één route te herstellen en geen 4 of soms 5.
Bovendien is vaak zeer moeilijk vast te stellen of het forward of backward moet zijn omdat de tekenrichting van de weg niet altijd zichtbaar is als je stijlen gebruikt, bijv. voor snelheid.
Verder is het tentakelmodel ook er lastig als de samengestelde knoop uit 3 of meer splitspunten bestaat. Dan moet je dus routes van/naar dat splitspunt maken en dat ziet er niet uit in de route editor en is ook nauwelijks te onderhouden.
Ik heb laatst in Losser knooppunt 13 dat ik ooit nog exact volgens het handboek tentakels had gemaakt vervangen door een 13-13 route

Verder strekken sommige van deze verdeelde knooppunten zich uit over grotere lengtes.
Voorbeelden zijn bijv. knooppunt 51 in Almelo over 750 meter met 3 splitspunten en 82 in Almelo met 3 splitspunten en in Enschede 60. Dat los je elegant op met een route 51-51 en 82-82 en 60-60. De bewegwijzering binnen deze knooppunten is ook met knooppuntbordjes.

Mooi! Dit was een groot gemis, want waarom zouden anders al die knooppuntroutes invoeren?
Wat wordt in vergelijking met bestaande knooppuntplanners het unieke voordeel van deze?

Eén grote lange lijst wordt wel een beetje veel… Is het mogelijk om een indeling naar provincie / gemeente te doen? Of alleen wat binnen het gekozen kaartdeel valt? In ieder geval iets wat je gewoon uit de knooppunten/knooppuntverbinden kan afleiden, zonder expliciet een kenmerk toe te moeten voegen?

O wacht, dat gaat eigenlijk alleen over fietsknooppunten toch? Met verdubbelde knooppunten? Vond ik destijds lastig te begrijpen.

Nou het gaat eigenlijk over alle knooppuntsoorten, dus ook wandelroutes.
Maar zeker bij wandelroutes is een knoop-knoop route veel simpeler en robuuster

Het idee is niet zo moeilijk, alleen de praktische uitwerking is lastig.
Het idee is, dat als je op het eerste splitspunt van het verdeelde knooppunt aan komt, jouw route ophoudt en de route naar het volgende knooppunt begint. Je wordt dan over het verdeelde knooppunt geleid met een route in forward/backward, die pas na het laatste splitspunt van het verdeelde knooppunt “normaal” wordt. En zo hebben alle routes dus een enkelvoudige uitloper over het knooppunt heen.
Lastig wordt het vooral als je 3 of meer splitspunten hebt, de route vanaf een splitspunt er tussenin krijgt dan 2 forward/backward takken. Iets wat de route editor in JOSM niet aan kan.
Verder krijg je dus bundels forward/backward routes wat lastig te onderhouden is.

Over netwerken moeten we nog wat langer nadenken wat voor en tegen is.
Ik heb ook al zitten denken aan een tag network:name in routes en knopen. Dan kun je nog steeds groeperen.

Maar nu heb je relaties met soms een paar duizend members, waar je eigenlijk niet veel mee kunt.
Verder zijn ook diverse netwerken er eigenlijk niet meer. Bijv in Limburg heb je Zuid Limburg en Noord- en Midden Limburg.
Als je in OSM kijkt, zie je veel meer netwerken.

Okee, ik ben er! En daar zou je vanaf willen? Hoe doe je het dan?