Wandelknooppuntennetwerk Zuidplas komt eraan

Ik denk dat je in de “verkeerde” VMarc kijkt. Je kijkt waarschijnlijk in de nieuwe VMarc en die wordt niet zo vaak bijgewerkt. Ik heb al meer gemerkt dat die achter loopt. En daar staat ie inderdaad nog in.
In de oude VMarc http://old.vmarc.be/nl/overview is ie verdwenen. Die is bij tot 12:00 uur vanmiddag
Aan het nieuwe overzicht kan ik nog niet echt wennen. Ik ben zo gewend aan het oude overzicht

Aha, op die manier. En ik maar denken nieuwer=beter…

Oei, … “nieuwer=beter” is eigenlijk best wel de bedoeling… en dat is min of meer ook wel zo denk ik… behalve wanneer het nieuwe systeem achter knooppuntnet.nl steken laat vallen natuurlijk… zoals hier het geval.

Vanavond, na het lezen van jullie berichten hier in het forum, ben ik gaan kijken wat er aan de hand is. Het blijkt dat de verwerking in het nieuwe systeem een aantal dagen geleden onverwacht gestopt is, op 31 mei 22:01u om precies te zijn.

Te veel detail misschien, maar de logbestanden tonen een probleem met idle-timeouts in de verbinding tussen de analyse logica en de analyse database. Wellicht is er een verband met een recente verandering in release v2.0.6, waarbij play http vervangen werd door akka http. Ik heb nu een aantal timeout parameters aangepast (op ‘infinite’ gezet) en de analyse herstart. Op het moment dat ik dit schrijf is de analyse weer helemaal bijgewerkt.

Route 61-80 is in knooppuntnet.nl nu ook verdwenen uit de lijst van netwerk routes. In de historiek van Route 57-58 is nog te zien dat deze relatie vroeger route 61-80 bevatte (Route naam gewijzigd van “61-80” naar “57-80” in changeset 59450389).

Het nieuwe systeem achter knooppuntnet.nl zou korter op de bal moeten spelen (als het niet stilligt natuurlijk). Het “oude” systeem op old.vmarc.be maakt een volledige her-analyse om de 2 uur. Het nieuwe systeem kijkt voortdurend naar de veranderingen in OpenStreetMap, en verwerkt deze met slechts een beperkte vertraging. Aanpassingen in OpenStreetMap zouden vaak al na een aantal minuten zichtbaar moeten zijn in knooppuntnet.nl, bijvoorbeeld in Netwerk wijzigingen, Overzicht in cijfers, of in de individuele paginas voor netwerken, routes en knooppunten. Een uitzondering hier zijn de nieuwe kaarten zoals de fietskaart en de wandelkaart, en de andere plekken waar die kaarten als achtergrond gebruikt worden. Deze worden momenteel nog om de 2 uur (op de on-even uren) bijgewerkt.

Wanneer issue16 uitgevoerd is, dan zou elke pagina een “Situatie op” tijd moeten weergeven die aangeeft tot op welk tijdstip de analyse is bijgewerkt.

Het is een beetje pijnlijk om er min of meer per ongeluk achter te moeten komen dat de zaak al een paar dagen stilligt; daarom heb ik issue18 aangemaakt om een oplossing te verzinnen waarbij ik bijvoorbeeld automatisch een email zou krijgen wanneer er een probleem is.

Het is eigenlijk de bedoeling om old.vmarc.be nog slechts een beperkte tijd te behouden.

Voor ik old.vmarc.be uitschakel moet het nieuwe systeem wel voldoende stabiel zijn, en zou de functionaliteit in het nieuwe systeem liefst minstens zo goed moeten zijn als in het oude systeem. Ik heb vanavond in github een label must-have-before-vmarc-switch-off aangemaakt om te documenteren wat er zeker nog zou moeten gebeuren voor old.vmarc.be uitgeschakeld wordt. Indien hier zaken ontbreken (tekortkomingen die nog niet gedocumenteerd zijn in github, of bijvoorbeeld pijnpunten die het moeilijk maken om te wennen aan het nieuwe), dan hoor ik het graag in een berichtje via vmarc, of in github of hier in het forum.

fijn om te horen dat het een tijdelijk probleem was en heel voortvarend opgelost.
Ik had geen gewenning, dus bekijk de nieuwe niet als anders dan… . Het ziet er gewoon bruikbaar en logisch genoeg uit. Een goede online relatie-editor erbij zou wel heel handig zijn, maar dat valt denk ik buiten de scope.

Ik gebruik nieuwe vmarc en die is nu goed bij! Alleen als ik op OSM of EDIT klik dan krijg ik een scherm waarin alleen maar OK staat. Klinkt goed, maar niet wat ik verwachtte!
Verder geeft-ie een paar knooppunten (11 en 53) dat er 4 routerelaties zijn, maar ik zie er echt maar 3. Telt-ie een fietsroutes mee of zo?

De overige expected fouten kloppen met hoe het is. Zo lang het netwerk nog aangelegd wordt zijn er iedere dag onaffe zaken. Ik zet de expected bij het invoeren van de node toch al op het uiteindelijk te verwachten aantal, daar is het expected voor lijkt mij, en dan helpt vmarc mij om de missende eindjes te vinden.

Ik ben van plan elke avond het uitrolwerk van die dag gelijk in te voeren. Over een paar dagen beginnen er connections te komen, dat zal wel wat meer gepuzzel worden.

Als je in het nieuwe overzicht bij de knoppen kijkt, zie je bij een 11 2x route 11-53 staan. Dus er zijn wel 3 routes, maar eentje, 11-53, is dubbel opgenomen in de netwerkrelatie, zie je ook bij de netwerkrelatie, 11-53 krijgt een bruin kleurje. 1x 11-53 uit de netwerkrelatie halen.

Aha! Gefikst, bedankt. Helaas is zo’n netwerkrelatie niet sorteerbaar, al was het maar op naam/nummer. Of is het?

Nee, voor zover ik weet niet. Normaal gebruik je de netwerkrelatie ook niet zoveel. Je bergt er nodes en relaties in op en je kijkt er niet meer naar.
Ik selecteer meestal de routerelatie of de node en dan zie je het netwerk waar hij lid van is. Als je dan voor editten kiest, opent het relatievenster precies op die relatie of node.
Dat is ook handig bij lange routes. Eerst de weg selecteren en dan pas de route openen, dan komt hij direct op de goede weg. Anders zoek je je een ongeluk.

Ik ga vandaag de eerste connections doen. Heb ik dit juist:

  • elk knooppunt in zijn eigen netwerk
  • tenzij er meer relaties naar het andere netwerk loopen dan naar het eigen netwerk, dan doen we gewoon alsof hij bij het andere netwerk hoort
  • het traject in beide netwerken opnemen met role:connection
  • de knooppunten niet in de trajectrelatie opnemen (want dan zou je de knooppunten via de trajectrelatie stiekem toch in het andere netwerk zetten)

Hoe zet je de expected-relations? Ik zag er een met 2, dat was inklusief de connection en dan klopt het
Ik zie er ook waar het niet gezet is. Er staat ook ergens in een wikipagina dat je het weg moet laten omdat het niet gaat kloppen of onlogische uitkomsten geeft.

Kijk in ieder geval even naar het issue in VMarc https://github.com/vmarc/knooppuntnet/issues/6
Wat expected betreft, als je de knoop maar in 1 netwerk “hangt” moet het goed gaan. Het knooppunt is alleen maar lid van 1 netwerk en de aangrenzende routes zijn ook allemaal lid van dat ene netwerk. Tot dusver telde VMarc altijd per netwerk.

Dat issue heb ik gezien, maar dat verandert de aanwijzingen toch niet? Anders heb ik het verkeerd begrepen.
Expected kan ik dus gewoon zetten op alle betreffende trajectroutes. Bv. 2 trajecten binnen het netwerk en 1 connection, dan wordt het 3 expected.

Nee, de aanwijzingen veranderen niet. Maar het issue geeft duidelijk aan dat de knopen alleen in het eigen netwerk moeten. Al geeft VMarc daar nu wel een melding op.

Ok ik heb de aanwijzingen op de wiki wandelpagina nog wat aangepast.

Weetje (waarschijnlijk geen nieuws…)
Ik heb waymarkedtrails gevraagd wat zij doen met (de informatie in) netwerkrelaties. Het antwoord is: niets! De netwerkrelaties voor knooppuntnetwerken is voor hun niet bruikbaar voor de weergave, het is een zak vol ongesorteerde routes en punten die niets toevoegt aan de routes (trajektrouterelaties) zelf. Dus zij renderen de stukjes tussen de knooppunten en de knooppunten, en dat is het.

Informatie voor de kaart of de gebruikers moet dus aan de routerelatues en de knooppunten gekoppeld worden, ook al is het altijd dezelfde info namelijk symbol, name, operator, url en dergelijke.

20180618 - Voortgang

  • De uitbreiding van wandelnetwerk Hof ven Delfland is vrijwel klaar, in het veld én in OSM.
  • De vrijwilligers zijn na een oefensessie begonnen om in tweetallen alle knooppunten en routes na te lopen
  • De uitbreiding van wandelnetwerk Gouwe Wiericke is begonnen. Het intekenen op OSM loopt ietsjes voor op de uitvoering in het veld. Eind van de week zal dat ingehaald zijn, Auke is lekker bezig!
  • De connections heb ik voor het laatst bewaard. Er zijn aanpassingen in en er gaan connections tussen vier verschillende netwerken, dus het wordt goed opletten.

Ik probeer om geen zwevende knooppunten achter te laten. Wat op vmarc wel als “feiten” verschijnt, dat is dat expected_rwn_relations afwijkt van het ingetekende aantal. Ik zet die namelijk meteen op wat het volgens het plan zou moeten zijn, dan kan ik aan vmarc zien of ik alle verbindingen gelegd heb.

Over een week zullen die signalen dus verdwenen zijn. Daarna zal ik bevindingen van de vrijwilligers verwerken, ik verwacht daarbij geen belangrijke wijzigingen, hooguit een ander paadje.

20180623 - Klaar!
Alles is volgens plan gegaan. Ik word er best handig in, al zeg ik het zelf, dankzij de nuttige tips natuurlijk.
vmarc (nieuwe versie) is een goede hulp, en ook heel erg bij tegenwoordig! Minutenwerk.

Fouten/feiten buiten ‘mijn’ netwerk heb ik niet aangepakt, die zijn niet in mijn buurt. Mogelijk doe ik dat nog een keer maar nu heb ik andere prioriteiten.

En nu… onderhoud. Wekelijks vmarcen of zo.

Mooi werk Peter, dank!

Ook voor de toetsing/aanscherping van mijn eigen renderingsmethode en de planning van toekomstige uitstapjes:
Klopt het beeld dat ik krijg via
https://www.openkaart.net/wandel/#map=14/51.9960/4.6317 dat:
-er in het gebied maar 1 pad is met een periodieke sluiting, namelijk 42-95, net onder het spoor bij Gouda (nu nog paarse stippels)
-de voornaamste trajecten met echte wandelpaden (geen fietspad of weg met auto’s) liggen rond Moordrecht, Rottemeren en Hitland (gestreepte lijn ipv doorgetrokken lijn)

Ik ga nu zelf aan de slag met het netwerk Leiden/Leiderdorp -dat staat net in het veld.

Daarna Bollenstreek afmaken, maar zag op wandelen123 dat er in Kennemerland ook een nieuw netwerk is, wordt voor mij wat veel/ver

Lekker bezig zo!

42-95 is inderdaad het enige pad met (broedvogel)-sluiting.

Er zijn in Zuidplas helaas vooral veel verharde verbindingen, maar toch hebben we wat toe weten te voegen:
43-44 in Capelle
in Ver Hitland 45-86-51-79 en 51-52
Langs de IJssel grotendeels buitendijks 53-11-30 en 66-60-71-82
Westergouwe 72-73-74
Donk 76-87
Oostpolder 88-14 grasdijk langs de Gouwe
Waddinxveen 36-75 door het Gouwebos
Bentwoud 13-73
Zevenhuizen 50-52 omgelegd naar de graskade aan de andere kant van de Ringvaart
Nieuwerkerk 34-35 via een “bos”; 39-65 graskade langs de Ringvaart; 66-61-44 via kettingpontje en graspad.

We hebben het maximum eruitgesleept en het begrip “aansluiting” een heel end opgerekt! Er waren nog meer onverharde plannen maar dan moesten er bruggen aangelegd worden en boeren omgeko… ik bedoel een passende vergoeding aangeboden worden. Onhaalbare kaart.

In de provincie Noord Holland wordt nu ook wandelnetwerk uitgerold, zo met een snelle blik leek het trekjes van het Overijsselse model te hebben. Ik zag tenminste op StreetView en op de website gekleurde routes.

Goed werk! Weer een groot gat in het wandelnetwerk dicht.