Wandelknooppuntennetwerk Zuidplas komt eraan

Het is zover, ze zijn aan het uitrollen! Ik kan in “Routebeheer” precies zien waar ze zijn en wat er al gedaan is, want elke plakker en elk punt wordt afgemeld en met foto’s gedokumenteerd. In feite kan ik dus gelijk gaan invoeren in OSM. Omdat het vooralsnog een uitbreiding is van Hof van Delfland hoef ik nog geen verbindingsstukken te maken.

Hoe zat dat ook alweer:

  • de verbindende trajekten in beide netwerkrelaties opnemen
  • alle nodes en trajektrelaties in de netwerkrelatie opnemen.
  • En grensnodes in één netwerk opnemen, namelijk dat netwerk waar het de meeste verbindingen mee heeft., ook al staat er officieel een andere netwerknaam op het paaltje? (het is uiteindelijk allemaal 1 pot nat…)
  • De nodes geen namen geven
  • De twee nodes in de trajektrelatie opnemen hoeft niet maar mag wel, als het handig werkt bij het invoeren, en dan later liefst weer verwijderen
  • De note:- in de trajektrelatie hoeft niet maar mag wel, want dat werkt handig bij het invoeren en aanpassen (dus ook niet verwijderen)

Ja toch?

Paar opmerkingen:
Trajectrelatie altijd van laag kp naar hoog kp, naam is een note tag met altijd “laag kp” streepje “hoog kp”
note tag is verplicht, de volgorde ook. VMarc controleert daar ook op.
Bij een verbinding tussen twee netwerken beide kp in beide netwerkien, routerelatie in beide netwerken met role connection.
Maar ook dat zie je snel genoeg in VMarc als je de knopenlijst door loopt, zie je welke knopen nog een netwerkrelatie moeten hebben (rood kruisje)
nodes mag je een naam geven als er buiten iets van een naam staat. De tag is rwn:name
kp geef je een tag expected_rwn_route_relations en je geeft hierin aan hoeveel relaties er op dat knooppunt bij elkaar komen. Bij connection routes kan dat problemen geven omdat VMarc per netwerk telt. Zelf laat ik die tag dan maar weg.
Leo heeft daar ook eens wat wijze woorden over gesproken.
Zelf bouw ik de expected meestal op. Begin met 1, als ik dan een tweede route op dat kp laat aankomen, 2, enz. Maar je moet gewoon doen wat je zelf als prettig ervaart.
Netwerkbeheerder geef je aan met operator tag.
Als de lengte van de route bekend is, kun je ook een distance tag toevoegen.
En ook een osmc:symbol is toegestaan

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