Toch lijkt het mij interessant om globaal zoveel mogelijk dezelfde basisregels te kunnen toepassen
Ik zou hier gaarne de mening van anderen willen horen, aangezien ik het daar niet mee eens ben. Dat heeft enerzijds te maken met het feit dat ik totnogtoe nog maar weinig infoborden ben tegengekomen (behalve in Duitsland, daar krioelt het ervan) en daar dus zelfs nog niet over had nagedacht, maar anderzijds ook omdat de instructies die een router zal geven aan een fietser, niet logisch zijn.
De reden waarom je dit zo wilt doen, begrijp ik echter wel. Het was ook mijn eerste reflex: kies één punt en verklaar dat dat het ‘knooppunt’ is. In jou geval kies je daarvoor de plaats waar ze toevallig plaats hadden om een infobord te zetten. In mijn geval heb ik in het verleden getracht om ervoor te zorgen dat er zo weinig mogelijk ways meerdere malen in een routerelatie terecht komen.
Mijn tweede reflex was om gesplitste knooppunten te gaan verbinden met aparte relaties, die ik dan 26-26 als note meegaf.
Dit leidde echter tot mensen die kwamen zeggen dat ik hun werk vertrappeld had, als een olifant en toen ik onderzocht waar ze het nu eigenlijk over hadden, dan heb ik ingezien dat wat ik ‘tentakels’ ben gaan noemen, omdat ik ze eerder lelijk vond, eigenlijk de meest expressieve manier zijn om aan te geven hoe je van de ene route op de andere terechtkomt.
Verder wil ik opmerken dat routerelaties van FKPN’en geen gesloten lussen hoeven te zijn. Ze kunnen dus eindigen/starten als één lijn op één punt, of als een vork op twee punten. Enkel het punt waar een route ‘toekomt’, heeft een rcn_ref nodig.
Dat is waar we het moeilijk over eens geraken. Jij vindt dat er van infobord naar infobord moet gefietst worden. Ik vind dat het naadloos overvloeien van de ene route in de andere belangrijker is. (dus geen ways die op dat traject tweemaal gebruikt dienen te worden). Als fietser zou ik dat als inefficiënt ervaren.
Het is nooit mijn bedoeling geweest om een eliteclubje op te richten, vandaar ook mijn inspanningen om de wiki aan te passen met de door mij verworven inzichten, langsheen de FKpNw’en. Het verschl tussen lokale mappers en mensen die de zaak van wat verder weg bekijken is dat voor een gegeven gebied de laatste altijd in de meerderheid zullen zijn. Ik wil ook vermijden dat lokale mappers op een andere manier gaan mappen dan mensen die met een adelaarsblik ‘the big picture’ zien.
Ik ben ook zeker niet vergeten dat ik eind augustus als heel naïeve beginneling kon beschouwd worden en dat is nog helemaal niet zo lang geleden.
Mijn pythonscript kan perfect bepalen waar het knooppunt ligt, dat ik beschouw als ‘het eigenlijke startpunt’ van de route. (Ofwel komen daar meerdere tentakels samen voor de laatste keer (en begint er daar vaak een way die geen role meer heeft), ofwel staat er een rcn_ref met hetzelfde lage KP-nummer als waar het tentakel begon).
Nogmaals, enkel nodes waar routes hun eindpunt hebben, moeten worden voorzien van een rcn_ref. Bij het ‘eigenlijke begin van een route’ wordt dat niet geplaatst. De uitzondering is natuurlijk als die node het eindpunt is van een andere route.
Ik bedoelde dat ze het infobord zouden kunnen opmerken op het moment dat ze op het kruispunt toekomen. Ik zet rcn_ref op wat ik beschouw als het einde van een route. Jij wil rcn_ref zetten waar het infobord staat. Daar begint deze discussie op neer te komen. (zie opmerking bij Casusvraag 5, verderop)
Navigeren is geen enkel probleem, behalve als je verwacht om langs alle infoborden op je route geleid te worden. Zie opmerking over efficiëntieverwachtingen van fietsers (of van mezelf, zo je wilt) hogerop in deze boodschap.
Het is duidelijk te zien, als je vanuit een punt 100m hogerop naar beneden tuurt. (Of met JOSM het knooppunt in z’n verband met de omliggende knooppunten en routes bekijkt. Nogmaals, dit lijkt mij (Polyglot) de meest voor de hand liggende manier om dit te doen, maar bij casusvraag 5 staat een alternatieve manier om het op te lossen, die wat mij betreft even geldig is.
In dat geval moeten we de node met rcn_ref inderdaad verplaatsen en naar noordoostelijke punt van het kruispunt brengen. Dit heeft echter als gevolg dat route 26-98 eigenlijk een route is die als tag state=connection meekrijgt. En wat mij betreft zou de note tag dan eigenlijk beter “25-26 - 98” o.i.d. worden. Dan begint deze route ergens midden op route 25-26 en verbindt door naar KP 98. Daar heb ik verder geen problemen mee, maar het lijkt me lastiger voor routeersoftware om mee om te springen. Nu moet routeersoftware sowieso zodanig worden geprogrammeerd dat het overweg kan met routes die state=connection hebben, dus dat mag ons daar niet van weerhouden.
Extra tags lijken me niet noodzakelijk. Wel een wijziging van de perceptie. Ik weet dat dat veel gevraagd is en wat mij betreft hoeft het niet eens. Als iemand echter mijn Pythonscript als referentieimplementatie voor routeersoftware zou gaan gebruiken, zou het echter wel interessant zijn dat de routes OK verklaard worden door het kwaliteitscontrolescript (Dus niet meer opduiken op de wikipagina waar het rapport staat). In feite kan dat ook met jullie/jouw manier van werken, waar ways meerdere malen gebruikt worden in meerdere routerelaties en waar fietsers steeds langsheen infoborden worden geleid. Zolang de routes als continu kunnen worden beschouwd van laag naar hoog en omgekeerd en maximaal 2 verschillende rcn_refs bevatten, is het in orde voor mijn script. Uitzondering zijn routerelaties met een state=connection tag, die hoeven helemaal geen enkele node te bevatten met een rcn_ref (heb ik echter nog niet geïmplementeerd, dat komt nog)
Wat mij betreft is het inderdaad correct. Als er besloten wordt om op een andere manier te werken, zal ik wel een ander knooppunt kiezen om als voorbeeld voor de wiki dienst te doen. Het is veel werk, maar nu weet ik toch al wat de beste wijze is om het te doen (screenshots van JOSM, nabewerkt met LibreOffice Draw).
Ik had ook graag geweten of die illustraties geholpen hebben bij een beter begrip van de ‘tentakels’. Of heeft er iemand suggesties hoe het beter kan?
Jo
