Wandenetwerk Utrecht (stad) en Groene Hart (provincie) samenvoegen?

Communities Nederland (Netherlands)
1

Ik ben het Wandelknooppuntennetwerk Groene Hart in Utrecht aan het aanpassen en uitbreiden, naar aanleiding van veldrapporten van een wandelaar. Het viel me op dat het wandelnetwerkje in Utrecht stad heel klein is, ca 25 knopen en 25 knooppuntverbindingen, en de rest van de provincie zit allemaal in Groene Hart. Op de site van het routebureau spreken ze niet over een netwerk in de stad Utrecht, alleen over de provincie en ze gebruiken de term Groene Hart voor de hele provincie Utrecht. Ze geven geen speciale naam aan het knooppuntennetwerk, en het wordt als 1 geheel beheerd door Routebureau Utrecht.

Ik stel voor om er gewoon 1 netwerk voor de gehele provincie van te maken, met de werknaam Utrecht Groene Hart. Want ik kan van nieuwe knopen en verbindingen toch niet vaststellen of het bij stad, gemeente, regio of provincie Utrecht hoort. Aan de bordjes zie je het ook niet. Voor de toepassingen maakt het niet uit.

Akkoord?

2020-08-29 Samengevoegd.

2

Gewoon doen. Mijn zege heb je. Die kleine gebiedjes zijn niet handig en je zit voortdurend met connection routes te hannessen.
Voor Drenthe, Groningen en Fryslân hebben we ook al één netwerk per provincie.

3

Ik weet niet of het nog altijd relevant is maar de wiki raadt af om relaties te groot te maken:

We zitten in het Groene Hart nu al op 1200+ leden, dus als we heel de provincie Utrecht in een netwerk stoppen, gaan we de 2000 wel halen.
Misschien eerst maar een navraag doen of dit nog altijd relevant is?

4

Fryslân, de grootste, zit momenteel op 2009 routes en 2957 knooppunten en het gaat nog prima

Het Groene Hart is lang niet de groootse van Nederland, dus geen probleem

Punt is dat netwerken alleen maar een verzamelbak zijn, ze worden uiterst zelden compleet ingeladen.

Routerelaties zijn een ander verhaal, die moet je niet te groot maken.

5

Knooppuntnet (vmarc) is de enige toepassing die de netwerkrelaties gebruikt. Ik heb nog nergens gemerkt dat de grootte een probleem is. In Id is de grootte al en probleem als je bovn de 10 leden komt, in JOSM is boven de 300 lastig en boven de 500 onwerkbaar. Maar dat is voor routes. De netwerkrelatie beheer je niet echt, je gooit de elementen erin als het nodig is ; of ze er al in staan zie je aan het kleurtje.

In de volgende versie van Knooppuntnet zijn de netwerkrelaties voor de controle niet persee nodig. Je kan dan via de administratieve hiërarchie een gebied kiezen dat je wil je bekijken/beheren. Bijvoorbeeld een land, een provincie, een gemeente.

Noord-Brabant heeft in OSM een wandelnetwerk per gemeente, terwijl de provincie een routebureau heeft dat geen onderscheid meer maakt. Dat zou enorm veel gedoe schelen als we daar de netwerkrelaties kunnen afschaffen.

Als de release gepubliceeerd is moeten we het daar maar eens over hebben.

6

Hmm… al merk je het niet… knooppuntnet heeft het toch knap lastig met grote netwerken, zoals wandelnetwerk Fryslân.

Achtergrond verhaal:

De manier waarop knooppuntnet de analyse doet van knooppuntnetwerken is uitgedacht in de tijd dat netwerken nog een relatief beperkt aantal knooppunten en routes hadden (zeker in vergelijking met vandaag in ieder geval). De analyselogica wordt steeds voor het complete netwerk uitgevoerd. Bij de minste verandering aan 1 van de nodes of ways of relaties binnen het netwerk wordt het ganse netwerk opnieuw geëvalueerd. Ondermeer voor de analyse van expected_rXn_route_relations heeft het belang om de samenhang van het netwerk te zien. De analyse resultaten worden ook per netwerk bijgehouden in de analysedatabase, zodat ze heel snel getoond kunnen worden op het scherm. Deze “naïeve” methode van per-netwerk analyse heeft heel lang goed gewerkt, en eigenlijk vandaag ook nog wel…

Maar:

Het wandelnetwerk Fryslân heeft nu afgerond 2000 knooppunten en 2950 routes. Het XML bestand met de complete netwerkinformatie telt ongeveer 370000 (driehonderdzeventigduizend!) lijnen en is 25 Megabytes groot. Voor elke changeset met de minste verandering aan het netwerk wordt heel het netwerk (alle knooppunten en alle routes) twee keer opgeladen (situatie vóór de changeset en situatie na toepassen van de changeset).

Elk knooppunt en elke route in het netwerk wordt individueel opnieuw geanalyseerd en vergeleken met de bestaande toestand in de analysedatabase.

Het netwerkanalyseresultaat in JSON (pretty-printed) telt iets meer dan 125000 (hondervijfentwintigduizend!) lijnen.

Het kost wel wat rekenkracht om deze verwerking te doen. Bijvoorbeeld: in changeset 90029509 is gisteren 1 letter weggehaald uit de naam van een weg. De verwerking op de analyseserver heeft 1 minuut en 35 seconden geduurd op een toch best stevige machine.

En:

Als 1 van de laatste (?) stappen in voorbereiding van de nieuwe knooppuntnet versie 3.0 wou ik de software van analyse database naar de meest recente versie brengen (Couchdb 2.3.1 naar 3.1.0). Dat is niet gelukt. Na meerdere dagen onderzoek heb ik moeten vaststellen dat Couchdb 3.1.0 zich verslikt specifiek in netwerk Fryslân. Ergens diep in de databasesoftware doet er zich een timeout voor die de map-reduce verwerking doet crashen. Na verschillende pogingen over de duur van verschillende weken om 3.1.0 toch aan de praat te krijgen heb ik het uiteindelijk moeten opgeven, en alles terug naar 2.3.1 moeten brengen.

Resultaat:

De oorspronkelijk aanpak van de analyse schaalt niet meer zo goed. Netwerk Fryslân houdt momenteel een database software upgrade tegen (niet zo erg, versie 2.3.1 werkt prima). Er kunnen gerust nog meerdere grote netwerken bijkomen, maar als heel Nederland/België/Duitsland in grote netwerken zou worden ondergebracht dan gaat de analyse logica misschien toch niet goed meer kunnen volgen denk ik, als er op een gegeven moment veel opeenvolgende veranderingen zijn. Uiteindelijk zal er toch iets fundamenteels moeten veranderen in knooppuntnet.

Een mogelijke piste is om heel de netwerk gebaseerde analyse te laten vallen in knooppuntnet, en gewoon route per route te verwerken (maar wel met de op administratieve hiërarchie gebaseerde rapportering).

Dat wordt dan wellicht iets voor “knooppuntnet 4.0”.

Inderdaad, eerst maar eens proberen om knooppuntnet 3.0 verder in orde te krijgen (komt dichtbij)…

7

Jammer, vooral zonde van de tijd en de moeite.

8

Ff na zitten denken. Waar het vooral over gaat bij de netwerken is het connection-gebeuren. De routegebruiker heeft daar in de praktijk niets aan.

Voor de integriteit van de netwerken dan? De connectiviteit hangt alleen van de punten en de wegen af.

Het aantal routes per knooppunt ook. Daarvoor is denk ik alleen de state=* tag van belang.

De eis is eigenlijk, de route moet in minstens 1 netwerkrelatie (van dezelfde soort, **n) voorkomen en de knooppunten ook.

Of heeft het connection-zijn nog een ander belang?

9

Sorry :smiley: