Wandelknooppuntennetwerk Zuidplas komt eraan

Ik heb de definitieve tekening van het netwerk gekregen. Zoals het daarin staat gaat het over een aantal weken uitgevoerd worden.
Tijd om me te gaan verdiepen in de kunst van het knopen breien.
Is er ergens een handig stappenplan om dit aan te pakken? Met handige let-goed-op-zus-en-doe-vooral-niet-zo’s?

Ik neem aan dat ik begin met de knooppunten zelf, dan de losse verbindingsrelaties (zonodig eerst ways bijmaken) en tenslotte alles samennemen in 1 superrelatie? Of geen superrelatie maar een gewone relatie met alles er nog een keer in?

Je hebt 1 netwerk.
Daarvan worden alle knooppunten en alle routerelaties lid
De routes lopen telkens van knooppunt naar knooppunt, dus altijd tussen 2 knooppunten.
Hierbij is de sortering altijd van het laagste naar het hoogste knooppunt
In de routerelatie komt een tag note=kpA-kpB, waarbij kpA het laagste knooppunt is en kpB het hoogste.
Dan zijn er ook nog wat zaken bij een verdeeld knooppunt, maar dat komt wel als je daarmee te maken krijgt
Ook de aansluiting op andere netwerken heeft nog wat bijzonderheden.

Kijk ook bij VMarc op de overzichtspagina staan links onder Documentatie een paar links.
De Woordenlijst bevat nog nuttige info en de links verwijzen naar wiki pagina’s

En verder bestudeer een bestaand netwerk en hoe een en ander in elkaar steekt.
Bij VMarc vind je de netwerken onder Wandelen

Een stappenplan is er niet voor zover ik weet.

@Peter:
Mooi vooruitzicht!
En op zich schets je een goed raamwerk voor stappenplan.

In aanvulling op de post van Dick een paar punten die opkomen:
-de superrelatie waarover je (Peter) schreef, kan je dus vervangen door * netwerk*
-knooppunten eerst is idd fijn, als je die eerst upload heb je wat houvast (en foutencontrole tov surveymateriaal/plankaart) als je daarna routerelaties aanmaakt (volgorde etc.)

-werk in netwerk in kleine partjes (bijvoorbeeld steeds uitbreidende lussen ipv “boomstructuur” )
-gelijk nadat je een element (knoopput of relatie) hebt aangemaakt deze toevoegen aan het -juiste…- netwerk, anders vergeet je dat en breng je “wezen” in de wereld

-bij route kan het ook een goede tussenstap zijn om eerst te checken in hoeverre wegen dienen te worden opgeknipt en dat te doen (en te controleren op schade, zie recente discussie in draadje “welkom”
-hoe je ook toevoegt met relatievenster (zie PM van tijdje terug): na voltooien van route is check op gaten/volgorde erg raadzaam

-na upload even kijken of het correct rendert in Waymarkedtrails (duurt paar minuutjes) geeft zichtbaar resultaat van werk en de nodige rust voor je muisarm (mijn gebruik van F5 in laatste twee jaar is denk ik evenveel als in alle jaren daarvoor)

-in JOSM is de kaarttekenstijl (Wandelknooppuntennetwerken ; heel goed: één woord!) een erg fijn hulpmiddel, evenals

-Grenzende netwerken kunnen gedoe geven (zie eerder draadje) als je laat weten wanneer je echt begint zal ik vooraf zorgen dat de grens tussen Hof van Delfland en Rijn-en Veenstreek niet meer onnodig overlapt (zie andere draadje) anders wordt het helemaal een gordiaanse knoop. Als je wil kan ik de grens met Zuidplas ook wel proberen zo goed mogelijk vast te leggen als jij info aanlevert over feitelijke scope van netwerk Zuidplas (welk deel wordt echt door deze organisatie onderhouden in de toekoemst en welke “merknamen” staan er op de bordjes (zowel knooppunten als routepijlen, te taggen met operator=)

-Verder staan er in diverse draadjes op het forum nog veel tips van Dick, onder andere in reactie op vragen van mij nav fietsnetwerk Groene Hart

Succes!

@multimodaal Ik heb de diskussie over aangrenzende netwerken min of meer gevolgd maar raakte de draad kwijt.
Als ik een nieuw knooppunt van Zuidplas aanmaak wat verbonden moet worden met een bestaand knooppunt van Krimpenerwaard, moet ik de routerelatie dan lid maken van beide netwerken?

En wat gaat er in de praktijk fout als ik hem maar van 1 netwerk lid maak, of helemaal geeneen?

Zullen we het daar tzt over hebben, ik loop nog wat achter… (-: ?

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.