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

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?

Zie hierboven post #29

Indeling naar provincie/gemeente: prima idee!!
Dat ga ik eens verder bekijken.

Ok dat is spaghetti voor mij! Het ligt ongetwijfeld aan mij, maar ik kan er in mijn hoofd geen model of stappenlijstje van maken. Ik ga er dan maar vanuit dat slimmere mensen het kunnen begrijpen en in de tools verwerken! :slight_smile:

In dit draadje https://forum.openstreetmap.org/viewtopic.php?id=54379&p=2 post #29 heb ik een uitleg gegeven met een plaatje voor het rwn netwerk.
Maar jouw reactie bevestigt mijn mening. Zo’n model moet je niet willen. Als je een enorme lap tekst nodig hebt om de basissituatie uit te leggen, dan is er iets mis.
In de wiki staat nog een uitleg van een tentakelmodel bij Bemmel en dat heb ik nog nooit kunnen volgen.

Ook hier geldt het KISS principe :slight_smile:

Voor wandelen is het zelden moeilijk. Het zou moeilijker worden als de wandelknooppunten in osm preciezer waren wb voetpad, fietspad, rijweg, weghelft. Nu is dat niet het geval, je neemt de eigenlijk de knoop die het dichtstbij is en de aansluitingen van de nodige ways heeft. Als er op een kruispunt voor het gemak van de wandelaar nog meer paaltjes met hetzelfde nummer staan, laat je die gewoon weg, want je mapt de aansluitingen, niet de paaltjes zelf.

Het enige wat ik soms niet kan vermijden is dat twee aansluitingen een klein stukje hetzelfde pad volgen. Dat stukje staat dan in twee relaties. Ik weet niet of dat een “feit” oplevert, maar ik zie er in de praktijk geen probleem in. Wat mij betreft mag het wel gedetekteert worden als “mogelijk een probleem” maar geen rode vlag.

Over dat soort feiten had ik het idee dat je misschien in knooppuntnet een vinkje zou kunnen zetten dat het in dit geval klopt?

Die overlappen zijn niet te vermijden en worden in knooppuntnet niet gemeld, gelukkig maar.
Bij het rcn heb je ze ook, in sommige netwerken over kilometers, bijv. in Limburg en Brabant.
En bij de oosterburen is het zeer gebruikelijk. Daar staan lang niet overal knooppunten, er zijn ook veel punten waar het knooppuntnetwerk splitst, maar geen knooppunt staat. Dat is daar geen probleem door de andere manier van bewegwijzeren. Bij een knooppunt wordt dan naar 2 knooppunten verwezen en ergens onderweg splitsen de routes.

Ah op die manier, dan zijn het dus eerder mikpunten dan knooppunten :slight_smile:

Inmiddels heb ik op verzoek van een Brabander het wandelknooppuntnetwerk rond Veghel (Meierijstad) ingevoerd. Ik zag dat er ook alweer kleine verbeteringen aangebracht zijn, foutjes van mij verbeterd, bedankt daarvoor! Daarna heb ik gezorgd dat knooppuntnet.nl geen fouten/feiten meer geeft. Top-tool!
Dus ik heb netjes alle netwerkrelaties en connecties bijgewerkt, de volgorde aangehouden en zo.
Knooppunten in de relatie opnemen en expected zetten heb ik vrijwel nergens gedaan, de meeste omringende netwerken hadden dat ook niet (alleen Uden wel, dacht ik).

Ik heb ingevoerd tot en met de connections, dus ik heb niet alle aangrenzende netwerkjes aangevuld. In totaal is Brabant nog lang niet klaar!

Het tijdrovendste en foutgevoeligste deel van het werk is het gedoe met verschillende netwerken en met connections. Sorteren/omdraaien van losse knoop-knoopverbindingen is in JOSM geen enkel probleem.

Ik ben eens dat het Tentakel model te ingewikkeld is voor wat nodig is.

Wat betreft afschaffen van de netwerkrelatie zie is als voordeel makkelijker beheer maar qua data model, vindt ik dat een netwerkrelatie precies klopt.

De alternatieven om in de routes en een knooppunten een tag op te nemen met de naam van het netwerk vindt ik niet kloppen (je krijgt geheid spellingverschillen en te veel redundantie vind ik), als het toch moet dan wat mij betreft werken met een boundary, alle knoppunten en routes binnen die boundary zijn onderdeel van het netwerk, routes die over de boundary gaan zijn connecties, maar zogezegd niet mijn voorkeur.

De naam van het netwerk in de elementen opnemen zou ik mordicus tegen zijn. Veel werk en foutgevoelig is één reden, maar vooral dat je aan de knooppunten en routepijltjes helemaal niet ziet welk netwerk het is. Bij voorkeur hou je het zo simpel dat een individuele mapper die iets tegenkomt het er gewoon in kan zetten zonder zoektochten naar externe informatie.

Bij wandelknooppuntnetwerken is het zo dat de netwerken allemaal aan elkaar groeien en ook in steeds grotere clusters beheerd worden waarbij de oorspronkelijke begrenzingen en namen veranderen. Op de weg zie je daar vrijwel nooit iets van, hooguit op de informatieborden die af en toe lukraak her en der staan. Voor de wandelaars is er 1 meldpunt: Meldpunt Wandelen van Wandelnet.

Bekende renderers doen niets met de netwerkrelatie. Voor hen is het een onwerkbare zak met routetjes en nodes die ze op grond van de routetags en nodetags toch al kunnen weergeven, dus de netwerkrelatie voegt niets toe.

**Routers **kunnen ook met de routes zelf werken. Als je kan zien dat het knooppuntenroutes zijn, kan je ze in een routeerpofiel zwaarder gewicht geven. Zo bereik je dat plannen van A naar B met een profiel bv. KnooppuntWandelen, vooral of knooppuntroutes gekozen worden.

Planners waarbij je zelf de knooppunten aanwijst waar je langswil, daar heb ik nog minder verstand van. Ik zie er veel, maar die gebruiken op de OSM-ondergrond een eigen knooppunten/routedatabase met een planningsapplikatie. Misschien dat een echte OSM-knooppuntenplanner een netwerkrelatie kan gebruiken? Of misschien is dit hetzelfde als routeren: je geeft aan dat je wil knooppuntrouteren (Profiel), dan klik je een reeks kaartlokaties aan (al dan niet knooppunten) en vervolgens routeert hij je van Start naar Eind via de aangeklikte punten met voorkeur (hoog gewicht) voor knooppuntroutes. Dan is het wel fijn als hij de knooppunten vervolgens opsomt in de aanwijzingenlijst en eventueel de stembegeleiding als je ermee navigeert, maar ook daar heb je de netwerkrelatie niet voor nodig.

Blijft over: beheer en controle lees: knooppuntnet (vmarc) en JOSM.
Het is natuurlijk gemakkelijk als je een indeling in losse netwerken hebt, maar dan moet dat wel enigszins stabiel blijven en op de werkelijkheid gebaseerd zijn. Zoals het nu is, bij wandelknooppuntnetwerken, is het heel vaak niet meer konform de realiteit op de weg, en het verandert ook nog voortdurend en zonder dat het zichtbaar is, niet bij te houden dus!

Kortom, als we voor beheer en controle toekunnen met een administratieve indeling die uit de lokatie en OSM af te leiden is, dan vind ik dat al bij al een veel betere oplossing. In OSM heb je dan geen netwerknaam, maar in toepassingen kan je de naam van het administratieve gebied (zal bij ons wel gemeente zijn, voor wandelen) gebruiken: het Wandelknooppuntennetwerk van Krimpenerwaard bevat alle knooppunten en knooppuntroutes in het grondgebied van de gemeente Krimpenerwaard. Grensoverschrijdende routes neem je gewoon in beide selecties op. Oftewel, je kan instant een netwerkrelatie maken voor zolang als je hem nodig hebt.

Het hele connection gedoe verdwijnt dan. De dubbele vastlegging dat een route of knooppunt een netwerkelement is (namelijk in de tags én in de netwerkrelatie) verdwijnt ook. Daar hoef je dan ook niet meer op te kontroleren. Je kan nog wel andere kontroles doen, bijvoorbeeld: waar twee knooppuntroutes samenkomen zou een knooppunt moeten zijn (en dus minimaal getagd moeten zijn met…). Een knooppuntroute hoort te beginnen en eindigen met een knooppunt. Een knooppunt zou als eindpunt aan minstens 1 knooppuntroute moeten zitten. Etc.

Als je bij zo’n administratief “netwerk” in knooppuntnet ook nog die handige “Edit met JOSM” knop hebt, kan je een gemeentegebied ook in één keer in JOSM binnenhalen voor onderhoud.

Waarschijnlijk zijn er ook nadelen of kunnen er dingen niet die mij mogelijk lijken? Ik hoor het graag!