Wandelknooppuntennetwerk Zuidplas komt eraan

Ok alvast bedankt!

Ik heb het plan grotendeels geanalyseerd op interacties met omliggende netwerken: Hof van Delfland, Krimpenerwaard, Gouwe Wiericke, Rijn en Veenstreek.
Resultaat: een heel klein kernnetwerk is puur Zuidplas, maar het overgrote deel van de nieuwe punten en routes zit aan minstens 1 ander netwerk vast. De nummering, markering en de route-aansluitingen in het veld zien er goed uit, maar als je dit als nieuw netwerk in osm gaat inbrengen en apart probeert te houden, dan heb je een serieus probleem.

De oorzaak: vooral hof van delfland maar ook Gouwe Wiericke en Rijn en Veenstreek hebben hun netwerk over de rand heen geleg, HVD zelfs heel ver, en dwars door Zuidplas heen. Daardoor was het onvermijdelijk om die knooppunten in onze plannen op te nemen. Omgekeerd hebben wij ons ook niet strikt aan de grenzen gehouden, en knooppunten en routes gepland in het gebied dat al door andere netwerken bestreken werd. En dat komt er dus allemaal!

De projektleider van toen de provincie maar nu Staatsbosbeheer gaf aan dat hij de benodigde afstemmingen zou doen… maar ik vraag me serieus af of dat gedaan is en of daarmee het beheer geregeld is… In ieder geval, als er ruzie over komt is het mijn schuld! En dus ook het OSM-mapping probleem.

Waar ben ik aan begonnen?

Gelukkig heeft de exacte afbakening in OSM ook weer niet zulke dramatische effecten en kunnen we ons in eerste instantie ook vooral laten leiden door “de merknaam” op het knooppuntpaaltje.

In het draadje over RWN-validatie kwamen een paar uitzonderingen naar voren die bij toepassing van die regel tot wel hele rare netwerkvormen zouden leiden (meest duidelijke : een achtergebleven niet-omgekat paaltje van GW dat verbinding alleen had 4 knopen van RV).

Praktisch gezien komt de daar voorgestelde (en reeds toegepaste werkwijze) erop neer dat een paaltje hoort bij het netwerk dat erop staat vermeld TENZIJ dit paaltje meer verbindingen heeft met een ander netwerk.

Dan ga ik dus een heleboel uitbreidingen toevoegen aan andere netwerken.
Aan welk netwerk voeg ik een relatie toe die ligt tussen een knooppunt van netwerk a en een knooppunt van netwerk b?

Aan beide, met als rol “connection”

Zie toelichting en illustratie op https://forum.openstreetmap.org/viewtopic.php?pid=685442#p685442

Zojuist heeft de projektleider van SBB (Kees Opstal, vast geen onbekende) het een stuk makkelijker gemaakt: Er komt kwa naamgeving geen Zuidplas netwerk (alleen op de infoborden wordt Zuidplas genoemd). Ze hebben een streep getrokken, aan de ene kant wordt/blijft alles Gouwe Wiericke, aan de andere kant wordt/blijft alles Hof van Delfland. Er hoeft niets omgekat te worden.
Hij bevestigde verder dat de namen op de paaltjes komen te staan en dat dat puur voor het formele beheer (lees: de lasten en kosten) is; uiteindelijk voert SBB in de praktijk ook het hele beheer uit. Alles wordt daarna toegevoegd aan wandelen123.nl .

Ik ga lekker achterover leunen totdat ze gaan plaatsen, en dan HvD en GW op OSM uitbreiden tot ze mekaar onlosmakelijk omarmen.

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