Wandelnetwerken oost-Nederland : samenhang rwn/lwn

Was laatst een paar dagen in het oosten van het land en zag daar wandelnetwerken die op zich -net als elders- gebruik maakten van knooppunten, maar waar de nadruk in de bewegwijzering (en afgeleide kaarten) veel meer lag op overlappende gekleurde rondwandelingen langs verschillende knooppunten. Op de (steeds langere…) lijst met nog te verwerken data staan ook de dingen die ik daar ben tegengekomen.

Die rondwandelingen bedekken samen het hele netwerk en het aardige is dat je daarmee minder knooppunten hoeft te onthouden (alleen maar: *“de gele route, tegen de klok in, dan overstappen op de groene en daarna weer de gele…” * ipv een trits van x knoopunten op volgorde).

Ik zag dat de knooppunt-knooppunt-relaties de tag rwn krijgen en dat snap ik op zich vanuit de noodzaak tot eenduidige validatie (en ik zou dat ook vooral zo willen laten, zie bijvoorbeeld http://www.openstreetmap.org/relation/1341166 ).

De gekleurde lussen die tot het wandelnet vormen zijn, om verwarring met de knooppunt-knoopunt-delen van het netwerk teruggezet van rwn naar lwn (terwijl ze eigenlijk van een groter schaalniveau zijn dan de knooppunt-knooppunt relaties, maar ook dat snap ik vanuit oogpunt van eenduidigheid en validatie). Zie bijvoorbeeld https://www.openstreetmap.org/relation/2808231/history

Dat tot een hoop losse lwn’s in de trant van “paarse route” (meerdere keren), rode route (meerdere keren) over verschillende netwerken.

Zou het een idee zijn om naast de rwn-versie (type=network, network=rwn) van het betreffende wandelnetwerk (met daarin alleen de klassieke knooppunt-knooppunt rwn-relaties) ook een lwn-versie van het netwerk (type=network, network=rwn) te maken met (met daarin alleen de gekleurde lwn-lussen) ?

Zo blijft de samenhang tussen die lussen behouden en kan je ook de lussen van het ene netwerk onderscheiden van de lussen van het andere netwerk.

Ben benieuwd naar jullie beeld.

De afspraak is om de gekleurde lussen ook gewoon met rwn te taggen en niet met lwn.
Zie http://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes#Tagging
De incomplete tweede relatie die je noemt (https://www.openstreetmap.org/relation/2808231/) is dus verkeerd getagged.
Iedere gekleurde rondwandeling (trajectrelatie) is een relatie met network=rwn. Alle relaties samen zitten vervolgens ook nog in een network relation die ook als network=rwn getagged wordt.
Het zou natuurlijk ook gek zijn als de paaltjes met het knooppunt bij een rwn wandeling horen maar de wegen tussen die paaltjes bij lwn.

In die wiki lees ik:

En dat is nu net de crux. De gekleurde routes laten zich niet op dezelfde manier taggen als fietsknooppuntnetwerken.

Er zijn in de wiki ook afspraken gemaakt waaraan een knooppuntrelatie moet voldoen.
Deze afspraken zijn indertijd voor het rcn gemaakt, maar omdat de meeste wandelnetwerken zijn opgezet op hetzelfde knooppuntprincipe als rcn, gelden de facto ook dezelfde afspraken voor het rwn.

Helaas heeft men in Overijssel menen te moeten afwijken van wat algemeen gebruikelijk is voor knooppuntroutes en de Achterhoek heeft dat helaas ook nog gevolgd en dat levert nu forse problemen op.

Een rwn en rcn route:

  • loopt van knooppunt naar knooppunt,
  • krijgt een note tag met de naam in de vorm van: laag knooppuntnummer-streepje-hoog knooppuntnummer
  • loopt in de volgorde laag knooppuntnummer naar hoog knooppuntnummer
  • loopt altijd tussen twee knooppunten in en niet meer dan twee

en deze gekleurde routes lopen over vele knooppunten heen, liggen in de onjuiste volgorde, hebben geen note tagt
Daarom zijn er aparte routes gemaakt, die tussen de knooppunten of keuzepunten lopen en wel voldoen aan de eisen, die aan rwn worden gesteld.

Als de gekleurde routes in het rwn worden geplaatst, levert dat een enorme hoeveelheid foutmeldingen in VMarc op en dat is niet wat je wilt.
Als je ze lid maakt van het netwerk Twente of Salland of … dat worden het beschouwd als vreemde elementen want de note tag, die de naam aangeeft, ontbreekt. Ook krijg je meldingen over bijkomende knooppunten en nog veel meer.
Die meldingen hebben we allemaal gehad, Twente was koploper met over de 1000 foutmeldingen. A67-A67 heeft een geweldige klus gehad aan het ontwarren van de kluwen en het weg werken van al die foutmeldingen en hij heeft een fantastische job gedaan.

Het belang van een overzicht van VMarc is, dat je kunt zien waar problemen met routes zijn en als er boven de 1000 oneigenlijke foutmeldingen zijn, is dat oorverdovende ruis, waardoor je de echte problemen niet meer ziet. En dat is iets wat je absoluut niet moet willen.

De huidige situatie in Overijssel en Achterhoek is niet ideaal, dat geef ik toe, maar je zit nu eenmaal met het gegeven, dat men daar buiten de pot heeft willen piesen. Buiten zie je alleen maar gekleurde pijlen en geen verwijzingen naar keuzepunten. Iets wat ik persoonlijk een totaal foute keuze vind. Je volgt een rode route en je hoopt maar dat je bij K42 uit komt. Weten doe je het niet.

Ik heb al van het moment af, dat ik met het rwn begon, zitten denken over hoe je de gekleurde routes gekoppeld krijgt aan de onderliggende knooppuntroutes.
Mijn idee is, om de gekleurde routes samen te stellen uit de knooppuntroutes.
Alleen heb ik begrepen dat dat momenteel niet ondersteund wordt door de diverse tools.
Maar voor mij is dat de mooiste oplossing.
Als er wat verandert, dan verander je de knooppuntroute en de gekleurde routes gaan vanzelf mee.

Maar ook daar zit een fors probleem. De knooppuntroutes lopen niet allemaal dezelfde kant op. Omdat een knooppunt route altijd van laag knooppunt naar hoog knooppunt loopt, kunnen de richtingen verschillen.

Voorbeeld:
Zie de kaart van VMarc voor Salland: http://osma.vmarc.be/nl/network-map/4740184
In Schalkhaar loopt de oranje route L20, L21, L15, L14 (nog niet ingetekend), L22, L21, L20
De richting van de onderliggende routes zijn dan:

  • L20 naar L21
  • L15 naar L21
  • L14 naar L15
  • L14 naar L22
  • L21 naar L22
    Dus de gekleurde route is helaas niet zo maar even samen te stellen uit de onderliggende knooppuntroutes

Verder vind ik zeer verdedigbaar dat de gekleurde routes in het lwn worden opgenomen.
De gekleurde routes horen bij een bepaald startpunt en zijn daarmee lokaal.
De enige routes, die over de startpunten heen gaan, zijn dan de lange afstandsroutes, die zijn ook meestal op de bekende wandelroute-manier gemarkeerd. Ook al hebben we nu van die routes, die in feite weer lokaal zijn, zoals een route om Deventer heen, die groen/wit is gemarkeerd.

Een ander probleem is de kleur van de route. Ik heb al eens geëxperimenteerd met een colour tag in de rwn knooppunt relatie, maar 'Waymarked trails wil daar niet aan. Een knooppuntroute is en blijft lichtbruin. Bovendien wordt het lastig als er meerdere gekleurde routes over een knooppuntroute heen liggen. Welke kleur neem je dan?

Dank voor jullie reacties. Ik herken zowel de wens van Richard om de gekleurde lussen (relatie, type=route) te ordenen in een type=network-relatie als de praktische bezwaren die Dick noemt tegen het opnemen in het RWN (ik ben erg dankbaar voor het bijna dagelijkse monnikenwerk dat sommige mappers doen om de rwn en rcn-relaties vrij te houden van fouten op basis van de validatietools).

  • Zou het maken van een network=lwn (parallel aan het network=rwn, met daarin de verschillende gekleurde lwn-lussen voor dat gebied) niet tegemoet kunnen komen aan die beide punten?[

Zo blijft het rwn-netwerk consistent met de rest en vrij van een dikke mist aan foutmeldingen, zie je in de huidige tools ook de lwn-kleuren en kan je zelf toch de samenhang tussen de lwn-lussen verder in beeld brengen met een eigen rendering als je daar behoefte aan hebt.

(aanpassen van rendering aan locatiespecifieke kenmerken / wensen heb ik ook gedaan voor het grote aantal wandelpaden bij mij in de regio dat een aantal maanden dicht is in het broedseizoen, deels ook verschillende periodes… Zal nog een linkje daarnaar posten.)

De vraag blijft dan inderdaad wel wie de leden vormen van die gekleurde routes: de individuele ways of de daarmee samenvallende (maar niet uniform op-/aflopende) knooppunt-relaties.

Het elegante van het samenstellen uit relaties ipv wegen is idd dat het automatisch meeverandert (hoewel het invoegen van een knooppunt denk ik wel voor extra werk zorgt, ook als de lus zelf niet verandert).

Ik probeerde een lwn-route te maken aan de hand van het voorbeeld van Dick, het viel me op dat als je de knooppunt-relaties invoert als leden, dat je in JOSM dan niet de validatiepijl rechts in beeld ziet waarmee je kan zien of iets wel of niet aansluit. Dat maakt het wel foutgevoeliger.

Maar het probleem van de volgorde laat zich wellicht oplossen door aan elke relatie die lid is een role=forward/backward toe te voegen, aan de hand van de vraag of je (gegeven de richting waarin je de lus intekent) tussen het specifieke knooppunt-traject van laag naar hoog loopt (forward) of van hoog naar laag (backward).

In dit voorbeeld gaat het zo te zien om een lus met een “stokje” eraan, dus een vast vertrekpunt. In het Vechtdal zag ik ook veel gewone lussen, die niet echt een vast vertrekpunt leken te hebben en op elke punt kunnen starten/eindigen.

Even de opzet van de wandelnetwerken in Overijssel en de Achterhoek.
In Overijssel heb je een verdeling in hoofdnetwerken:

  • Twente
  • Salland
  • Vechtdal
  • IJsseldelta
  • Waterreick

De Achterhoek is gewoon Achterhoek, zonder verdeling.

Binnen elk netwerk heb je een heel aantal startpunten.
Bij elk startpunt staat een kaart met daarop de routes van dat startpunt. Sommige startpunten hebben flink wat routes, andere maar een paar.
De routes zijn inderdaad rondlopers en sommige hebben een “piefje” om bij het startpunt te komen.
Je kunt de routes overal op pakken, dat hoeft niet bij een startpunt.
Een route van een startpunt kan in contact komen of voor deel samenlopen met een route van een ander startpunt.
Zo ontstaat samenhang in het netwerk.
De routes hebben een kleur.
De kleuren zijn uniek per startpunt, niet voor het netwerk. Per netwerk en per kleur zijn er een heel aantal routes.
De grijze routes vormen de verbindingsroutes. Dat kan zijn van/naar een startpunt, of van/naar de groep van een ander startpunt of tussen de netwerken. Ook worden langs lange afstandsroutes wel grijze routes gelegd.

De keuzepunten hebben altijd een hoofdletter gevolgd door een tweecijferig nummer. Dus met voorloopnul!
De letters geven een geografische groep aan.
Zo zijn de punten in Deventer/Schalkhaar allemaal L, in Colmschate M, Bathmen N, Lettele J, Diepenveen + deel van de landgoederen K, , De Haere/Groot Hoenlo G, Olst/Boskamp F, Okkenbroek H, etc.
Je kunt dus aan de letters zien waar je ongeveer bent.

De lange afstandsroutes zijn meest gesynchroniseerd met het netwerk of beter het netwerk met de lange afstandsroutes.
Maar bij de laatste grootschalige vernieuwing van Salland en Twente, zie je dat lange afstandsroutes gelijk mee gewijzigd zijn.

Verder zijn er ook “eigen” langere routes, die dus niet van één van de gevestigde wandelroutemakers zijn.
Voorbeeld is de Sallandse Zandloper en het Regge- en Schipbeekpad

Volgens mij kun je in het lwn gewoon netwerken maken.
Dus de routes groeperen in lwn netwerken kan prima.
Naar mijn idee is het dan handig om per startpunt nog een netwerkje te maken en die in de grote netwerken te hangen. Anders heb je het probleem dat je in elke route moet gaan vermelden waar hij bij hoort.

Je krijgt dan de hierarchie: netwerk - startpunt - route

En ik denk dat het handig is om in de route te vermelden langs welke keuzepunten hij loopt.

Ik heb een proefopzetje gemaakt en dat in OSM opgeslagen. De validator moppert niet als je een netwerk in een netwerk stopt,

Om de discussie op één plek te voeren i.p.v. op twee quote ik hieronder even de reactie van dvdhoven op mijn commentaar op één van zijn changesets (http://www.openstreetmap.org/changeset/44111514):

@dvdhoven: ik snap niet waarom je denkt dat ik je aanspreek alsof je geen verstand van zaken hebt, maar dat was zeker niet mijn intentie. Ook de volgende reacties hieronder moet je ook vooral niet persoonlijk opvatten. Het is gewoon zo dat wij verschillen van mening en ik probeer zo goed als mogelijk mijn mening te onderbouwen met de afspraken zoals die op de wiki staan.

Dick stelt dat de wandelknooppunten in Twente en omstreken niet voldoen aan de eisen die gesteld worden aan een rwn-route. Ik neem aan dat hij daarmee doelt op de eisen die de wiki geeft. De enige eis die de wiki (http://wiki.openstreetmap.org/wiki/Tag:network%3Drwn) geeft is dat het een regionale route moet zijn. Hij heeft hier dus een punt aangezien de trajecten tussen 2 knooppunten lokaal zijn. Echter geldt dit net zo hard voor de stukjes tussen 2 knooppunten A en B (A != B) als voor stukjes tussen 2 knooppunten A en A. Beide hebben een lokaal karakter. Het idee van knooppuntenroutes is dat je zelf je route kan samenstellen door een route te kiezen die een aantal knooppunten aandoet. Zo beschouwd zit er weinig verschil in de Twente-methode en de rest van het land. Je bent immers in Twente en omstreken ook niet gedwongen om bij een knooppunt aangekomen dezelfde kleur te blijven volgen. Ik snap dus wel dat Dick de tussenstukjes lwn wil taggen, maar dit zouden we dan voor alle knooppuntenroutes moeten doen. Zowel voor fietsroutes als voor wandelroutes. Ikzelf ben hier geen voorstander van, want al hebben de tussenstukjes een lokaal karakter, gezamelijk hebben ze een regionaal karakter. Ook lijkt het me niet logisch om de knooppunten wel op te nemen in een rwn netwerk relatie, maar de verbindingen als lwn traject relaties. De wiki (http://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes#Tagging) is hier trouwens ook heel duidelijk in: zowel de traject-relaties als de netwerk-relaties worden als network=rwn getagged. Ik vind het daarom ook jammer dat zonder overleg de door mij aangelegde rwn-trajecten worden omgetagd naar lwn-trajecten en dat hij een edit-war aankondigt als ik dat weer terug zou veranderen.

Een ander probleem dat hij aanstipt is dat er een checker (VMarc) is die foutmeldingen geeft als de rondjes als rwn worden getagd. Hij stelt dat de enige manier om van die foutmeldingen af te komen is om de traject relaties om te taggen van rwn naar lwn. Dit is, vind ik persoonlijk, een slecht argument. We taggen immers niet voor de checkers; net zo min als we voor de renderers taggen. Er zijn zat tools de foutmeldingen geven die eigenlijk geen fouten zijn. Je moet dan niet je tagging aanpassen maar de foutieve/onvolledige tools. Je moet je niet blindstaren op tools als VMarc, Osmosis, Keepright, etc. Het zijn handige hulpmiddelen, maar ook niet meer dan dat.

Hij geeft ook aan dat de volgorde/richting van de relatie een probleem oplevert. Ik zie echter niet in waarom een rwn wel een bepaalde richting op moet lopen en een lwn niet.

https://hiking.waymarkedtrails.org/#?map=14!52.2318!6.8243 geeft overigens wel gewoon kleurtjes weer.

Er wordt overduidelijk gesteld dat de rwn netwerken getagd worden als de fietsnetwerken.
Daarvoor hebben we deze wiki pagina: http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging

Dus dat zijn de eisen waaraan de routes moeten voldoen.

En weer duikt dat argument op dat we niet taggen voor de checkers. Daar wordt ik zo moe van. En daar baal ik zo van.
Dank zij VMarc hebben we een standaard bereikt in het rcn, die klinkt als een klok. Fouten zijn er binnen in een dag uit in de meeste gevallen.
Het rwn hinkt er wat achteraan, maar is behoorlijk goed.

En jij stelt dat de verbindingen tussen de knopen niet in het rwn zitten, maar dat is niet waar. In het rwn zitten de verbindingen tussen de knopen, die voldoen aan de knooppuntstandaard. Kijk maar op de Salland kaart of Twente kaart. Beide via VMarc op te roepen of via Waymarked Trails
Die rondjes zijn geen verbindingen tussen de knopen, maar gaan er overheen. Die zijn niet bruikbaar als verbinding tussen knoopppunten.

Jij volgt het gebeuren van rcn en rwn niet zo en dat is je goed recht. Ik repareer dagelijks routes in beiden. Elke dag gaan er dingen stuk door vele redenen en zonder VMarc was het rcn weer de grote chaos, die het een paar geleden was.

Zodra je die rondjes in het het rwn propt, hebben we duizenden foutmeldingen en kunnen we niet meer zien of routes gebroken zijn, knooppunten verdwenen zijn, op een verkeerde plek liggen, routes niet compleet zijn, niets meer. Dan verzinken we voor het rwn in Achterhoek, Overijssel in de grote chaos, die het was voor A67-A67 en ik de schouders eronder hebben gezet. En daar pas ik voor.
Ik neem dit wel persoonlijk, ik laat mijn inspanningen en die van medemappers niet aan gort helpen door iemand die op zijn principiële strepen gaat staan. Waarom wil je dat zo hoog nodig in het rwn hebben?
Het alternatief van multimodaal is een zeer goed alternatief, de rondjes in het lwn en daar netwerken creëren.

Ik kan je wel zeggen, dat elk rondje dat in het rwn opduikt, binnen de kortst mogelijke keren weer in het lwn zit.

Ik denk dat dit weer een mooi voorbeeld is van een situatie waarin twee systemen (systeem in het veld en de ontstane methoden in OSM) niet echt op elkaar passen en wij daar als mappers samen een weg in moeten vinden, met alle mogelijkheden voor verschillen van inzicht vandien (net als bij nationale regelgeving en oms-access-categoriën, dat staat ook altijd garant voor fijne discussies :wink:

Ik denk dat we vooral met elkaar moeten zorgen voor een methode die werkbaar is en recht doet aan de bestaande situatie. Als ik het heel abstract/principieel zou bekijken, dan zou ik geneigd zijn om de gekleurde lussen hoger in de hiërarchie te zien dan de knooppunt-knooppunt verbindingen (dus eerder rwn dan lwn), omdat de lussen zelf van een groter schaalniveau zijn (en ze beiden het netwerk bedekken). Maar om het zo principieel te bekijken zonder de context erbij te betrekken brengt ons in dit geval (en dat is ook het punt dat Dick denk ik terecht maakt) eerder verder dan dichter bij een oplossing, en het zou in ieder geval niet consistent zijn met hoe elders rwn/rcn-routes gedefinieerd zijn (van één knooppunt naar één ander knooppunt).

Ik zie er zelf dus geen enkel probleem in om dat meer principiële punt te laten wijken voor het duidelijke en sterke praktische argument, en dus lussen te taggen als type=route/network=lwn en die te groeperen in een type=network/network=lwn

En dat is volgens mij ook niet fout irt de werkelijkheid, zoals de kwalijke vormen van tagging for the renderer/validator dat wel zijn), het zijn twee manieren om twee niet-passende modellen toch op elkaar te laten passen, dat zal altijd ergens wringen.

@Richard:
Wat is jouw beeld: zou er iets mis gaan als de lussen op lwn houden en dan ook opnemen in een lwn-netwerk-relatie, als we die werkwijze ook helder opnemen op een NL-wiki, zodat er een gedeeld beeld is?

Of zie je een andere methode die per saldo beter werkt, gegeven ook dat ook de knooppunt-knooppunt delen worden ingevoerd en je, ook voor kwaliteitsbewaking (met welke validator dan ook) toch onderscheid tussen de lussen en de knooppunt-knooppunt-delen zal moeten kunnen maken?

@Dick: dank voor de opzet/voorbeeld.
Het startpunt als lwn-netwerk (met daarin routes_ om die vervolgens in het salland-lwn-netwerk op te nemen is op zich in termen van duidelijke hiërarchie een mooie vondst, maar als ik me probeer voor te stellen hoe dat dan werkt als mapper lijkt me het toch wel moeilijk werken:

Stel je loopt ergens op een bepaalde route, zeg de blauwe en er komt een andere route (zeg de gele) bij, dan weet je volgens mij niet war die gele is begonnen. Als ik die gele route wil invoeren zonder dat ie een wees ie, dan zou je een startpunt-netwerk moeten aanmaken waarvan nog niet bekend is wat het startpunt is. En sowieso is het wel weer een extra stap (ik merk dat ondanks de ervaring die ik ondertussen heb het mappen van netwerken nog steeds zo arbiedsintensief is dat ik ook nu al wel een drempel voel, toen ik de werkwijze uitlegde aan iemand die dacht dat je gewoon een shap-laag met het netwerk kon importeren krabde ik mezelf ook weer even achter de oren :wink:

Zou het misschien een alternatief zijn om het startpunt niet in de vorm van een netwerk op te nemen, maar als attribuut van de routes die daar beginnen. De lus wordt dan lid van het netwerk (je weet doorgaans wel in welk netwerk je zit, dat staat op elke paal, behoudens grensschermutselingen), en het startpunt zou dan een attrubuut van de route zijn (die kan je invullen als je die weet, maar als je die niet weet is het niet direct een probleem.

De node met het Startpunten zou dan, parallel aan de rwn-methode, een lwn-ref kunnen krijgen met de naam.
Zo kan je via die node de lussen identificeren die daar beginnen.

De start-node zou dan, net als bij rwn, een apart lid kunnen worden van het netwerk (maar niet nog een keer dubbelop van de route, net als bij rwn).

Zou dat misschien wat kunnen zijn?

ps.
in het kader van wat te doen met de startpunten:
ik zie op de kaart van Vechtdal die ik ter plekke heb gekocht, dat er lussen zijn die langs meerdere formele startpunten komen.

Zo komt de Blauwe route over de Lemeler-/Archemerberg (in 10,5km) langs 4 startpunten en langs 20 knooppunten…

Ja, jouw voorstellen zijn prima.
Ik probeerde een modus te vinden om onderscheid te kunnen maken tussen de diverse routes van dezelfde kleur. Een netwerk als Twente heeft met gemak enkele tientallen routes van dezelfde kleur.
Bij wandelroutes voert men vaak een node in als startnode met de role start. Zoiets kan je ook doen bij de kleuren routes. Je kunt dan de node nemen met de rwn_ref bij het startpaneel. Bij elk startpunt ligt een startnode dat een rwn_ref heeft.

Ik tag zelf een losse node voor het infopaneel en geef die de naam van het startpunt. Zo’n node kun je ook in de route opnemen.

Dit zou ook een optie kunnen zijn:
De knooppunten en routes tussen de knooppunten als network=rwn taggen.
De lussen als routes met network=lwn taggen. Dit zijn de lokale wandelingen. Om een dubbele boekhouding te voorkomen kan dan de lwn route een aantal rwn routes bevatten.

Dit lijkt een beetje op het systeem bij mij in de gemeente:
Er is een knooppuntennetwerk aangelegd. Daarlangs zijn er lokale routes die gebruik maken van dit netwerk waarbij de palen een extra markering hebben. Een langere meerdaagse wandeling (petran pad) gaat ook via de knooppuntenroutes.

Ik heb http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging gelezen en lees nergens dat voor een route tussen punt A en punt B geldt dat A ongelijk aan B moet zijn. Rondwandelingen voldoen dus precies aan de omschrijving. Ja je komt onderweg andere knooppunten tegen, maar wat is daar erg aan? Het is nog altijd voor een tool als VMarc prima te doen om de volledigheid van elke relatie te checken. Misschien dat je de tool een beetje moet aanpassen (if A==B then … else …), maar dat is altijd nog beter dan om dan maar een mass-edit te doen en ik weet niet hoeveel relaties te gaan omtaggen. Zo’n mass-edit moet overigens altijd eerst besproken worden. Ik stond dan ook perplex dat zomaar al mijn relaties zomaar zijn veranderd zonder ook maar een berichtje, hetzij persoonlijk, hetzij op het forum. Praktisch het gehele Twente-wandelnetwerk is van mijn hand. Ik ben dus niet een kleine speler die wel aan de kant gezet kan worden.

Problemen die ik heb met de omtagging van rwn naar lwn en het dupliceren van routes tussen de knooppunten is:

  1. Er is geen enkele communicatie richting mij geweest bij het massaal aanpassen van al mijn relaties.
  2. Er is afgesproken om elke feature slechts 1 keer te mappen (http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element). De manier van Dick is om alle routes dubbel te mappen. Ieder stukje van een route wordt in zijn manier dubbel gemapped. Eentje als onderdeel van een lwn-rondwandeling en eentje als rwn-verbindingsstuk. Dit is in strijd met de “One Feature, one element” regel van OSM.
  3. Door het dubbel mappen is het dubbel zoveel werk om alle routes goed te krijgen.
  4. Juist een tool als VMarc is handig om ontbrekende stukken van een route te detecteren. Als je die tool nu loslaat op enkel de verbindingstukjes, mis je de veel grotere lussen die, als ik het goed begrijp, nu helemaal niet meer op compleetheid worden gecheckt. Dit is een gemiste kans van de tool.
  5. Er zijn soms splitsingen in de route zonder dat dit punt een nummer heeft gekregen. Dit is in het schema van Dick niet te taggen, anders dan om de route zelfs 4 keer op te nemen.
  6. Mass edits moeten eerst uitvoerig met de community besproken worden alvorens deze in de database worden aangepast. Dit is mijns inziens niet gebeurd.
  7. Het is schitterend dat er check-tools worden gebouwd om de kwaliteit van de database te verbeteren, maar wat geeft de bouwers daarvan het recht om bij false-positives de database massaal te veranderen i.p.v. dat ze hun tools aanpassen aan de werkelijkheid?

Ik kan me voorstellen dat het vervelend is als je werk op grote schaal wordt aangepast, maar laten we dan vooral hier de gelegenheid gebruiken om samen tot een zo goed mogelijke oplossing te komen, want de twee manieren van tagging door elkaar in dezelfde netwerken daar wordt denk ik niemand echt gelukkig van, dat lijkt een blijvende bron van gedoe. En ook veel van mijn knooppunt-data is in de loop der tijd aangepast, hoewel dat meestal om zaken ging die meer echte foutjes waren, maar in dat geval was ik erg blij dat Dick en A67-A67 dat wilde doen en begreep ik ook, dat gezien de enorme hoeveelheid (dagelijks)werk, het niet te doen was om over elke wijziging te mailen (maar kan me wel voorstellen dat dit hier net iets anders ligt).

One feature is inderdaad een aandachtspunt, in het algemeen en zeker hier als een duplicaat-netwerk wordt voorgesteld, maar ik twijfel of dit echt een show-stopper is: er zijn immers in het veld twee verschillende relaties: de knooppunt-knoopunt en de ronde lus. Die delen niet alle zelfde kenmerken. Een ook als je in het rwn alleen lussen zet, dan blijf je de situatie houden dat de meeste verbindingen in meerdere lussen tegelijk zijn opgenomen (pad x zit zowel in de rode, blauwe als groene lus).

Elders wordt dit ook niet als een probleem gezien daar waar “klassieke” rwn-netwerken zijn aangelegd die reeds bestaande lokale en regionale routes volgen daar waar aanwezig: daar zitten ways soms tegelijk in een lwn, rwn en een nwn-relatie.

Aan de andere kant kan het zo strikt mogelijk uitleggen van “one feature” misschien ook wel een derde praktische mogelijkheid bieden:

  • als je het netwerk tagt in een rwn op de klassieke manier (dus een rwn-relatie per knooppunt-knooppunt)

  • en voor elke (knooppunt-knooppunt)route-relatie in een variabele (color / ref etc.) vastlegt welke kleuren er in het veld zijn toegekend aan dat traject (voor bovenstaand pad x dus iets in de trant van “ref=red;blue; green” dan dupliceer je niets (ook geen 3 rwn-lussen over hetzelfde pad)

  • zo kan je de lussen ook afleiden uit de rwn-data, eventueel met hulp van de door Dick genoemde startpunten

Zou dat iets kunnen zijn?

Dat zou in ieder geval het meest in lijn zijn met hoe rwn/rcn netwerken normaal worden getagd (los of de huidige tekst van de wiki daar nu wel of niet dwingend in is: de praktijk gaat toch normaal wel uit van knooppunt-knooppunt, misschien is dat zelfs zo vanzelfsprekend voor de opstellers dat dat niet is benoemd. En belangrijker dan de exacte bewoording daar (de wiki is zo aan te passen…) is denk ik de vraag wat uiteindelijk, alles afwegende, het beste werkt.

Ook aan deze optie zullen nadelen zitten, maar het lijkt me wel dat we iets moeten kiezen wat per saldo het beste werkt (en inderdaad afstemmen als dat tot wijzigingen van bestaande data leidt). Er zullen ongetwijfeld uitzonderingen zijn, maar als ik de kaart van het Vechtdal zo bekijk, zou dit denk ik wel eens kunnen werken.

Wat denken jullie?

Waarom niet een superrelatie maken waarbij de wandelingen relaties niet verwijzen naar ways, maar de rwn relaties.
Die superrelatie kun je met kleuren op smaak brengen met colour en osmc:symbol tags.
Ik ga er dan vanuit dat de gekleurde routes en de knooppunten altijd overlappen.

Superrelaties worden ook gebruikt om lwn routes te bundelen tot andere lwn en iwn routes, dus dit principe wordt al gehanteerd in OSM.

Ik ben niet zo’n voorstander van het opknippen van de rondwandelingen in verschillende kleinere delen, noch op de manier van Dick, noch op 3e optie van multimodaal.

  1. Het wordt er namelijk veel bewerkelijker op. Alle features als colour, name, network, osmc:symbol, ref, route, type moet je dan op ieder stukje zetten. Soms zitten de knooppunten heel dicht (10 meter bijvoorbeeld) bij elkaar en dan zou je dus iedereen heel veel werk op de hals halen. En al die losse relaties moet je ook allemaal nog in de netwerk-relatie opnemen. Kans dat je daarbij eentje over het hoofd ziet is veel groter naarmate de fragmentatie toeneemt.
  2. Hoe groter de fragmentatie, hoe groter de kans op fouten en hoe lager de kwaliteit.
  3. Ook verlies je daarmee informatie. Je kunt dan namelijk niet meer achterhalen welke stukjes bij elkaar horen. In het Twente netwerk komen soms gelijk gekleurde routes akelig dicht bij elkaar in de buurt. Ik ben al tegengekomen dat 2 verschillende rode routes op nog geen 10 meter van elkaar liggen. Zelfs heb ik al meegemaakt dat ze elkaar kruisten. In de oplossing van multimodaal zou je dan dus problemen krijgen als er ergens (per ongeluk) een wegdeel aansluitend aan een knooppunt uit een relatie weghaalt. Er is dan niet meer te achterhalen of de 2 relaties die voor die actie bij het knooppunt samen kwamen bij elkaar horen of niet. De twee relaties hebben dan niets meer gemeenschappelijks. Zouden ze bij dezelfde rondwandeling-relatie horen, dan zou meteen opvallen dat er een gat in de relatie is ontstaan. Ook kun je dan niet meer eenvoudig een gpx’je van de rondwandeling in je GPS zetten, maar moet je al die losse stukjes los op je GPS zetten. Ook kun je niet meer makkelijk zien hoe lang een rondje is, etc, etc.
  4. Tools kunnen met al die losse stukjes ook niet meer checken of een lus volledig is of niet, immers er zijn dan geen lussen meer. Als er rond een knooppunt een lijntje ontbreekt wordt dit niet meer gedetecteerd. Door de fragmentatie gaat dus juist de kwaliteit omlaag, terwijl je juist met checker tools de kwaliteit omhoog wilt brengen.

Een rondje zie ik als één feature. Ook een knooppunt zie ik als één feature. Het is niet zo dat de maker bedacht heeft om naast de rondjes ook nog de tussenstukjes aan te leggen. Ik zie daarom ook geen voordeel om een rondje op te splitsen in verschillende delen op te splitsen. Kan iemand mij vertellen wat hier het voordeel van is anders dan dat VMarc bij de rondjes false-positives oplevert?

Daarnaast blijf ik het vreemd vinden om een 7 km rondje als ‘lokaal’ te mappen en een deel ervan van wellicht slechts enkele honderden meters als ‘regionaal’.

Dat wil ik ook graag doen. Van begin af aan dat ik met rwn Salland begon, is dat mijn idee. De gekleurde routes opbouwen uit de onderliggende stukjes rwn. Ik twijfel alleen of er iets is, dat dan ook kan renderen en of het een probleem is dat de diverse stukjes verschillende richtingen hebben. Ook is er een probleem met overlappende stukjes. Dat is bij het rwn gelukkig minder, maar het is er wel.

Je noemt een hoop punten waar ik erg in kan meevoelen.
Ook deel ik je beeld dat het op zich -geredeneerd vanuit oogpunt van schaalgrootte- het wel apart lijkt om een kort knooppunt-knooppuntstukje als regionaal te noemen en een langere lus (waar dat korte stukje inzit) als lokaal.

Toch is dat wel hoe de knooppuntnetwerken nu zijn gedefinieerd: lwn-routes zijn rondjes, rwn-routes zijn “korte op elkaar aansluitende wandeltrajecten tussen genummerde punten.” ( https://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes ; dus in dat kader zijn de “tussenliggende stukjes” als feature gedefinieerd).

De logica is wat meer direct zichtbaar als je niet naar de type=route kijkt, maar naar de type=network waar die routes toe behoren:
Lwn-routes maken doorgaans deel uit van een klein gebied (bijvoorbeeld een bepaald natuurgebied met daarin een “klassieke” blauwe, gele route etc.), daar waar de -op zich kortere- rwn-routes behoren tot een netwerk dat een grotere schaalgrootte heeft, daarmee vind ik zelf die hogere “rangorde” wel logisch.

Het lastige is dat er in delen van oost-Nederland er nu net een uitzondering is: regionale netwerken gevuld met lussen die je normaal gesproken in een lwn verwacht en met de knooppuntenstructuur van een rwn.

Op zich vind ik dat als -incidentele gebruiker- best een mooie vondst: je kan met minder kenmerken een route definiëren en hopelijk draagt het er ook aan bij dat bij het opstellen al te lange saaie stukken worden vermeden, omdat het wel als concreet rondje wordt gepresenteerd (bij mij in de regio lijkt bij de opstellers soms de neiging te bestaan om de kaart vol te tekenen met rwn-netwerken, ook als dat over plekken gaat waar je helemaal niet wil lopen, zoals drie kwartier lopen over deze drukke weg: https://hiking.waymarkedtrails.org/#route?id=6607906 ).

Maar het vervelende is wel dat het inconsistent is met de manier waarop wandelnetwerken elders in het land worden getagd, tenminste als je bij het taggen van de rwn-routes de focus legt op de lussen. Want wat de bedoeling van de maker is durf ik niet te veronderstellen, maar je kan het netwerk wel vanuit twee manieren bezien: als een verzameling lussen of een verzameling knooppunt-knooppuntrelaties, afhankelijk van je invalshoek (hoewel in de markering die ik in het zag de nadruk meer op kleur lag dan op verwijzing naar het volgende knooppuntnummer).

Ik had mijn vraag gesteld omdat ik wat data wilde invoeren en dat graag wil doen op de manier die voor dat netwerk de bedoeling is. Als invoerder is het invoeren van alleen een paar (delen van) lussen makkelijker dan per knooppunt-knooppunt, maar ik kan me de argumenten van de mensen die bijna dagelijks hard werken aan validatie ook heel erg voorstellen en pas me daar graag aan aan, dat weeg ik persoonlijk zwaarder dan meer theoretische argumenten dat een andere methode minder fouten zal geven.

Volgens mij liggen er 4 opties voor (twee met en twee zonder rwn/lwn die parallel naast elkaar bestaan als aparte relatie):

  1. lussen als rwn taggen en de knooppunt-knooppunt-relaties dus niet apart taggen

  2. de lus-informatie opnemen in de rwn-knooppunt-knooppunt-routes en de lussen dus niet apart taggen

  3. lwn-lussen bundelen in parallel lwn-netwerk

  4. lwn-superrelatie maken obv de rwn-delen (in verschillende bewoordingen benoemd door Dick, Jan, Sander)

Aangezien het een bij uitstek regionale (rwn :wink: aangelegenheid is en ik hier slechts inciddenteel actief ben, pas ik me graag aan een voor alle betrokkenen acceptabele werkzwijze die hier hopelijk wordt gevonden.

@ Richard:
ik ben benieuwd: zo te lezen ligt je voorkeur bij optie 1 uit bovenstaande, welk van de andere opties spreekt je het meeste aan (of staat je het minste tegen) ?

Ik ben inderdaad het meest voor optie 1. Om dan tegemoet te komen aan de mensen die dagelijks de relaties repareren met behulp van VMarc, zal dan VMarc hierop aagepast moeten worden. Daar staat tegenover dat andere checkers (zoals de validatie binnen josm, http://ra.osmsurround.org, http://osmrm.openstreetmap.de, etc.) niet hoeven te worden aangepast.

Met optie 2 verlies je informatie en lijkt me de slechtste optie
Optie 3 druist in tegen de “one feature”-regel
Optie 4 is de minst slechtste. Theoretisch gezien wellicht de beste, maar in de praktijk ook wel de meest bewerkelijke en de meest foutgevoelige. Er zou dan zowieso een nieuwe checker ontwikkeld moeten worden om relaties van relaties te kunnen valideren.

Ik heb overigens nog altijd geen redenen gehoord waarom optie 1 niet goed zou zijn anders dan dat VMarc zich hier op verslikt. Als dat inderdaad de enige reden is, dan lijkt me het verreweg het efficients om die tool aan te passen aan de werkelijkheid. Beter dat één persoon wat tijd installeert om de software aan te passen, dan dat alle mappers (van wandelingen in Oost-Nederland) bij iedere wandeling extra werk moeten verrichten.

Optie 1 is pure bagger!!!

Het zou helpen als je je mening zou willen toelichten. Aan dit soort ongefundeerde onderbuikgevoelens heeft de community niet zoveel.