Wandelnetwerken oost-Nederland : samenhang rwn/lwn

richardbrinkman · 2017-11-26 21:21:06

Grootste nadeel van optie 3 vind ik de onderhoudbaarheid en validatie. De knooppuntenroutes (in ieder geval die van netwerk Twente) zijn continu aan veranderingen onderhevig. Het zijn soms maar kleine verschilletjes, soms groter. Als je twee parallelle netwerken hebt, hoe ga je dan om met veranderingen in het ene netwerk die in het andere netwerk worden vergeten door te voeren?
Ik ben zelf gepromoveerd op het gebied van databases. In de database wereld is het een grote no-go om gegevens dubbel op te slaan, tenzij er automatische synchronisatie is (bijvoorbeeld master-slave databases, foreign keys of caching). Optie 3 heeft dat niet. Als je de lwn aanpast verandert de rwn niet automatisch mee en vice versa. Er gaan dus ongetwijfeld verschillen tussen de beide netwerken ontstaan. En de enige manier als mapper om erachter te komen welke van de 2 netwerken klopt, is om ter plaatse te gaan kijken. Je verdubbelt daarmee dus de hoeveelheid werk. Tools gaan hier helaas niet helpen. Een lwn route hoeft namelijk geen knooppuntenroute te zijn.

Last edited by richardbrinkman (2017-11-26 21:23:23)

multimodaal · 2017-11-26 23:01:02

Optie 3 vraag er inderdaad wel om dat je beide aanpast, dat is inderdaad een nadeel.
Wel is is aanpassen eenvoudig.
En soms (in ieder geval hier in de regio) wordt wet het rwn aangepast, maar niet het lwn en dan zijn de twee netwerken juist een voordeel. Maar dat lijkt (iig bij wat ik van het Vechtdal heb gezien) in oost-Nederland minder waarschiijnlijk omdat de bewegwijzering daar zo sterk op de kleuren leunt.

Bij optie 4 gaat het denk ik wel vanzelf goed als het gaat om het verleggen van (zowel lwn als rwn) de wijze waarop een verbinding tussen twee knooppunten loopt.

Wat bij mij in de regio het meest gebeurt, is echter dat er knooppunten worden tussengevoegd.
Zou je dan met optie 4 in zo'n geval ook niet beide relaties moeten aanpassen (zowel de knp-knp als de lwn-relatie die bestaat uit knp-knp-relaties) ?

Vanuit dat perspectief zou optie 2 weer het meest automatisch beide niveau's aanpassen:
als je daar de knp-knp's zo aanpast dat er een nieuw knooppunt is ingevoegd en de kleuren goed toekent aan de knp-knp-delen, dan zijn beide niveau's in een keer aangepast.

Ook lijkt het me (als leek op gebied van informatica) met optie 2 het makkelijkst om -als alles goed is ingevoerd..- in keer een kaart te maken die aangeeft dat er verschillende kleuren aan een bepaald wegsegment hangen. Anders zal je denk ik moeten zoeken welke verschillende routes er allemaal over een gegeven weg lopen en die informatie bij elkaar brengen voor je rendering, of is dat niet complexer dan domweg de kleuren drie renderen die in een variabele van die weg zijn opgenomen?

richardbrinkman · 2017-11-27 08:42:02

multimodaal wrote:

Vanuit dat perspectief zou optie 2 weer het meest automatisch beide niveau's aanpassen:
als je daar de knp-knp's zo aanpast dat er een nieuw knooppunt is ingevoegd en de kleuren goed toekent aan de knp-knp-delen, dan zijn beide niveau's in een keer aangepast.
Ook lijkt het me (als leek op gebied van informatica) met optie 2 het makkelijkst om -als alles goed is ingevoerd..- in keer een kaart te maken die aangeeft dat er verschillende kleuren aan een bepaald wegsegment hangen. Anders zal je denk ik moeten zoeken welke verschillende routes er allemaal over een gegeven weg lopen en die informatie bij elkaar brengen voor je rendering, of is dat niet complexer dan domweg de kleuren drie renderen die in een variabele van die weg zijn opgenomen?

Optie 2 gaat de mist in zodra er relaties kapot gaan. Dit gebeurt door veel beginnende mappers (veelal met de ID-editor) vaak per ongeluk. Stel dat er ergens het eerste of het laatste stukje (per ongeluk) uit de knooppunt-knooppunt relatie wordt verwijderd. Je houdt dan een gat over. Software kan op geen manier meer bepalen of de relaties aan weerszijden bij dezelfde rondwandeling horen of niet. Het kan dan wel kijken of ze dezelfde kleur hebben, maar, zoals ik al eerder opmerkte, lopen gelijkgekleurde routes vaak akelig dicht bij elkaar. Ook kun je met optie 2 geen incomplete work-in-progress relaties aanmaken. Immers als je ter plekke rondwandelt heb je nog geen idee wat het volgende of het vorige knooppuntnummer zal worden. Anders dan bijvoorbeeld fietsroutes staat dat niet op de paaltjes.

multimodaal wrote:

Optie 1 (in rwn alleen lussen, geen aparte knp-knp): Volgens mij is een van de genoemde bezwaren -naast de validiatie- dat deze manier van invoeren niet overeenkomt met hoe rwn's in de wiki zijn gedefinieerd en -wellicht nog belangrijker- dat dit geen arbitraire tekst is die met een simpele wiki-edit is aangepast, maar dat er al -In NL en daarbuiten- al duizenden kilometers RWN zijn ingevoerd volgens de knooppunt-knooppunt-afbakening. Ik deel het oordeel van Dick dat dat dit de minst gewenste optie is.

Bezwaar 1 (validatie) is eenvoudig op te lossen door VMarc ietsjes te veranderen. IF NOT rondje THEN do huidige check ELSE check iets anders. Juist door extra relaties te gaan verplichten maak je niet alleen het taggen maar ook de validatie alleen maar ingewikkelder.
Bezwaar 2 (klopt niet met wiki tekst): enige 2 zaken die niet met de wiki (https://wiki.openstreetmap.org/wiki/Fie … tennetwerk) kloppen is: het gebruik van ref (ik ben echter nog nooit tegengekomen wat dan die problemen met rendering zijn; voordat Dick mijn relaties aanpastte stond er ook gewoon een ref op de rwn relaties en ik heb nog nooit gezien dat dat render problemen gaf bij welke renderer ook) en het gebruik van name (niet aanbevolen maar dus ook niet verboden). Ik snap dan ook niet waar je ziet dat optie 1 zo afwijkt van wat op de wiki staat. Kun je een citaat geven uit de wiki waaruit zou blijken dat optie 1 niet correspondeert met de wiki tekst?
Bezwaar 3 (er is al veel ingevoerd): Dick heeft de rondjes behouden en ze alleen omgetagd naar lwn. Je kunt dus zeer eenvoudig in josm alle rwn relaties (in Oost-Nederland) selecteren en verwijderen en vervolgens de lwn-relaties weer terugzetten op rwn. Kan binnen een paar minuutjes. De rest van het land (waar ze niet met de rondjes werken, maar met de manier van het fietsknooppuntensysteem) kan gewoon onveranderd blijven.

dvdhoven · 2017-11-27 10:00:02

richardbrinkman wrote:

Bezwaar 3 (er is al veel ingevoerd): Dick heeft de rondjes behouden en ze alleen omgetagd naar lwn. Je kunt dus zeer eenvoudig in josm alle rwn relaties (in Oost-Nederland) selecteren en verwijderen en vervolgens de lwn-relaties weer terugzetten op rwn. Kan binnen een paar minuutjes. De rest van het land (waar ze niet met de rondjes werken, maar met de manier van het fietsknooppuntensysteem) kan gewoon onveranderd blijven.

Kennelijk lees je niet goed. Ik heb al aangegeven dat ik nooit akkoord ga met het verwijderen van rwn relaties. Dat is ruim 1200 km aan werk. Ga maar na hoeveel uren veldwerk en hoeveel uren binnenwerk daar in zit. Degene, die het waagt om dat te doen, is gelijk kandidaat voor vandalisme melding bij de DWG en ik zal al die verwijder changesets per direct reverten.

Ik begrijp werkelijk niet hoe je met droge ogen kunt beweren dat je zo even tussen neus en lippen door ruim 1200 km aan routerelaties moet verwijderen om vervolgens de grootste chaos over te houden.

Verder dekken momenteel de rondjes het rwn niet en omgekeerd.
In Salland en Achterhoek is veel meer rwn dan lwn ingevoerd en ook in Twente is er geen dekking. Zal ook niet snel komen.
Verwijderen van het rwn zal dus leiden tot zeer groot informatieverlies.
Kijk nu eens eerst wat verder dan je eigen hoekje Twente.

Maar nogmaals - zum mit singen - IK GA NOOIT AKKOORD MET HET VERWIJDEREN VAN MIJN EN ANDERMANS RWN WERK!!!!!!!
Live the dream, maar kom dan maar weer terug op aarde en zie eindelijk in dat jouw geliefde rondjes nooit rwn zullen worden.

Verder dekken de rondjes bij lange na niet het hele netwerk. De verbindingsroutes zijn er ook nog.

Ook voldoen de rondjes niet aan one feature. Er liggen soms tot wel 4 of rondjes op een weg of een pad. Welke is dan de knooppuntrelatie?

En ook Marc zal zijn tool niet aanpassen.
Die tool is gebouwd op de consensus over hoe knooppuntenrelaties in OSM worden ingevoerd en behandeld.

En nu optie 5:
Stoppen met deze discussie en gewoon lekker gaan invoeren.
De een met zijn routes in lwn en de ander met zijn rwn relaties
Zijn we allemaal lekker bezig.
Het gaat nog jaren duren voor de netwerken zijn ingevoerd en zeer waarschijnlijk wordt dat nooit bereikt.
Kijk maar eens op de kaart welke fractie van Twente is ingevoerd.

Last edited by dvdhoven (2017-11-27 10:12:09)

dvdhoven · 2017-11-27 18:19:57

multimodaal wrote:

Vanuit dat perspectief zou optie 2 weer het meest automatisch beide niveau's aanpassen:
als je daar de knp-knp's zo aanpast dat er een nieuw knooppunt is ingevoegd en de kleuren goed toekent aan de knp-knp-delen, dan zijn beide niveau's in een keer aangepast.
Ook lijkt het me (als leek op gebied van informatica) met optie 2 het makkelijkst om -als alles goed is ingevoerd..- in keer een kaart te maken die aangeeft dat er verschillende kleuren aan een bepaald wegsegment hangen. Anders zal je denk ik moeten zoeken welke verschillende routes er allemaal over een gegeven weg lopen en die informatie bij elkaar brengen voor je rendering, of is dat niet complexer dan domweg de kleuren drie renderen die in een variabele van die weg zijn opgenomen?

Het is in de basis redelijk eenvoudig om aan een rwn relatie een kleur toe te voegen. Dat kan met de colour tag.
Problemen zijn dan meerdere kleuren en dubbele kleur. Hier in Deventer heb je sinds kort een route, die heeft groen-wit als kleur, dus net zo als een lange afstandsroute rood-wit heeft en een streek-pad rood-geel. Verder zijn er routes als de Sallandse Zandloper met ? en het Schipbeekpad en het Reggepad met blauw-wit.
En wat doe je met verbindingsroutes, die grijs hebben maar een lange afstandspad begeleiden?
Kijk maar eens noord van Deventer, http://www.openstreetmap.org/note/10959 … 1&layers=N , vanaf het landgoed Kranenkamp loopt vanaf J15 een grijze route samen met het Marskramerpad naar E58, tussen E58 en E59 loopt de rode route, van E59 naar M25 is het weer grijs, na M25 krijg je een gele route.

richardbrinkman · 2017-11-27 20:15:15

dvdhoven wrote:

Ik heb al aangegeven dat ik nooit akkoord ga met het verwijderen van rwn relaties. Dat is ruim 1200 km aan werk. Ga maar na hoeveel uren veldwerk en hoeveel uren binnenwerk daar in zit. Degene, die het waagt om dat te doen, is gelijk kandidaat voor vandalisme melding bij de DWG en ik zal al die verwijder changesets per direct reverten.

Ik snap dat er heel veel werk in is gaan zitten. Mijn hele punt is nu juist dat het dubbel invoeren van dingen zo gruwelijk veel tijd kost en dat dat niet nodig is.

dvdhoven wrote:

Verder dekken momenteel de rondjes het rwn niet en omgekeerd.

Ook dit is precies het punt dat ik wil maken. Met twee parallelle netwerken krijg je ze nooit met elkaar gesynchroniseerd.

dvdhoven wrote:

Ook voldoen de rondjes niet aan one feature. Er liggen soms tot wel 4 of rondjes op een weg of een pad.

Klopt, maar dit zijn wel 4 features. Op elk paaltje zie je dan ook 4 vierkante bordjes. Je ziet dus in werkelijk 4 features, dus kun je die ook als 4 elementen mappen. Een weg kan prima bij meerdere features horen. Over sommige wegen leiden nu eenmaal meerdere fiets, wandel, MTB en ruiterroutes. Dit zijn wel degelijk meerdere features.

dvdhoven wrote:

En ook Marc zal zijn tool niet aanpassen.
Die tool is gebouwd op de consensus over hoe knooppuntenrelaties in OSM worden ingevoerd en behandeld.

Consensus hoort in de wiki thuis. Ik heb nu al verschillende keren gevraagd om daaruit te citeren, maar niemand die mij kan wijzen op specifieke gedeeltes uit de wiki waarom optie 1 niet goed zou zijn.

dvdhoven wrote:

En nu optie 5:
Stoppen met deze discussie en gewoon lekker gaan invoeren.

Jammer dat je niet open staat voor verdere discussie. Gelijk dreigen met reverts en mij aangeven bij de DWG werken niet heel motiverend. Zelf eerst al mijn werk massaal omtaggen en als ik daar dan vraagtekens bij zet, gelijk met reverts en met de DWG gaan dreigen zelfs nog voordat ik iets van jouw werk heb aangepast. De toon die jij soms aanslaat staat mij tegen. Met boos worden en met hoofdletters gaan schreeuwen is niet de manier om met de community te overleggen. Neem een voorbeeld aan multimodaal. Die stelt eerst wat opties voor en geeft de voors- en tegens weer. Wij willen beide eerst consensus voordat we dingen gaan veranderen.

Last edited by richardbrinkman (2017-11-27 20:18:23)

multimodaal · 2017-11-28 02:10:41

Voor mij is het redelijk makkelijk om dit wat afstandelijker te blijven zien omdat ik in de wandelnetwerken in het oosten nog geen tijd heb geïnvesteerd en het echt een regionale bijzonderheid is. Ik snap dat als je ergens vele uren werk in hebt zitten dat het dan eerder gevoelig ligt, dat heb ik zelf ook (hoewel ik hier veel minder tijd aan besteed).

Tegelijk ligt er een praktische vraag open om te beantwoorden (dat was voor mij de aanleiding, ik wilde wat data invoeren en weet niet hoe ik dat het beste kan doen) en is het ook wel een mooie puzzel, ingegeven door een inrichting van de knooppunten die afwijkt van wat landelijk gebruikelijk is (en die ik stiekem op zich qua concept wel aardig, en de knooppunten waren zelf ooit ook nieuw).

Maar ondertussen is er al enorm veel werk verricht op de klassieke methode en zitten wij met de hoofdbrekers en zijn we aan de ene kant gebaat bij consistentie en wil je het aan de andere kant niet moeilijker maken dan het is (ik moet me er altijd weer toe zetten om verder te gaan met invoeren knooppuntnetwerken..)

Over de quote van de Wiki, ik doelde op deze:

https://wiki.openstreetmap.org/wiki/Fie … tennetwerk (laatste aanpassing: 2015)

Wiki Fietsroutes#Regionale_Fietsroutes_.2F_Fietsknooppuntennetwerk wrote:

Het Fietsroutenetwerk bestaat uit een verzameling afzonderlijke relatie tussen twee netwerkpunten.
[...] De route tussen twee nodes wordt aangegeven met een relaties met als members de nodes en ways:

Maar zoals gezegd vindt ik het zelf zwaarder wegen dat dit niet alleen uit de wiki-tekst blijkt, maar ook volgt uit de context op OSM: het wordt in de praktijk ook zo gedaan (knp-knp), iedereen kan immers snel achter die zin in de wiki toevoegen "of een rondje" (-:

Tegelijkertijd kan hier ook evolutie plaatsvinden, zeker in het licht van nieuwe ontwikkelingen. En daar hink ik zelf op twee gedachten. Eigenlijk vindt ik -als ik me een virtuele situatie voorstel waarin er nog geen netwerken waren ingevoerd- het wel elegant om het netwerk te vullen met rondjes, die komen overeen met wat daar in het veld het meest kenmerkend is en mappen makkelijk. Als het mooi rondgaat zou het al snel goed kunnen zijn in de validatie (evt een variabele opnemen op de knooppunten die je tegen moet komen), aangevuld met verbindingsroutes op de klassieke manier? Maar de praktijksituatie is anders met al wel heel veel ingevoerde klassieke knooppuntroutes (en nog veel werk te doen, zowel in onderhoud als uitbreiding), en daar vind ik dat Dick ook een punt heeft.

Eerder merkten we dat de superrelatie per saldo op de meeste stemmen van jullie kan rekenen. Als ik zelf veel zou mappen in het oosten, dan zou dat niet mijn eigen favoriet zijn (lijkt me lastig), maar dat doe ik niet en zoals gezegd pas ik me in dit geval graag aan.

Zal ik een paar proefstukjes met een superrelatie doen op basis van mijn verzamelde data om eens te kijken hoe dat uitpakt (invoeren, validatie, rendering?

Zoiets? (concrete verbetersuggesties zijn welkom) :

(1) klassieke knp-knp relatie:

type=route; network=rwn
is lid van bestaande relatie type=network ; network=rwn ( https://www.openstreetmap.org/relation/1341166 )

aangevuld met

(2) superrelatie voor klassieke knp-knp relatie:

type=route; network=lwn
(een superrelatie hoeft toch niet per se ook een type=superroute te hebben als ik de wiki zie, eerst kijken of de eenvoudige weg werkt?)
deze is net als (1)- lid van het de relatie rwn type=network ; network=rwn , want zij vormen net zo goed als de knp-knp verbindingen het netwerk

(Vmarc lijkt alleen rnw's te selecteren en niet zozeer alle leden van het netwerk als ik de info lees, maar daar gaan we achterkomen?)

Hoe onderscheiden we de vele lussen met dezelfde kleuren in hetzelfde netwerk?
-Misschien met een ref= met daarin de kleur en het laagste knooppuntcode dat (tot dan toe, work in progress is idd van belang bij veldwerk) bent tegengekomen in het netwerk

-Nog een note= (zoals bij klassieke knp-knp) met de nummers van de knooppunten die in de lus zouden moeten zitten, startend bij het knooppunt met de laagste code (of startpunt met naam die het eerst in het alfabet zit?), zodat je kan checken of alle nodes met knooppunten nog in de route zitten (indirect via de relaties-> wegen die lid zijn) ?

vmarc · 2017-11-28 07:54:00

Vmarc lijkt alleen rnw's te selecteren en niet zozeer alle leden van het netwerk als ik de info lees, maar daar gaan we achterkomen?

Inderdaad, momenteel worden enkel netwerktypes rwn en rcn verwerkt (geen lwn). Relaties die verzamelingen zijn van netwerk relaties worden momenteel expliciet buiten de analyse gehouden.

Laat de keuze over hoe te taggen liefst niet te veel afhangen van hoe de analyse op http://osma.vmarc.be/ vandaag werkt. Ik sta open voor aanpassingen, bijvoorbeeld ondersteuning van rwn lus-relaties (verzameling van rwn route relaties) binnen rwn netwerk relaties, of iets anders waar concensus over bereikt wordt.

richardbrinkman · 2017-11-28 07:58:45

Wiki Fietsroutes#Regionale_Fietsroutes_.2F_Fietsknooppuntennetwerk wrote:

Het Fietsroutenetwerk bestaat uit een verzameling afzonderlijke relatie tussen twee netwerkpunten.
[...] De route tussen twee nodes wordt aangegeven met een relaties met als members de nodes en ways:

Strikt genomen staat hier niet dat die twee netwerkpunten verschillend moeten zijn. Sterker nog voor een rondje waar je slechts 1 knooppuntnummer tegenkomt, moet je het wel als rondje taggen.

multimodaal wrote:

Hoe onderscheiden we de vele lussen met dezelfde kleuren in hetzelfde netwerk?
-Misschien met een ref= met daarin de kleur en het laagste knooppuntcode dat (tot dan toe, work in progress is idd van belang bij veldwerk) bent tegengekomen in het netwerk

Even voor de duidelijkheid. De bedoeling van (2) is toch dat je per rondwandeling één lwn-superrelatie maakt met als leden de rwn-knooppunt-knooppunt relaties? Dan bestaat het onderscheid tussen gelijk gekleurde lussen uit het feit dat het verschillende relaties zijn.

Een proef kan denk ik geen kwaad. Dan krijg je feeling met hoeveel werk het is, hoe het overal rendered, hoe relatie-checkers ermee omgaan en hoe makkelijk/moeilijk het is om met een editor als josm het in te voeren en te valideren. Ik zou het wel in overleg doen met Dick, zodat hij het niet, zoals hij aankondigde, alles direct gaat reverten.

multimodaal · 2017-11-30 01:23:03

@(V)Marc: Dank voor je reactie, je bereidwilligheid om mee te denken over actualisatie en voor de nu ook al bijzonder handige site!

@overigen:
Heb twee lwn-proeflussen gemaakt obv optie 4 (superrelatie):
eentje waar de volgorde waarin een relatie-lid gelezen moet worden wel met forward/backward expliciet is gemaakt en eentje waar dat niet het geval is
http://www.openstreetmap.org/relation/7769722
http://www.openstreetmap.org/relation/7769965

Heb deze zowel aan het rwn-netwerk als aan een apart lwn-netwerk toegevoegd

Wat direct al opvalt:

Rendering
-Op OSM.org wordt de superrelatie niet gevisualiseerd (zie bovenstaande links), terwijl als je op een van de leden klikt (een relatie die zelf weer ways als leden heeft), dat wel gebeurt (bijvoorbeeld http://www.openstreetmap.org/relation/7769719 )

-Waymarkedtrails toont beide lwn-routes wel gewoon:
https://hiking.waymarkedtrails.org/#?ma … 226!6.4738

-Maar ook de aangepaste Hiking-versie van d=het BTM-kaartje (oorspronkelijk van Ligfietser) en mijn 'eigen' renderer (gemaakt met veel programmeerhulp, ik ken dus niet de fijnste technische details) krijgen de lwn-superrelatie niet gevisualiseerd (wel de gewone LWN die er al liep):
http://www.openkaart.net/wandel/lvww-ov … erlays=lwn
http://www.openkaart.net/wandel/hiking- … FTFFFFFFFF

-Validatie
De bovenstaande twee routes staan op moment van schrijven nog niet in Vmarc,
maar die lijkt in ieder geval niet blij om relaties in een relatie (obv aanzet van aanzet van andere route eerder vanavond - daar had ik daar door combineren niet een hele lus gelopen):

http://osma.vmarc.be/nl/network/1341166

NetworkExtraMemberRelation Found unexpected member 2810239 of type "relation" in network relation. Expected valid route relation or network node only.

Voor de bovenstaande twee routes zal morgenochtend denk ik ook wel zo'n boodschap verschijnen

-De OSM Relation analyzer lijkt hier vooralsnog ook weinig mee te kunnen
http://ra.osmsurround.org/analyzeRelati … noCache=on

Unknown state
This relation contains no ways to build a graph.

Invoeren
Nu ik ze ga invoeren begin ik die gekleurde lussen door al het overlappen opeens een stuk minder sympathiek te vinden, vooral als je compleet zou willen zijn
Heb me nu dan ook maar beperkt tot een lus per keer ,maar je komt steeds meer tegen onderweg..

Als je alleen veldwerk hebt en geen kant en klare kaart ernaast als referentie voor het totaalplaatje is het toch wel erg lastig (en veel data verzamelen, meer dan bij knp-knp).

Wat ik vooral lastig vindt is dat je in JOSM in het relatievenster niet ziet of de boel mooi aansluit als je relaties invoert als lid van je relatie, terwijl dat met ways mooi wordt gevisualisserd, waardoor gaten, overlappingen en omdraaiingen gelijk opvallen.

Genoeg voor nu, wellicht kennen jullie andere validators en hebben jullei nog ideeën

richardbrinkman · 2017-11-30 09:19:46

Dank voor het uitvoeren van de test. Het heeft de nodige handige informatie opgeleverd.

De punten die je noemt onder rendering en validatie zou je af kunnen doen als "dat is de taak van de renderer / validator en niet van de mapper". Echter, ken ik vrijwel geen enkele tool die iets met netwerk relaties doet. Je kunt moeilijk verwachten van al die software bouwers dat ze hun tools en renderers maar moeten ombouwen, omdat wij als mappers een ingewikkeld systeem hebben bedacht van wegen en knooppunten in relaties ((1) knp-knp) in relaties ((2) lwn lus) in relaties ((3) lwn superrelatie), waarbij (1) dan ook nog eens zit in een andere relatie ((4) rwn superrelatie). Zo'n systeem is voor de doorgewinterde mapper zoals wij nog wel te bevatten, maar voor de gemiddelde mapper gaat dat vrees ik boven z'n pet. Het kan gewoon op teveel manieren onbedoeld stukraken.

Ik vind daarom je bevindingen onder je kopje "invoeren" ook de belangrijkste bezwaren tegen optie 4. Als je bij het invoeren al niet kan zien of je alles correct hebt ingevuld, dan gaan er al bij het invoeren dingen fout, vooral omdat je aan veel dingen moeten denken omdat het zo ingewikkeld in elkaar steekt.

Overigens ben ik nog wat andere bezwaren tegen het knp-knp-systeem tegengekomen:
1. begin stukjes die beginnen vanaf een punt zonder knooppuntnummer naar de rondwandeling kunnen niet gemapt worden (immers het loopt niet van knooppunt naar knooppunt), terwijl ze in het veld wel met bordjes zijn gemarkeerd. Zie bijvoorbeeld het paarse beginstukje: https://hiking.waymarkedtrails.org/#?ma … 854!6.8906
2. rondjes met slechts 1 of 2 knooppunten kunnen niet gemapt worden. Voorbeeld, hoe zou je de gele route (https://hiking.waymarkedtrails.org/#route?id=2571522) moeten taggen met enkel knp-knp stukjes? Je ziet hier dat de onderste X11-X14 wel gemapped is maar het bovenste X11-X14 niet. Twee maal een relatie X11-X14 opnemen lijkt me erg verwarrend. Als je slechts 1 knooppuntnummer in een lus hebt zitten, ben je helemaal de sjaak.
3. splitsingen gebeuren soms ook zonder dat op dat punt een knooppuntnummer staat. Dit is met mappen van enkel knp-knp-relaties niet te mappen (zonder overlap). Kijk bijvoorbeeld naar de rode en groene routes die tussen Y78 en Y79 lopen (https://hiking.waymarkedtrails.org/#?ma … 428!6.7281)

dvdhoven · 2017-11-30 09:35:57

Elk startpunt heeft een knooppunt. Dus piefjes kunnen ook getekend worden.
In het voorbeeld gaat het om het startpunt Smalenbroek met knooppunt Z87 volgens de nieuwste kaart.
Buiten moet nog gekeken of dat klopt. De nieuwste kaarten blijken niet bepaald foutloos

Tussen 2 knooppunten kunnen meerdere relaties lopen, dat komt vaker voor ook in het rcn. Voorbeeld: In Zeeland heb je routes binnendiijks en buitendijks.
Ik heb gisteren nog "dubbele" routes ingetekend, gaat prima.
Je ziet buiten aan de bordjes of de paaltjes wel hoe je moet lopen.
Je zit zelf in de IT, dus weet je dat onder water met ID's wordt gewerkt. Die relaties hebben een verschillend ID. Dus de software kan er prima mee omgaan.
De naam van de relatie staat in een note tag. En note tags worden niet gerenderd. Dat is heel slim bedacht toen men met het rcn begon. Dan zie je op de kaart geen relatienamen verschijnen. Dus ook daar geen verwarring.

Een rondje vanuit 1 knooppunt naar hetzelfde knooppunt is een probleem, dat klopt. Dat moet je oplossen met een virtueel knooppunt. Niet de fraaiste oplossing maar het kan wel.

Overlappen zijn geen probleem of fout van het knooppuntensysteem.
Dat is pure baggerconfiguratie. Als de netwerkbeheerder verzuimt op die plekken een keuzepunt te leggen, is dat zijn fout. Niet van het knooppuntensysteem.
Als je de gekleurde routes gaat gebruiken als netwerkrelatie, heb je hier net zo goed een probleem mee. Ook dan mis je het keuzepunt.
Bij de manier van invoeren van het knooppuntensysteem in OSM, hebben we er overigens geen last van. Je legt gewoon twee relaties over elkaar heen.
In het rcn hebben we daar ook last van. Met name in Zuid Limburg waar vaak 2 knooppuntrelaties kilometers gelijk op gaan om dan ergens te splitsen zonder een knooppunt. Het ergste geval is ergens tegen de Belgische grens aan waar 5 knooppuntroutes over elkaar heen liggen.

Van overlappen hebben we ook last als 2 netwerken over elkaar heen liggen.
Achterhoek en Salland overlappen elkaar en hebben ieder hun eigen keuzepunten. Ja, ook dat is een kwestie van niet afstemmen tussen de beheerders. En wat buiten krom is, kun je binnen niet meer rechtbuigen.
Dus in dit geval worden de keuzepunten aan zowel Salland en de Achterhoek toe gekend.

Het knooppuntensysteem is geen vervanging van de gekleurde routes. Het is er complementair aan. Het geeft de basisrelaties aan tussen de knooppunten. Niet meer en niet minder. In feite de atomaire deeltjes van het systeem. En vanuit die deeltjes kun je zaken opbouwen, zoals routes. En je kunt er ook prima GPS tracks mee maken.
Als je een wandeling plant via overstappen van de ene gekleurde route op een andere, dan kom je met het probleem te zitten, dat je bijv. via Waymarked trails alleen een complete GPS track kunt krijgen van de hele route. Vervolgens kun je dan met bijv Basecamp of Mapsource die tracks in stukjes gaan knippen en dan weer stukjes aan elkaar gaan plakken.
De stap van het knippen kun je je besparen door GPS tracks van de onderliggende knooppuntrelaties te maken en die aan elkaar te verbinden. Dat zou een planner applicatie ook kunnen doen, maar helaas is zo'n planner - voor zover ik weet - nog niet.
Er is wel een planner van Waypoint, die werkt met tracks van knooppunt naar knooppunt, net zoals in OSM de knooppuntrelaties, maar volgens mij ligt het werk daaraan stil.

Ik heb zelf zo'n ruime 30 jaar ervaring in IT, voornamelijk als developer en 2e lijns ondersteuner.
Ik heb vaker zitten denken hoe om te gaan met die gekleurde routes.
Als ik een planner op basis van die routes zou moeten maken, dan zou ik als eerste de routes opdelen in hun samenstellende delen, de stukken tussen de keuzepunten.
Als ik daarover nog wat langer nadenk, wordt ik al gillend gek.
Immers er is geen enkel verband vast gelegd tussen de route en de keuzepunten waar hij langs loopt. De keuzepunten zijn niet in de route vast gelegd, dus route en keuzepunten kunnen compleet out of sync raken. Ook kunnen de wegen wel doorlopen over de keuzepunten heen. Allemaal punten, die het lastig maken om de route als knooppuntroute te gebruiken. En er zal vast nog wel veel meer zijn.
Daarom is het - volgens mij - handiger om de relaties tussen de knooppunten apart vast te leggen. Dan heb je nog wel de problemen, die jij schetst, maar die heb je bij de gekleurde routes ook. Ook als je die chopt in de kleine stukjes, krijg je het probleem, ga ik linksom of rechtsom als de route rondloopt tussen 2 keuzepunten.
Het grote punt is en blijft, dat men verzuimt heeft bij de keuzepunten een verwijzing naar het volgende keuzepunt op te nemen. Een groot manco naar mijn idee en ik begrijp ook niet waarom de bedenker daarvoor gekozen heeft.

Ik vind het uitermatig prettig om met de losse relaties te werken. Dan heb je geen grote moppen zoals een hele route.
En je kunt het stukje bij beetje doen. Je kunt ook kleine gebiedjes doen.
En mijn idee is nog steeds om gekleurde routes te maken vanuit de netwerkrelaties. Het mooist is een superrelaties, maar als dat niet lukt, kan de gewone methode ook nog. Je pakt een netwerkrelatie, zet het blok wegen erbuiten, en hangt die in de routerelatie van de gekleurde route. Eventueel nog omkeren. Klaar. Volgende netwerkrelatie. Groot voordeel tov rcn is, is dat je geen forward/backward hebt.
Zo doe ik het bij rcn ook als er fkp omgelegd en LF routes omgelegd moeten worden. En zo moeten er ook nog fietsroutes worden gemaakt die het rcn volgen.

Last edited by dvdhoven (2017-11-30 11:58:03)

JanWandelaar · 2017-11-30 11:00:23

Helaas komen de genoemde situaties ook in de knooppunt netwerken voor.

1. begin stukjes die beginnen vanaf een punt zonder knooppuntnummer naar de rondwandeling.
Dit komt voor vanaf bv. een station of camping.
De validaties is een probleem, maar het is zoals de werkelijkheid is.
Soms zie je dat later nog een knoopppunt paaltje toegevoegd wordt.

2. rondjes met slechts 1 of 2 knooppunten kunnen niet gemapt worden.
Dit komt af en toe voor. Een rondje om een vijver terug naar het beginpunt.
Of beide richtingen om de vijver zijn gemarkeerd. Dit levert dan 2 relaties op met hetzelfde begin en eind punt.

3. splitsingen gebeuren soms ook zonder dat op dat punt een knooppuntnummer staat. Dit is met mappen van enkel knp-knp-relaties niet te mappen (zonder overlap).

Dit komt regelmatig voor. Soms wordt het later verbeterd met een nieuw knooppunt paaltje.
Hier gebruik ik de overlap om het beter controleerbaar te houden.
Bij online routeplanners zie ik een extra knooppunt zonder nummer (wat handiger is voor het invoeren en onderhoud).
Liever zou ik ook naar een virtueel knooopppunt overgaan, maar dan moet hier wel consensus over bestaan.

multimodaal · 2017-11-30 22:49:51

dvdhoven wrote:

Als je een wandeling plant via overstappen van de ene gekleurde route op een andere, dan kom je met het probleem te zitten, dat je bijv. via Waymarked trails alleen een complete GPS track kunt krijgen van de hele route. Vervolgens kun je dan met bijv Basecamp of Mapsource die tracks in stukjes gaan knippen en dan weer stukjes aan elkaar gaan plakken.
De stap van het knippen kun je je besparen door GPS tracks van de onderliggende knooppuntrelaties te maken en die aan elkaar te verbinden. Dat zou een planner applicatie ook kunnen doen, maar helaas is zo'n planner - voor zover ik weet - nog niet.
Er is wel een planner van Waypoint, die werkt met tracks van knooppunt naar knooppunt, net zoals in OSM de knooppuntrelaties, maar volgens mij ligt het werk daaraan stil.

Zie https://forum.openstreetmap.org/viewtop … 38#p675138 voor iets dat misschien van pas kan komen

(nadere reactie volgt later)

Hans Erren · 2017-12-10 19:03:27

Ik heb een pad bij de watermolen van haaksbergen geedit, kan iemand die van wandelnetwerken weet kijken of ik niks gebroken heb?
https://www.openstreetmap.org/way/373900429

dvdhoven · 2017-12-10 20:53:09

Op het pad zelf liggen geen routes en op de Watermolenweg is alles in orde

Hans Erren · 2017-12-10 21:39:32

Bedankt voor de controle. Het pad was dubbel en de aansluiting met de weg was fout, dus hele pad maar verwijderd.
Deze is wel goed
https://www.openstreetmap.org/way/142177344

Last edited by Hans Erren (2017-12-10 21:40:04)

escada · 2017-12-11 07:17:25

Voor zover ik weet worden in Vlaanderen de lussen en de netwerken gescheiden gehouden.
Voor de lussen gebruiken we lwn, voor de netwerken rwn.
In de lussen stoppen we net zoals voor de netwerken de wegen en de paden. Aangezien een lus los van een netwerk kan evolueren, lijkt het mij logischer om geen routes van de ene in de andere te plaatsen.

Nu is het wel zo dat in Vlaanderen er nog hele gebieden zijn waar geen netwerk is vastgelegd, en er enkel lussen zijn.

Last edited by escada (2017-12-11 07:17:37)

dvdhoven · 2017-12-11 07:51:31

Hans Erren wrote:

Bedankt voor de controle. Het pad was dubbel en de aansluiting met de weg was fout, dus hele pad maar verwijderd.
Deze is wel goed
https://www.openstreetmap.org/way/142177344

Routes zien er allemaal goed uit.

Hans Erren · 2017-12-18 18:28:39

Kan iemand met verstand van wandelnetwerken naar deze knoop kijken?
https://www.openstreetmap.org/node/5290445918
Ik heb een brug over het water gemaakt maar de gele route gaat nu heen en weer over de brug.
https://www.openstreetmap.org/relation/ … 337/6.7263
Kan iemand knoop 5290445918 aan de noordkant van de brug leggen met behoud van de relaties?

Last edited by Hans Erren (2017-12-18 18:29:10)

dvdhoven · 2017-12-18 20:08:12

Een en ander is hersteld.
Het was een verwarrende boel waarbij een pad, een pad op een brug en een track op elkaar lagen. Alles was verder verknoopt met landuses en de brug ook nog met het water.
Paden en wegen mogen niet met landuses verknoopt worden. Bruggen mogen niet met het onderliggende water verknoopt worden.
Ik heb nu het pad en de track weg gehaald, het pad op de brug laten liggen en alle relaties en dat was een hele bundel, hersteld.

Mijn dringend advies wees voorzichtig met het inleggen, je kunt snel zaken aan elkaar verknopen en ook snel wegen tegen zichzelf in op elkaar plakken, wat hier ook gebeurt was. Doe telkens kleine stukjes en check of alles nog klopt.
En als eenmaal de boel als een klont aan elkaar zit, is het uitermate lastig om de zaak te herstellen.

Hans Erren · 2017-12-18 20:53:30

Hartelijk dank! Ik werk met ID en die snapt heel gemakkelijk aan landuse polygonen.

Peter Elderson · 2018-10-18 11:04:23

Ik heb deze hele diskussie gelezen. Had ik al eerder gedaan, maar toen snapte ik driekwart van de punten niet. Nu wel, heb inmiddels veel ervaring opgedaan en ik snap zelfs de situatie in de Achterhoek....

Maar ik mis nog een konsensus die je in een wiki kan vastleggen. Omdat ik nu min of meer de wandelwiki doe en daarin de tag-afspraken voor NL staan, zou ik het wel fijn vinden als we een tekst kunnen maken waar iedereen zich in kan vinden.

Peter Elderson · 2018-10-18 12:53:30

Om een voorzet te doen over een paar bediskusieerde punten:

Tekstvoorstel wandelwiki

Themaroutes met blijvende eigen beschrijving en beheer, maar geen eigen markering op de weg:
Niet in OSM, behalve als ze als permanente knooppuntroute beschreven zijn.

Permanente knooppuntgebaseerde routes: Netwerk kan lwm, nwn, of zelfs iwn zijn, maar niet rwn dat is gereserveerd voor knooppunttrajekten en knooppuntnetwerken. Er moet vast beheer zijn en een website of geldend boekje waarin de knooppuntenreeks beschreven staat, en liefst hier en daar een infopaneel op de weg bij een opstappunt (trailhead, TOP, toegangspoort).
NB Het komt veel voor dat er toch delen zijn die niet of niet eenduidig via knooppunten lopen. Aanlooproutes, lusjes, er bestaan meerdere routes tussen twee knooppunten. In dat geval maak je van de extra delen aparte routerelaties, waarvan het netwerktype overeenkomt met de route waar ze onderdeel van zijn.

Tot netwerk verknoopte langere routes: Worden beschouwd als knooppuntgebaseerde routes, ook als ze op de weg hun eigen markeringen gebruiken ipv een aparte knooppuntnetwerkmarkering.
Dus de langere routes zijn lwn (bv rondwandelingen, dagwandelingen) opgebouwd uit een serie knooppuntrelaties (die zelf rwn zijn). De markering van de langere route tag je op de routerelatie.

NB Het is niet aanbevolen om een superroutenetwerk te maken van lokale routes die op zich al uit knooppunttrajekten opgebouwd zijn. Alle kruispunten en gezamenlijke routedelen zijn immers al opgenomen in het knooppuntennetwerk. Als je een route wil maken samengesteld uit verschillende delen van verschillende langere wandelingen, dan plan je die via de knooppunten. Een gpx van zo’n geplande mengroute zou door een knooppuntenplanner moeten worden geproduceerd, zoals dat geldt voor alle knooppuntenroutes. Bijvoorbeeld http://www.wandelen123.nl/ biedt deze mogelijkheid.

JanWandelaar · 2018-10-18 15:22:44

Peter Elderson wrote:

Permanente knooppuntgebaseerde routes: Netwerk kan lwm, nwn, of zelfs iwn zijn, maar niet rwn dat is gereserveerd voor knooppunttrajekten en knooppuntnetwerken. Er moet vast beheer zijn en een website of geldend boekje waarin de knooppuntenreeks beschreven staat, en liefst hier en daar een infopaneel op de weg bij een opstappunt (trailhead, TOP, toegangspoort).

Een goed voorstel om hiervan een wiki te maken!

In mijn omgeving zijn er (permanent gemarkeerde) themaroutes die via knooppunten lopen. Naast de knooppuntmarkering is er dan een extra markering aangebracht (http://www.landschaphorstaandemaas.nl/wandelen).
De meeste zijn "ommetjes" en er is een meerdaagse wandeling.

In de wiki zou ik dan graag een uitgebreidere beschrijving erbij zien (een voorbeeld helpt ook).
De vragen die nu bij de korte tekst heb:
- Bevat de route alleen de routes (van het knooppunten netwerk) of ook de knooppunten?
- Wordt het voorgestelde startpunt opgenomen en hoe?

Announcement

#26 2017-11-26 21:21:06

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#27 2017-11-26 23:01:02

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#28 2017-11-27 08:42:02

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#29 2017-11-27 10:00:02

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#30 2017-11-27 18:19:57

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#31 2017-11-27 20:15:15

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#32 2017-11-28 02:10:41

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#33 2017-11-28 07:54:00

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#34 2017-11-28 07:58:45

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#35 2017-11-30 01:23:03

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#36 2017-11-30 09:19:46

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#37 2017-11-30 09:35:57

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#38 2017-11-30 11:00:23

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#39 2017-11-30 22:49:51

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#40 2017-12-10 19:03:27

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#41 2017-12-10 20:53:09

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#42 2017-12-10 21:39:32

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#43 2017-12-11 07:17:25

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#44 2017-12-11 07:51:31

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#45 2017-12-18 18:28:39

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#46 2017-12-18 20:08:12

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#47 2017-12-18 20:53:30

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#48 2018-10-18 11:04:23

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#49 2018-10-18 12:53:30

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

#50 2018-10-18 15:22:44

Re: Wandelnetwerken oost-Nederland : samenhang rwn/lwn

Board footer