Validatie RWN-netwerken op grens met ander netwerk (expected_rwn..)

Gister het nog ontbrekende deel van het wandelnetwerk Rijn- en Veenstreek ingevoerd en daarna aan de slag gegaan om de resterende validatiefouten op te lossen (die voor het grootste deel samenhingen met de niet-complete status die het netwerk eerder had).

Het was gisteravond flink puzzelen om de laatste foutmeldingen mop de grens met andere netwerken (niet alleen Gouwe-Wiericke) weg te krijgen en het duurder even voordat ik het doorhad en de teller op dit netwerk en (en de omringende netwerken voor wat betreft de aansluitingen) weer op 0 fouten stond.

Vandaag zag ik dat echter alweer een soortgelijke foute was ontstaan, dus ik zal vast niet de enige zijn voor wie onderstaande tot voor kort onbekend is:

-het gaat om knooppunt-nodes met een foutmelding vanwege integriteit op http://osma.vmarc.be/nl/networks/nl/rwn

IntegrityCheckFailed: 
Nodes for which the "expected_rwn_route_relations" tag value does not match 
the actual number of routes that reference this node. 

-Met als waarden bijvoorbeeld:

Expected: 3
Actual: 2

Maar als je in JOSM kijkt, dan lijkt alles ok:
er komen wel 3 rwn-relaties aan op de node, en ze zijn ook allemaal lid van een rwn-netwerk (geen route-wezen).

Na wat puzzelen en vergelijken bleek dat het erom gaat dat als:
-de node lid is van netwerk A, er ook 3 routes van netwerk A moeten aankomen: een route die alleen lid is van netwerk B telt niet mee
-als de node lid is van zowel netwerk A als netwerk B, dan moeten alle aankomende routes lid zijn van zowel *netwerk A * als netwerk B

De oplossing was dus of om de routes lid te maken van meerdere netwerken of de knooppunten slechts van 1 netwerk lid te laten zijn.
Afhankelijk van de soort grenssituatie heb ik tussen die twee gekozen (grofweg respectievelijk : (1) bij node van het nieuwe netwerk B geplakt tussen twee bestaande nodes van netwerk A en (2) bij mooi gescheiden nodes omdat het oude netwerk in anticipatie van het nieuwe netwerk al een node had gemaakt met eerst 2 aantakkingen die later 3 werden).

Hopelijk helpt dit bij het foutloos houden van de netwerken (gister laat stonden zowel Rijn-/Veen, Gouwe-Wiericke / Groene Hart / Duin Horst en Weide en Hof van Delfland op 0 foutmeldingen voor knooppuntintegriteit en lijken ze behalve (het erg grote Hof van Delfland) ook compleet te zijn. Gaat goed met de netwerken in Zuid-Holland boven de IJssel!

Ga nu zelf verder met Bollenstreek.

ps.
Gouwe Wiericke was natuurlijk een verhaal apart met de soms grillige overname van bordjes door het nieuwe Rijn- en Veen, en latere acties in OSM. Heb in aanvulling van eerdere hersteledits met mijn foto’s en blik op de netwerkkaarten de afbakening verder proberen te verfijnen. Misschien niet perfect, maar zonder foutmeldingen en resulterend in een soort van begrijpelijk beeld, als het in het veld een warboel is kunnen wij het maar beperkt beter maken…

Tsja, dat had ik je dat zo kunnen vertellen. :slight_smile:

Ik durfde ook niet te denken dat ik jou nog iets nieuws kon vertellen op dit gebied, maar voor mij was het nieuw en even puzzelen :smiley: en afgaande aan het nieuwe foutje van vandaag ben ik daarin geloof ik niet alleen

Was eerst ook op een ander (verkeerd?) spoor gezet omdat bij het eerste geval dat ik aan de hand had het ook ging om een aankomende route waarin ook de knooppunten weer een *apart *lid van de routerelatie waren.

Leerpunt voor mezelf was in ieder geval om niet al te enthousiast de aangrenzende knooppunten van naburig netwerk A ook lid te maken van netwerk B (zo had ik dat eerder wel in mijn oren geknoopt),
omdat dat icm bovenstaande al snel leidt tot een soort haasje-over, omdat je dan ook weer de aankomende routes van “de verre kant” van het naburige knooppunt weer lid moet maken van netwerk B om geen validatiefouten te krijgen.

Ben dus kariger geworden met het verschaffen van buurlidmaatschappen van knooppunten, en ruimhartiger voor de buurlidmaatschappen voor routes.
Is dat zo in samenhang ook de breed geaccepteerde werkwijze bij grenssituaties?

Overigens is het in de algemene netwerk theorie zo dat een knooppunt nooit tot twee netwerken kan behoren.

Als beide knooppunten tot 1 netwerk behoren, behoort de route ook tot hetzelfde netwerk.

Als beide knooppunten tot twee verschillende netwerken behoren, is de route een connection en behoort ook tot beide netwerken.
Je ziet dat ook in V-marc: in plaats van een volgnummer in de linker kolom saat er een schakel. Als je de muis op de schakel zet, zie je een verklarende tekst.

Vandaag weer een derde serie knooppunten bezocht en vele van GW over moeten brengen naar R&V.
De knooppunten 21. 35, 19,52, 93, 48, 23, 20, 35, 93, 48, 58, 47 zijn in het verleden foutief overgenomen van wandelen 123 en behoren toch echt tot Rijn- en Veenstreek. ( survey te velde blijft toch wel erg leuk !)
Knooppunt 32 is kennelijk vergeten bij de overname door R&V. 32 heeft als opschrift GW, maar wordt volledig ingesloten door knooppunten van R&V.

Bij de update van V-marc van 20.00 uur zou alles er weer foutloos in moeten staan.

Groetjes,
Leo

Interessant, in de wiki gunnen ze zichzelf meer ruimte:
https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging

en ik had aan wat een tijd terug las (al dan niet correct) overgehouden de knooppunten aan weerszijden van een connection tot beide netwerken moesten worden toegevoegd (waar ik nu dus op terugkom).

Bij een geval waar in het oude netwerk al is geanticipeerd op het nieuwe netwerk (eerst 2 verbindingen, na komst van het nieuwe netwerk 3) is het me helder, dan worden alle knopen alleen lid van 1 netwerk en heb je 1 connection die lid is van beide.

Verderop in de wiki staat

Maar als je in netwerk A eerst knooppunten A1 → A2 hebt en netwerk B plaatst daartussenin knooppunt B1 (dat verbindt naar A1, A2 en verder alleen naar B2- dat weer niet verbindt met A), maak je B1 dan toch niet lid van beide netwerken?

(anders zou dat icm met bovenstaande worden met expected route relations=1 (want alleen B1->B2 is lid van B en de routes naar A1 en A2 niet, of hoogstens als connection), maar dat klink niet intuïtief en zo kan je ook niet controleren of weet de twee routes vanuit A1/A2 nog goed aansluiten.

-Is dit niet het geval waar de Wiki op duidt waarin een node lid wordt van twee netwerken?
-En dan met alle drie de aankomende routes in beide netwerken:
met in netwerk A de rol “connection” voor B1-B2 en in netwerk B de rol “connection” voor B1->A1 en voor B1->A2

En is dit misschien ergens uitgeschreven?

Eindelijk begint het weer ergens op te lijken, eindelijk zijn beide netwerken van elkaar gescheiden. Zitten waarschijnlijk nog kleine foutjes tussen maar ja die worden ook wel opgelost :slight_smile:

Binnenkort zal het Zuidplas netwerk wel weer wat afsnoepen van Rijn- en Veenstreek, Hof van Delfland en misschien klein beetje van Gouwe-Wiericke.

Interessant, de wiki geeft dus een onjuist beeld.
En V-marc wijkt weer af van de wiki en is gebouwd volgens de algemene netwerk theorie.

A1-B1 is een connectie die dus in beide netwerken meetelt, idem voor B1-A2
B1-B2 telt alleen in netwerk B.

Vmarc toont dan voor netwerk B:

B1 expected 3 aanwezig 3
A1 extern geen expected toont 1 route A1-B1
A2 extern geen expected toont 1 route A2-B1

Vmarc toont voor net werk A
A1 expected 1+x aanwezig 1+x
A2 expected 1+y aanwezig 1+y
extern B1 geen expected aanwezig 2connections

Nogmaals dat is de zuivere theorie van de algemene netwerk theorie !

Om het nog ingewikkelder te maken: soms lopen 2 routes voor het laatste deel over een zelfde weg naar een knooppunt.
Dan zit er niks anders op om vmarc om de tuin te leiden en het aantal expected met 1 te verminderen.
Volgens de theorie zou er dan een nieuw knooppunt moeten worden toegevoegd, maar de netwerken doen dat natuurlijk niet.

En tenslotte zijn er twee knooppunten die zo dicht bij elkaar liggen dat ze hetzelfde nummer krijgen.
Daar is elders op het forum al veel over geschreven, maar dat kan ik niet zo gauw terugvinden.

Zo, en na al deze theorie, morgen weer aan het werk in ons regiments-museum.

Groetjes,
Leo

Dank voor de toelichting, Leo!
Snap alleen nog niet helemaal de “extern geen expected” in onderstaande quote:

Wat goed bleek te werken om de overlap in netwerken te visualiseren was om de actuele gpx-en van de netwerken te downloaden via http://osma.vmarc.be/nl/networks/nl/rwn en die beide in JOSM te openen in een andere kleur en de onderste breder te maken dan de bovenste.

Heb de knooppuntnr’s uit jouw post van 18:28 voorzien van een operator:rwn=Rijn- en Veenstreek om toekomstige twijfels te verhelpen

Aan de hand van de gpx-en nog twee te ver doorlopende overlappen (want geen connections) verwijderd en er eentje toegevoegd waar die nog ontbrak.

Als het goed is zijn de netwerken nu echt helemaal gescheiden en zou ook de integriteitscheck moeten kloppen, maar vandaag ga ik niet opblijven om de update van Vmarc te zien (-;

Knoopppunt A1 heeft wel de tag voor een aantal expected routes maar Vmarc toont dat niet als je netwerk B bekijkt.
Bekijk je netwerk A in Vmarc dan wordt het aantal expected wel getoond.

Ah, zo!
Dus niet alleen het ‘actual’ aantal (aantal routes) maar ook het ‘expected’ aantal (eigenschap van het knooppunt) wordt steeds bepaald geredeneerd vanuit de netwerk lidmaatschappen van respectielijk de routes *en * het knooppunt.

Wel prettig dat Vmarc ook de connections meetelt, want als het zou gaan zoals je uit de wiki zou kunnen afleiden (connections tellen niet mee voor expected aantal), dan wordt het steeds heel tegenintuïtief: je *ziet *drie routes aankomen maar expected zou dan 1 of 2 zijn vanwege connections…

Heb de afbakening tussen Gouwe-Wiericke en Rijn en Veenstreek verder verfijnd, zie onderstaand plaatje (obv de gpx-en van Vmarc in Josm: dubbele kleur zijn de connections)

Bij KNP 32 hebben Johan en Leo al een pragmatische keuze gemaakt door ondanks de tekst “Gouwe Wiericke” (GW, paars in het plaatje) op het knooppuntbordje deze toch alleen tot het netwerk Rijn- en Veenstreek (RV, blauw in het plaatje) te laten behoren, aangezien deze verder alleen omringd is door andere RV-punten.
Het aanbrengen van de namen op de bordjes lijkt soms vrij arbitrair en dit paaltje lijkt vergeten te zijn in de overnamegolf door RV van bestaande GW-routes. De grote lijn van de overname is wel verwerkt in de gewijzigde indeling van de netwerken.

Door gewijzigd inzicht nav bovenstaande discussie en het werk sindsdien heb ik wat last gekregen van voortschrijdend inzicht en heb bij het schrappen van te ver doorgevoerde connections de lijn van knooppunt 32 iets verder doorgevoerd:

Voorbeeld:
-knooppunt 20 (rechtsonder in beeld) heeft nu een bordje “Rijn- en Veenstreek” (constatering van Leo in survey), maar is ingevoegd op een bestaande route van GW (46-65) waar RV verder geen deel aan heeft, anders dan door de naam op het knooppuntpaaltje.
-als je sec redeneert vanuit de naam van de knooppunten, dan wordt 20 lid van RV (en niet van GW, want in beginsel is een knp lid van 1 relatie, zowel vanwege netwerktheorie als praktisch: haasje over van connections ivm expected count).
-routes 20-46 EN 20-65 zouden dan de connections tussen GW en RV worden , terwijl deze al bestonden en een lus vormen en eigenlijk het pootje 20-23 de verbinding vormt tussen het ene en andere netwerk
-bij netwerken met een duidelijke fysieke scheiding (zoals de Kromme Mijdrecht tussen RV en Groene Hart) wordt dit rare effect nog meer zichtbaar: niet de route die de grens tussen de netwerken (de rivier) oversteekt is de connection, maar twee routes aan een kant van de rivier

Daarom heb ik ervoor gekozen om het lidmaatschap van dergelijke knooppunten (op de grens en met slechts 1 verbinding met het netwerk dat op het bordje staat vermeld) meer te laten bepalen door het geheel van routes dan door alleen op het bordje.

Nadeel is dat de naam en netwerk niet meer 1-op1 overeenkomen. Heb dat toegelicht in de comment, net zoals Johan / Leo dat al bij knooppunt 32 hadden gedaan. De voordelen lijken me dat meer dan waard (veel logischer netwerken) en met die toelichting is het in ieder geval nog navolgbaar voor geïnteresseerden.

-voordat ik verder ga om de overlap tussen Hof van Delfland en RV te corrigeren:-
Of vinden jullie de andere optie (bij 20 2 connections naar 46 EN 65 ipv 1 naar 23) echt heel veel beter?

Als het probleem echt in de vermelde naam op he tbordje zit, dan wil ik best een rondje fietsen met mijn lettertang in de achterzak voor correcties (bij 20 dus “Gouwe Wiericke”, want die bordenplaatsers zijn zelf ook halve graffiti-plegers die graag hun naam overal achterlaten :wink:

Ja als je het historisch besef van de route 46-65 van GW als argument inbrengt dan heb ik natuurlijk geen tegenargumenten meer.
Van mij mag het dan zo blijven, alleen nog even een foutje eruit halen: knooppunt 33 kan niet tot 2 netwerken behoren.
PS
Die lettertang moet ik onthouden, er schiet mij zomaar de tekst “mijn netwerk” door het hoofd :slight_smile:

Dit klopt bijna altijd.
Alleen bij de overlap van het wandelnetwerk Venray met de omliggende gemeentes is het een zooitje geworden (mijn mening).
En er zijn meer me dezelfde mening:
https://www.wandelknooppunt.nl/wandelnetwerk%20venray.htm

Het lastige is dat vaak verschillende nummers gebruikt zijn bij de koppeling tussen de netwerken.
De koppeling tussen Horst ad Maas en Venray bij Castenray is verbeterd en ziet er nu beter op.
Bij Blitterswijck zou dit nog moeten gebeuren.

Om alles compleet te krijgen heb ik bij verschillende nummers 2 rwn_ref punten ingevoerd, vlak langs elkaar.
Mocht er ooit een router komen is dat allesbehalve fijn.
De routeplanner van routebureau Noord- en Midden Limburg heeft hier ook moeite mee.Sommige trajecten kun je niet toevoegen aan een wandeling.

Het probleem met (iig) Venray en Horst is dat beide netwerken een paaltje hebben neergezet waar de netwerken samen komen. Ik ben er langs geweest omdat het mij ook stoorde, maar het is gewoon vervelend voor onze manier van werken.

Hier heb je een foto van zo’n situatie. Links, het houten paaltje met metalen plaatjes is Venray, rechts plastic paaltje met rood-gele plaatjes is Horst.

Prachtige illustratie van de grillige werkelijkheid (die overigens in dit geval naar mijn idee echt beter *kan *en *moet * ) die we met z’n allen in een (sociaal gezien) niet-hiërarchisch systeem wel systematisch proberen weer te geven…

Ook goed om in het achterhoofd te houden als we -mede ingegeven door het format van een internetforum dat niet altijd het beste in ons bovenhaalt- elkaar hier al te star / principieel / eenzijdig benaderen wegens verschillen van inzicht over hoe iets gemapt dient te worden

(waarbij overigens opvalt dat wel we -ook ik…- doorgaans principiëler zijn als het om het werk van anderen gaat en pragmatischer als het om ons eigen werk gaat…)

Kwam vandaag ook onderstaande tegen, niet zozeer een probleem met mappen voor ons, maar wel een illustratie bij bovenstaande discussie dat ook bordenplaatsers niet altijd handelen op basis van wat je van een heldere scheiding en bruikbaarheid van netwerken zou verwachten…

ps.
gevonden dankzij https://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes#NWB :
onder het bandje van het knooppuntennetwerk Rijn- en Veenstreek zit een aanduiding van deze relatie : https://www.openstreetmap.org/relation/1123606#map=10/52.1234/4.9287

http://www.koninklijkeweg.nl/

Ik spring even in op Zuidplas: Die relaties en tellingentoestanden gaan met nog boven de pet, maar wat mij betreft maakt het geen bal uit wat er voor naampje op de paaltjes staat en of iets GW, HVD, KR, RV, XXX, Straciatella of Boomkangaroepaardestaart heet. Het nieuwe stuk wordt aangelegd door Staatsbosbeheer, net als HvD en (toch?) GW, dus wat mij betreeft is het allemaal 1 ding. De gemeente Zuidplas heeft het aangevraagd, maar doet er verder niks aan: alles ligt bij Staatsbosbeheer.

Er komen straks verbindingen van HvD in Zuidplas (die liggen er al) maar ook van Zuidplas voorgestelde routes in Capelle (HVD-gebied), Oostpolder (GW-gebied), Waddinxveen (GW), Gouwebos (GW), Westergouwe (=Zuidplasgebied verkwanseld aan Gouda), Het Beijersche (Krimpenerwaard). Staatsbosbeheer laat alles aanleggen door Folkersma, en ik heb echt geen invloed op wat zij aan extra informatie op de paaltjes zetten. Volgens mij gaat het hun er alleen maar om dat de nummers per netwerk uniek zijn.

Wij hebben met name ons best gedaan om onverharde verbindingen toe te voegen, dus ik denk dat het echt meerwaarde heeft. Hopelijk wordt de registratie daardoor niet onmogelijk…

Voor zover ik heb meegekregen was Staasbosbeheer niet betrokken bij RV, maar ik weet wel dat dat netwerk door een ander bedrijf is uitgevoerd dan het bedrijf dat jij noemt. Zou zo maar een van de verklaring kunnen zijn van de overnamedrift (misschien niet voor half Boskoop, maar wel voor bestaande palen op de nog steeds bestaande grens die nu opeens van een ander “merk” zijn geworden.

Mooi dat er veel onverharde paden in het nieuwe netwerk komen, dat is volgens mij echt de meerwaarde van zo’n netwerk: nieuw inzicht geven in waar de interessante routes/paden liggen en hoe ze samenhangen. Dat klinkt misschien als een open deur, maar in de praktijk zie je dat er in sommige netwerken vooral wordt geprobeerd om maar zoveel mogelijk lijntjes in te tekenen en paaltjes te plaatsen, ook al zijn er helemaal geen goede wandelmogelijkheden.

Bijvoorbeeld een (bestaand) traject waarbij je een uur over deze weg loopt waarbij je opties voor uitwijken voor het best drukke verkeer bestaan uit in het water of over een hek springen…
https://www.google.nl/maps/@52.094248,4.4452665,3a,75y,33.39h,87.48t/data=!3m6!1e1!3m4!1sPyZTGSxMr5gsq15IINNB6g!2e0!7i13312!8i6656

Voor zover ik het nog weet, alle netwerken die tot nu toe in Zuid-Holland zijn aangelegd, zijn volgens mij met subsidie van de Prov. Zuid-Holland aangelegd. Geldt volgens mij voor alle netwerken, zoals HVD, GW, RV en Bollenstreek.
Hoop niet dat Staatsbosbeheer andere paaltjes gebruikt.
Trouwens dat overnemen deden Gouwe-Wiericke en Krimpenerwaard ook met de paaltjes van het Groene Hart (lieten wel de nummers hetzelfde)

Wij konden dat ook niet helemaal voorkomen: https://goo.gl/maps/L5jaobBLuJt hier lijkt het nog of je in de berm kan staan maar dat zijn heel schuine slootkanten, als je daar wil gaan staan glij je in de sloot. Ons voorstel om de graskade die er parallel aan loopt https://goo.gl/maps/SLUsmmB7uxS2 te gebruiken stuitte op privee-erven die de graskade erbij getrokken hebben. Hoge hekken dus. Tja. Op zich is zo’n graskade van rijkswaterstaat en zouden ze lopers toe moeten laten, maar dwang werkt niet in dit soort gevallen.

Was wel geïntrigeerd door het voorbeeld van de Onderweg (in het gras kunnen lopen zou idd waardevolle toevoeging van het netwerk zijn) en als er eigenlijk een bepaald niet benut een recht van toegang zou zijn, dan zou ik me daar ook wel voor willen inspannen.

Uit Kadasterdata bleek die grond het echter niet van Rijkswaterstaat te zijn, maar van een particulier.
En zag zo snel ook geen civielrechterlijk recht van overpad naar voren komen. Als je meer details wilt weten: stuur gerust een PM