Wandelknooppuntennetwerk Zuidplas komt eraan

Heb je de mouse-over in het relatiewindow al ontdekt? Als je in een relatiewindow, de muis even op een object houdt, dat kan een node of een way zijn, toont hij in een mouse-over de ingevulde tags.

Je hebt niets vernield, alleen wat zaken, die ik net lid gemaakt had, weer verwijderd uit de relatie verwijderd.
Werk gewoon in je eigen volgorde, tempo, etc.

Maar wat ik graag wil, is VMarc zo schoon mogelijk houden. Dat is ook in mijn eigen belang. Ik vergeet nog wel eens een route lid te maken van het netwerk en als de lijst routewezen heel lang is, wordt het lastig zoeken. Ik weet nu dat we standaard in de oude VMarc 5 routewezen hebben. Als het aantal hoger wordt, wordt het dus tijd om te gaan kijken.

Welke conflicten ben je tegen gekomen en waar? VMarc? of de JOSM validator? Van die laatste moet je je niets aantrekken. Die baselt voortdurend rare dingen. Degene die die templates heeft samengesteld heeft geen idee van knooppuntennetwerk, zoveel is mij wel duidelijk.
Of heb je JOSM conflicten gehad?
Die kun je beter vermijden.

Wat een groot probleem is met het relatiewindow, dat het geen direct contact heeft met de JOSM omgeving. Dus als je bezig bent met een route in te leggen en je hebt een weg opgenomen in de relatie en die moet nog worden doorgeknipt en je knipt hem zo door, dan krijg je beng een melding met als een mogelijkheid create a conflict. Dat nooit doen. In feite speelt het conflict zich af tussen het relatiewindow en JOSM, maar conflicten zijn nooit makkelijk op te lossen.
Wat je moet doen, is het volgende:
Druk op het 2e knopje van links bovenaan, dat witte vlakje met een blauwe pijl erin wijzend.
Daarmee “kieper” de inhoud van het relatiewindow in JOSM
Dan knip je de weg door
Vervolgens druk je op het 1e knopje van links boven, met die draaiende pijlen.
Daarmee wordt de inhoud van JOSM in het relatievenster opgenomen
En nu zul je de weg keurig doorgeknipt vinden in het relatievenster en kun je het overbodige stuk weg verwijderen.

Dit is voor mij ook een grote ergernis, ik loop er vaak tegen aan dat ik weer vergeet het relatievenster eerst in JOSM te kieperen en dan beng, create a conflict. GRRRRR
Ik create nooit een conflict, ik cancel alles en doe het gewoon opnieuw. Gaat veel sneller dan conflicten oplossen

Maar wen je zelf eraan, zo vaak mogelijk die knopjes bovenaan te drukken, beter te veel dan te weinig

Als je een route wilt splitsen, dan kun je het volgende doen:
Maak een nieuwe lege route aan
Selecteer in de bestaande route de wegen, die naar de nieuwe route moeten
Sleep dat blok naar het lege venster
Even tags aanpassen
Nieuwe route lid maken van netwerk
Klaar
Je kunt dus van het ene venster naar het andere slepen, belangrijk hiebij is dat forward/backward mee gaat

En ik weet niet of je deze help-pagina kent:
https://josm.openstreetmap.de/wiki/Help/Dialog/RelationEditor

@Dick Bedankt voor je tips! Volgens mij had je ze voor een deel al eerder gegeven, maar ik snap ze nu beter omdat ik de problemen/fouten eerst zelf ben tegengekomen.
Konflikten: bij eerdere oefeningen was ik een paar keer mezelf tegengekomen, want ik werk op verschillende plekken met verschillende computers. Dan gaf JOSM mij de optie op “een conflict te maken”, omdat OSM veranderd was t.o.v. JOSM, maar het waren wijzigingen die ik ondertussen ergens anders zelf had gemaakt. Dan maakte het in wezen niet uit hoe ik het oploste, ik raakte altijd zelf een stukje werk kwijt, soms uit OSM en soms uit JOSM. Het ging dan om wandeltochtroutes, en dan vergelijk je alles in volgorde, het zijn wegnamen en niet zomaar nummers, en dan ging het oplossen prima. Met zo’n netwerk is dat geen doen.

Ik doe voortaan telkens een stukje afgerond werk en upload het dan meteen. De josm-validator heb ik ingesteld om de “er zit een node in je relatie” en “foute rol in je relatie” systematisch te negeren. Die krijg je op alle knooppunten als je de nodes opneemt in je trajekten én in je netwerk, dus bij een node die in drie trajekten zit geeft-ie vier loze foutmeldingen! Leve de ignore-optie.

Omdat ik nog niet opneem wat nog niet echt op de weg te vinden is, zijn er nog wel zwevende knooppunten, onaffe trajekten, en trajekten die nog gesplitst moeten worden. Dus vmarc zal nog wel even blijven pieperen. Maar ik heb geen zin om overal fixme’s op te zetten. Dan loop ik ook nog het risiko dat iemand het gaat “fixen”!

Je had gelijk met die nodes in de trajekten, als je bezig ben dan helpt dat enorm. En twee schermen naast elkaar, onmisbaar.

Nog een paar dingetjes, die je mogelijk al gevonden hebt, maar die ik veel gebruik:

Zien of een relatie lid is van een netwerk:
In het relation window of het tag window rechtsklikken op de relatie en in het context menu Select relation kiezen, dan wordt de relatie in het tag window getoond en zie je waar hij member van is of er staat niks.

relatie of knoop toevoegen aan netwerk:
Selecteer de relatie of knoop, zoek in het relation window naar het netwerk, rechts klikken en helemaal onderaan Add Selection kiezen

@Dick Hof van Delfland 61-80 door het Hitlandbos blijft de hele tijd in vmarc staan, maar die relatie is er helemaal niet meer.

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.