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.
Ik heb echt geen zin meer om nog verder te reageren.
Alleen, dit.
Als er gekozen zou worden voor optie 1, lig ik onmiddelijk dwars. Ik heb in het rwn Twente al heel veel netwerkrelaties aangemaakt en die laat ik niet door iemand verwijderen. Daar zitten uren en dagen werk in. Harstikke leuk werk, dat wel. Maar vele uren werk. En ook andere mappers hebben al veel netwerkrelaties ingevoerd, dus het station optie 1 ben je al lang voorbij.
Er zijn heel veel netwerkrelaties ingevoerd en dat is bestaand werk en dat heb je binnen OSM te respecteren.
Jouw routes zijn ook gerespecteerd, je doet wel dramatisch of je werk is aangepast, maar het enige dat gebeurt is, is rwn in lwn veranderen. That’s all.
Hooguit kan het zijn, dat ik een route gelijk mee pak als er een fout wordt geconstateerd. In zo’n geval check ik altijd of andere routerelaties er ook last van hebben.
Bijv. een weg is door geknipt en daardoor de volgorde in een rwn/rcn relatie verstoord. Dan pak ik gelijk alles mee wat er nog meer op die weg ligt, bussen ook als die er liggen.
Ook als ik buiten zie dat routes anders lopen, dan ze in OSM staan, dan pas ik ze aan.
Even de cijfers:
Ingevoerd rwn
Twente: 544 km, 659 knooppunten, 594 routes
Salland: 435 km, 355 knooppunten, 454 routes
Vechtdal: 60km, 92 knooppunten, 86 routes
IJsseldelta: 6 km, 9 knooppunten, 10 routes
Achterhoek: 204 km, 211 knooppunten, 188 routes
Totaal 1239 km aan ingevoerde rwn relaties
Tsja, dan valt een optie zonder knooppuntrelaties dus gewoon af. En daarmee is optie 1 exit.
De DWG zal nooit accepteren dat een dergelijke hoeveelheid info en werk van mappers uit OSM wordt verwijderd.
En ik zal het ook niet accepteren dat iemand mijn werk gaat verwijderen. En ik kan wel voor andere mappers spreken, die ook niet.
Daarnaast heeft bijv. Salland nog nauwelijks gekleurde routes. Wat er is, dateert deels nog uit de tijd van voor het wandelnetwerk. Ik concentreer me gewoon op het rwn werk met knooppunt-knooppunt relaties
Het is gewoon zo dat er gekleurde routes zijn en netwerkroutes en knooppunten en daarmee zul je moeten leven.
Optie 1 kan dus gewoon niet, is een utopie.
Net zo min als jij het zal accepteren dat de - door jou ingevoerde - routes worden verwijderd, accepteren andere mappers het niet dat de - door hun ingevoerde - routes worden verwijderd.
De status quo is dus, er zijn netwerkrelaties op de rwn manier en er zijn gekleurde routes op de lwn manier.
En daarmee zul je moeten leven. Linksom of rechtsom.
En ik zie ook het probleem niet.
Een aantal mappers, waaronder jij, voeren gekleurde routes in in het lwn.
Een aantal mappers, waaronder ik, voeren netwerkrelaties in in het rwn.
Dat is tot dusver prima naast elkaar gegaan, dus waarom nu niet meer?
Ik zou de knooppunten ook niet zomaar opdoeken.
Die lokale rondjes op basis van knooppunten zie ik hier ook ontstaan en lijkt voornamelijk bedoelt om wandelaars te helpen een route uit te stippelen. Velen lopen gemakkelijker een rondje dat uitgezet is en hebben geen zin om een route uit te stippelen obv nummers. Die willen gewoon een rondje voor de zondagmiddag van een uur waar ze met de kinderen heen kunnen.
Anderen, die bijvoorbeeld een langer rondje willen lopen, dan kunnen met de knooppunten uit de voeten om alsnog een maatwerk rondje te lopen.
Dat wordt in Overijssel nu ook gedaan.
Bij het rcn zijn er een heel aantal routes, die het netwerk volgen, langere en kortere. De bordjes ervoor hangen dan onder de knooppuntbordjes.
En ook bij het rwn zijn er zulke routes. Rond Deventer loopt een groen/wit gemarkeerde route geheel volgens het netwerk. Daarvoor zijn een flink aantal extra knooppunten toegevoegd.
In mijn gemeente is dat ook zo gedaan.
Er zijn extra markeringen bij de knooppunten markeringen voor routes van 2 tot 10 km (themaroutes).
Het petranpad is een langere route met een extra pijl op de knooppunten paal.
In Leunen waren het eerst gekleurde pijlen die elke een route vormen (in 1 richting). Dit is omgebouwd naar een netwerk van knooppunten en gekoppeld aan de naburige dorpen.
Na een paar dagen bezig geweest te zijn met andere zaken (eindelijk simpele website maken met paar eigen kaartjes en links naar andere handige kaartjes/info) lijkt er helaas nog weinig toenadering op dit vlak te zijn.
Hierbij in ieder geval een paar kaartjes die illustratief kunnen zijn, gecentreerd op het gebied waar Dick een proefstukje met LWN heeft gemaakt:
LWN, op basis van kleur (inlcusief rendering adhv padsoort en evt sluiting obv access:conditional). Werkt via Overpass, kan even duren http://www.openkaart.net/wandel/lvww-overpass/index.html#map=14/52.2792/6.2038&overlays=lwn
Je kan ze ook allebei tegelijk aanzetten.
(nav eerder gemaakt punt: als je op het onvolprezen Waymarkedtrails een kleur ziet bij een RWN, dan is dat volgens mij alleen zo als er op dat traject ook een lwn met een kleur loopt, vanaf zoom 12).
Zoals gezegd zal ik me aanpassen aan wat er besloten wordt, maar aangezien ik het wel mooi zou vinden als we tot een lijn komen (al is het maar omdat ik ook mijn data invoeren zonder kans dat dit later weer anders moet ) hierbij mijn persoonlijke beeld adhv onderstaande overzicht van de opties :
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.
Optie 2 (lus-info in knp-knp-relaties versleutelen: ik denk dat als je dit correct en volledig doet, dat er dan geen informatie verloren gaat, maar voel wel mee in de genoemde praktische bezwaren waardoor het in de praktijk lastig zal zijn om daadwerkelijk de informatie over de gekleurde lussen correct en volledig te genereren uit de rwn-data . In die zin zie ik hier een parallel met optie 4.
Optie 3 (parallel type=network met LWN-lussen): ik denk dat het bezwaar obv ‘one feature’ hangt dat de knp-knp relatie en de lus dezelfde zaken zijn, maar daar kan je denk ik verschillende over denken (er zijn zowel argumenten voor als tegen). Als je het als twee verschillende zaken ziet, dan is dit geen probleem meer. Daarnaast (en wellicht belangrijker) : ‘one feauture’ is inderdaad good mapping practice, maar als het het goed kunnen mappen van zaken praktisch onmogelijk maakt, dan kan je je afvragen wat erger is en of we echt roomser dan de paus moeten zijn (hoewel die uitdrukking met de huidige paus wat aan kracht inboet ;-).
Dit lijkt mij de meest praktische oplossing, en als het bezwaar echt ligt in ‘one-feature’ , dan wil ik best bij de DWG navragen of zij er een onoverkomelijk bezwaar zien als er een type=network / network=lwn komt met gekleurde lussen naast het rwn-netwerk. Gelet op mijn eerdere contact (eerder rekkelijk dan preceis) vermoed ik dat hier geen bezwaar in wordt gezien.
Het laat ruimte voor de verschillende benaderingen (als een mapper de lwn lussen invoert met knooppunten, dan kan een andere mapper desgewenst daarop voortbouwen en ook de knp-knp in het rwn invoeren. Vele werk is dan al gedaan (knp invoeren en wegen aanvullen /splitsen).
Optie 4 lijkt me inderdaad theoretisch het mooiste, maar in de praktijk ook meer foutgevoelig dan optie 3 (en lijkt daarmee op optie 2). Dat werd voo mij bevestigd toen ik een proef-LWN-rondje probeerde in te voeren. Ik merkte ik dat ik het wel lastig vond ivm het omgekeerd invoeren als je van een hoog naar een laag knooppunt gaat omdat je in het JOSM-relatievenster niet ziet of je routedelen wel of niet aansluiten (en je voor validatie evt ook nog met forward/backward moet gaan werken)
Eerder begreep ik dat Dick geen bezwaar had tegen optie 3 (wellicht wel een voorkeur voor 4).
Zou een praktische oplossing zijn als ik de DWG vraag of zijn onoverkomelijke bezwaren hebben tegen optie 3 (parallel type=network / network =lwn met daarin de gekleurde lwn-lussen) ?
Of ligt de gedeelde voorkeur toch bij optie 4 (supernetwerk, dat is wel veruit de mooiste naam natuurlijk…) ?
Het zou mooi zijn als we hier een weg kunnen vinden die voor ons allemaal werkbaar is (het hoeft niet perfect te zijn).
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.
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?
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.
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/Fietsroutes#Regionale_Fietsroutes_.2F_Fietsknooppuntennetwerk) 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.
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.
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/1095981#map=17/52.30501/6.20151&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.
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.
Ook dit is precies het punt dat ik wil maken. Met twee parallelle netwerken krijg je ze nooit met elkaar gesynchroniseerd.
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.
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.
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.
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…)
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) :
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) ?
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.
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.
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.
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 )
-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):
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
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:
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/#?map=17!52.1854!6.8906
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.
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/#?map=15!52.1428!6.7281)
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.
