Wandelknooppuntennetwerk Zuidplas komt eraan

Volgens de wiki-pagina over fietsknooppuntnetwerken is dat toch anders. Daar staat over de netwerkrelatie:

Dus de knooppunten zitten maar in één netwerkrelatie, ook als er een verbindingsroute naar een ander netwerk vertrekt en aankomt. Dat vind ik ook wel logisch: een knooppunt hoort bij één netwerk, de route vormt de verbinding, en hoort dus bij beide netwerken, en is door de aanduiding connection als verbinding te herkennen.

Als niet de route door twee netwerken gedeeld wordt, maar het knooppunt, is de tagging als volgt. Het knooppunt is lid van beide (of meer?) netwerken met als rol connection. De routes horen dan maar bij één netwerk:

Als vmarc bij het toepassen van deze tagging-afspraken foutmeldingen geeft, lijkt het me logisch om de maker op de wiki-pagina te wijzen. Dan kunnen de validatie-regels aangepast worden, of eventueel de wiki-afspraken veranderd, als daarvoor goede argumenten zijn.

Ik heb zelf geen “grens-overscheidend gedrag” vertoond bij wandel- of fietsnetwerken. Ben wel benieuwd naar de eventuele fouten die vmarc meldt, wanneer verbindingsroutes volgens de wiki getagged worden.

Ga er maar vanuit dat ik fout zit in deze. Voor zover ik weet, volgt VMarc de wiki.
Ik heb ook niet gezegd dat VMarc foutmeldingen geeft, alleen dat je een rood kruisje bij een knooppunt kunt zien, wat een teken is dat het knooppunt nog in een netwerk moet worden opgenomen.

Overigens is de wiki een prachtig theoretisch verhaal wat helaas nog nooit door een netwerkbeheerder is gelezen. Buiten kom je allerlei varianten tegen. En die moet je dan maar in dat theoretische verhaal zien in te passen.

Overigens is het wel uitkijken met die wiki pagina. Dat stuk over tentakels is gewoon niet te volgen en het voorbeeld is in OSM al lang om zeep geholpen :slight_smile:

vmarc is hier mis en dient aangepast te worden. Zie ook https://github.com/vmarc/knooppuntnet/issues/6.

De wandelprojektpagina verwijst naar de fietspagina wb taggen van knooppuntnetwerken. Dat klopt dus niet helemaal met de nederlandse afspraken. En hier onderling zijn we het ook niet helemaal eens, sommigen doen het zus en anderen zo…

Het lijstje hierboven was gebaseerd op de minimaal verplichte tags om het netwerk vast te leggen, daar zijn bv knooppuntnodes en note in de trajektrelatie optioneel.
Volgens de Nederlandse afspraken zetten we knooppuntnodes en de note wél in de trajektrelatie, hoewel ik ook iemand heb zien zeggen dat dat eigenlijk niet goed is… en dan heb je vmarc als validator, die weer nét anders werkt…

Wat ik wil doen is op de wandelprojektwiki het aktuele setje NL afspraken (dus het minimaal verplichte plus de afgesproken extra’s) neerzetten, zonder de verwijzing naar de fietsknooppunten. En zonder het tentakelverhaal. Als het goed is zijn dat ook de dingen waar vmarc op checkt. Ik heb al wel gezien dat er netwerken zijn die hier niet volledig aan voldoen en toch prima tonen in wandeltoepassingen en apps, maar dat is voor later.
Ik ben er al aan bezig geweest maar het is zwoegen… ik ga proberen het tegelijk te doen met de invoer van het Zuidplasnetwerk.

distance is alleen voor de trajektrelatie, lijkt mij?
operator en osmc:symbol zijn voor de netwerkrelatie neem ik aan?

Wordt de rwn:naam van een knooppunt ergens weergegeven?

De knooppuntnodes opnemen in de trajektrelatie, maken we daar nou een verplichting, een voorkeur of een toegestane optie van? Het was dacht ik niet nodig, alleen kan het handig zijn bij het mappen. Of checkt vmarc erop?

Let op het verschil tussen junction (verbindt een place of een POI of zo met het netwerk, oftewel het is een tak zonder eindknooppunt), en connection (verbindt knooppunten van twee netwerken).

Sorry vergeet dit. Ik was verward door de verschillende uitleggen. Voor losse takken naar bv een POI of stadshart heb je een state=connection tag, en die eindigt dan op een knooppunt waar maar 1 trajektroute aan zit.

distance is voor de route. operator kan op het netwerk, osmc:symbol zal op de route moeten denk ik, op het netwerk zal het niet werken, denk ik zo maar, ik heb het nooit uitgeprobeerd. Ik gebruik het symbol voor verbindingsroutes, die geen gekleurde of twee kleurroutes op zich krijgen., maar dat is zeer specifiek voor deze regio. Ik zie op Waymarked Trails dat in het zuiden het osmc:symbol veel wordt gebruikt voor rwn.

rwn:name wordt momenteel nergens weergegeven.
Even kort de geschiedenis, hier in Overijssel en ook de Achterhoek hebben veel fietsknooppunten een naam. Een mapper had daarvoor rcn_name bedacht. Maar daar mopperde de validator voortdurend over. Toen ben ik overgestapt op rcn:name in de lijn van de namespace zoals die nu in OSM wordt gehanteerd en zie daar, het gemopper was voorbij. :slight_smile: In diezelfde lijn kun je dus rwn:name gebruiken.

Ik pleit ervoor de knooppuntnodes te laten zoals het nu is. Dus optioneel in de routes, maar als iemand dat niet wil, ook prima. Ik ben zo’n iemand. VMarc heeft er een kolom voor in het knooppuntenoverzicht.

osmc:symbol op het netwerk is eenvoudig te testen of dat werkt.
rwn:name zal voor wandelen niet veel voorkomen (dan blijf je bezig, honderd knooppunten voor een relatief klein gebied, gaat niet gebeuren) en bovendien wordt het niet weergegeven… ik zou het uit de standaardafspraken houden.
Knooppunten optioneel in de trajektrelaties, eigen voorkeur, akkoord.

als vmarc de standaardvalidatortool voor rwn’s is, dan neem ik hem in de wandelwiki op.
waymarkedtrails heb ik als standaardrenderer voor xwn’s.
JOSM natuurlijk als standaard-osm-editor.

Zijn er nog meer handige tools die we voor wandelknooppuntmappers als standaard neer kunnen zetten?

In JOSM is het ook handig om de wandelknooppunten-layer aan te zetten, zodat je meteen ziet wat je invoert.

Ik heb afgelopen twee jaar de rest van Hof van Delfland ingevoerd. Er missen nog een paar delen. Daarbij heb ik de knooppunten niet aan de routes toegevoegd. Ik ben in Hof van Delfland geen knooppunten met namen tegengekomen, dus rwn:name lijkt daar niet nodig.

Wandelnetwerk Zuidplas wordt uitgerold voor de helft als uitbreiding van Hof van Delfland, de andere helft wordt Gouwe-Wiericke.
Er ontbraken nog wat stukjes HvD in Hitland, op de grens van Zuidplas en Capelle an de IJssel. Daar zijn zowizo nu wat wijzigingen door de nieuwe trajekten, dus dat kan nu in één keer helemaal goed gemaakt worden!

Gisteren en vandaag is Folkersma aan de slag geweest, dus het moet daar nu in het veld klaar zijn. Ik kan de voortgang letterlijk paaltje voor paaltje volgen omdat ik in het afmeldsysteem van Folkersma kan inloggen. Over twee weken ga ik met de wandelwerkgroep MooiZuidplas langs de nieuwe punten en routes alles nalopen en checken, te beginnen in Ver Hitland. Maar daar hoef ik dus niet op te wachten, want de uitvoerders maken foto’s uit alle richtingen van elk paaltje en elk pijltje, en voeren dat in samen met de werkbeschrijving (welk nummertje aan welke kant wijst in welke richting naar het volgende nummertje) en de exakte lokatie. Dit wordt het best gekontroleerde en snelst ingetekende netwerk ooit! zichzelf op de borst roffelt.

Ik zal door vmarc wel snel op aarde teruggesmakt worden…

rwn:name gaat inderdaad niet nodig zijn. Ik zal de knooppuntnodes wel aan de trajektrelaties toevoegen, zolang het invoeren nog bezig is. Daarna ga ik alles nog een keer kontroleren, er zal nog wel wat verbeterd moeten worden. Wat er dan helemaal klaar en gedubbelcheckt is, ook op richting, #expected relations en misschien distance (moet ik nog over nadenken of ik dat wel ga doen), daar haal ik de nodes dan weer uit. Dat is mijn plan!

Goed bezig (-:

Ik heb vanmorgen routes en knooppunten aan het netwerk Hof van Delfland toegevoegd. Iemand heeft ze daarna weer uit het netwerk gehaald. Ik kan aan de historie niet zien wie. Maar even voor de goede orde, routes en knooppunten moeten per direct na het aanmaken lid worden gemaakt van het netwerk. Dat is prio 1.
Ik ben nu weer een bak meldingen van VMarc aan het afwerken en ik hoop dat ik niet nog een keer moet doen.
Verder moeten routes per direct gesplitst worden als er een nieuw knooppunt op gelegd wordt. Ik heb vanmorgen route 61-80 in flink wat delen gesplitst, routes en knopen lid gemaakt van Hof van Delfland en nu kan ik ze opnieuw lid gaan maken

Sorry Dick, ik ben bang dat het mijn schuld is. Ik ben de Zuidplasknooppunten en routes aan het toevoegen aan de hand van de werklijst van de markeerders. Ik zag dat er konflikten waren, heb geprobeerd die op te lossen maar snapte duidelijk niet goed genoeg hoe dat werkt. Ik ben zelf ook werk kwijtgeraakt, maar daar had ik al rekening mee gehouden (verwachtingenmanagement, erg belangrijk).

Terwijl ik invoer en ondertussen dingen korrigeer (soms omdat ik het zef niet goed gedaan had), zal je geregeld onaffe situaties tegenkomen in vmarc. Hof van Delfland is enorm groot, de kans dat iemand anders een aanpassing doet terwijl ik in JOSM bezig ben blijkt best groot te zijn, dus ik upload steeds vaker maar dan heb je meer onaffe situaties…

Ik wil je zeker geen extra werk of ergernis bezorgen, als ik wat vernield heb wil ik het natuurlijk zelf herstellen, als ik weet wat.
Het gaat nog wel even duren voordat alles erin zit. Ik zal proberen zorgvuldiger en in afgeronde stukken te werken, dus niet eerst alle knooppunten, dan ontbrekende ways, dan relaties, maar kunnen we ook iets afspreken om te voorkomen dat we elkaar in de weg zitten?

Het zal zeker nog een maand duren voordat het netwerk verder ingevoerd is. Na het Hof van Delflandgedeelte volgt een bijna even groot Gouwe-Wiericke deel.

Wat ik erg lastig vind is dat in de netwerkrelatie de nodes alleen als objektnummer verschijnen, en dat ik niet kan zoeken of sorteren, en in de konfliktoplosser kan je ook niet goed zien wat wat is. Heb jij tips wat dat betreft? Het aantal leden van de netwerkrelatie Hof van Delfland loopt tegen de 1500 aan, dus ik vind het echt wel een dingetje.

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.