Bij het nauwkeurig beschrijven van de routes op de wiki, heb ik gemerkt dat ik fouten gemaakt heb. Waarschijnlijk omdat ik die weg die er op de valreep nog vanaf 98 bijkomt in eerste instantie over het hoofd gezien had.
Eventueel zouden we dat fietspad wel dubbel kunnen gebruiken voor 25 en 98, als het je echt dwars zit dat daar op de weg geen knooppunt aangegeven staat. Maar ik denk wel dat er ook enige logica zit in het plaatsen van het knooppunt op die positie. Ik veronderstel ook dat er om naar 25 te gaan, als je vanaf 98 komt, dat je dan via het kruispunt waar de andere 26’en staan, moet. (Sorry ik kan morgen pas naar je opmerkingen en vragen kijken, allez, straks…)
Ook ik heb deze discussie een beetje aan me voorbij laten gaan. Door een combinatie van grote hoeveelheden tekst en niet al teveel tijd/energie. (Ben wel bezig het westen van het nieuwe netwerk Groningen toe te voegen). Ik denk wel dat het belangrijk is in het oog te houden dat de Fietsknooppuntennetwerken door verschillende organisaties/mensen worden uitgerold en dat dit niet altijd precies op de manier is uitgevoerd, zoals in het moederland der knooppunten, België, wordt gedaan.
Ik ben van mening dat je geen (geautomatiseerde) wijzigingen aan de situatie bij een ingewikkeld knooppunt kunt doorvoeren als je er niet zelf bent geweest. Als je niet weet waar de richting bordjes staan, weet je ook niet langs welke kant van het verkeersknooppunt je wordt gestuurd. Het moet niet zo zijn dat de geautomatiseerde route langs een knooppunt anders wordt dan die als die via de bordjes wordt aangegeven.
Ik begrijp dat die “tentakels” handig/nodig zijn om bepaalde situaties eenduidig te kunnen mappen, maar dat betekent niet dat dit op alle plekken waar een ingewikkelder verkeersknooppunt is, je deze tentakels moet gebruiken. Dit hangt helemaal af van hoe de routebordjes ter plaatse hangen.
Ja, als ik eenmaal op dreef ben, dan blijf ik maar verdertypen…
Ik wil er wel nog even op wijzen dat het script slechts een vrij beperkt aantal dingen automatisch doet. Het is er vooral om problemen te detecteren. De (soms grote) wijzigingen die ik doorvoer zijn allemaal eerlijk handwerk.
Ik ga vanaf nu mijn aanpak wijzigen. Totnogtoe liet ik mijn script lopen en trachtte ik de alle gemelde problemen zelf op te lossen. Nu ga ik me beperken tot het regelmatig (maandelijks?) laten lopen van het script, waarna het rapport op de wiki wordt bijgewerkt. Misschien worden de gemelde problemen aangepakt, misschien ook niet. Ik moet dit een beetje loslaten en terug OV in Vlaanderen ik kaart gaan brengen.
Ik denk wel dat ik ondertussen een schat aan ervaring heb opgedaan en ik wil natuurlijk wel eens komen helpen, als mensen er niet uitkomen.
Het script is beschikbaar als vrije software en er is niets dat mensen belet om het zelf te gaan gebruiken. Wie daar problemen bij zou ondervinden, kan me uiteraard, ook altijd aanspreken.
Vele instellingen zijn configureerbaar en als het script iets doet, wat iemand niet graag heeft, of als iemand extra functionaliteit nodig heeft, dan zal ik het met plezier aanpassen en acties/checks optioneel maken of toevoegen.
Nu zou ik wel graag zien dat de code (die eigenlijk een formeel afgietsel is geworden, van wat ik de voorbije maanden geleerd heb), als referentie-implementatie zou kunnen gelden, voor iemand die bijv. routeringssoftware zou willen ontwikkelen. Dus ik zeg niet dat echt alles zou gaan implementeren. Enkel datgene waar ik echt achtersta.
Ik heb dus een stuk gereedschap gebouwd en misschien hebben jullie er iets aan en gaan het gebruiken, of misschien ook niet. Nu ga ik verderdoen met het trachten duidelijker maken van de wikipagina. Ik heb wat geëxperimenteerd met Maperitive en Inkscape, maar ben nu bezig met screenshots van JOSM, nabewerkt met LibreOffice Draw, wat me veel duidelijkere plaatjes oplevert.
Wat de tentakels betreft zit het als volgt: als je eenmaal ingezien hebt, hoezeer die de verkeersafwikkeling eenduidig kunnen weergeven, dan is de verleiding inderdaad groot om ze zeer consequent overal te gaan toepassen en ten zuiden van de Maas heb ik dat dan ook gedaan.
Totnogtoe ben ik echter nog niet veel actieve mappers van fietsroutenetwerken tegengekomen en dat begon me al wat zorgen te baren. Ondanks dat het vermoeiend is en ik op wat onbegrip lijk te stuiten, ben ik er dus heel erg blij mee dat er nu meer betrokkenheid is en dat er meer mensen aan de tafel zitten om alles uit te klaren en formeel te definiëren.
Er zijn wel wat vrijheidsgraden (wel of geen KP’en in een routerelatie, volgorde steeds laagHoog of hoogLaag, al dan niet een 0 voor knooppuntnummers onder de 10), maar over het algemeen genomen zal het voor de gebruikers van de data wel handiger zijn, als we allemaal samen tot een zo eenvormig mogelijke manier van werken/mappen/coderen kunnen komen.
't Is weeral al langer geworden dan bedoeld, waarvoor mijn excuses,
Een mooi voorbeeld hoe het niet moet vind je in de regio oost Utrecht/west Veluwe. Hier lopen er twee netwerken door elkaar heen zonder dat die goed op elkaar zijn afgestemd. Hier een schematisch plaatje met fictieve knooppuntnummers
In rood is bijv. het oudere netwerk van de Veluwe, en later is het groene netwerk van Utrecht erbij gekomen. Op de route van 10 naar 11 zie je soms bordjes naar 11, maar ook de oude verwijzingen naar 02 komen voor. Route 10-11 valt voor een deel samen met 01-02 maar waar deze zich splitsen zit hoort eigenlijk in theorie nog een knooppunt maar die ontbreekt. Om hier nu nog een 11 neer te zetten is niet juist want 11 kan een paar km verderop liggen. Om het nog wat ingewikkelder te maken lopen routes 01-02 en 10-11 ook niet altijd parallel. Kortom fietsers zonder GPS worden hier gewoon het bos ingestuurd
Is er eigenlijk niet een mooie rol weggelegd voor het Landelijk Fietsplatform om dit soort fietsrouteknooppuntperikelen - wat een woord… - te coordineren en ook af te stemmen met de organisaties in de aangrenzende landen Duitsland en Belgie? Helaas is het nu zo dat de fietsknooppunten netwerken regionaal zijn georganiseerd. Een van de gevolgen daarvan is dat er identieke knooppuntnummers voorkomen binnen een relatief klein gebied. Gecentraliseerde aanpak en richtlijnen lijken mij de enige koninklijke weg. Ik ben het met @theun eens dat wij als mappers op OSM vooralsnog uit moeten gaan van de aanwezige routebordjes (pijlen en info-borden) en daarvoor taggen. Als er iets niet klopt of onlogisch / onmogelijk is, etc., dan bespreken met het Landelijk FietsPlatform. Geautomatiseerde processen ‘op afstand’ lijken mij niet wenselijk, maar zouden dankzij de ontwikkelde eenduidige systematiek wel heel goed kunnen dienen om op grond daarvan richtlijnen te ontwikkelen voor het opzetten en coderen van routenetwerken - grensoverschrijdend wel te verstaan. PS. Ik noem het Landelijk Fietsplatform als centraal coordinerend orgaan, maar heb dat gedaan als voorbeeld.
Die rol hebben ze ook, en ik zie dat ze op hun site een meldsysteem hebben, maar met een verouderde kaart die niet up to date is: http://meldsysteem.nederlandfietsland.nl/
Ze hadden op zijn minst een betere kaart van bijv OSM kunnen gebruiken
Ik heb dat meldsysteem al gebruikt. De melding wordt netjes doorgegeven aan de regionale beheerder, in mijn geval Rijnland / Groene Hart, en zij melden weer dat de onderhoudsgroep er aandacht aan zal besteden. Afwachten of ik daar nog iets van terugzie of -hoor.
Wat ik bedoelde met die mooie rol voor het Landelijk Fietsplatform is o.a. dat zij op dit forum ook deel zouden kunnen nemen aan de discussies over de landelijke en regionale fietsroutes. Ik herken ze in elk geval niet als zodanig. Of zouden we ze moeten tippen?
Ik heb de heer Nijland een mail gestuurd met een link naar dit draadje en hem uitgenodigd nota te nemen van de bijdragen en eventueel deel te nemen aan de discussie. Ben benieuwd.
Over wie het “dwars zit”: Dat zou zijn iemand die vanaf knp 98 of knp 25 en alle achterliggende knooppunten komt, die niet doorgeleid wordt tot de kruising waar het knooppunt werkelijk is. Nogmaals, routeborden geven op dit punt aan dat je nog niet bij knp 26 bent aangekomen, (en er is daar niets te zien van een infopaneel) dus fictief aanduiden als knp 26 is niet goed.
Als antwoord op je vraag of je bij node 44284208 linksaf mag slaan richting knp 25: nee, dat mag niet. Het is een enkelrichting fietspad en toegang is niet toegestaan wegens NL bord C2 (“Eenrichtingweg, in deze richting gesloten voor voertuigen, ruiters en geleiders van rij- of trekdieren of vee.”). Voertuigen zijn (Rvv 1990 1l) ook fietsen en bromfietsen.
Om bij 25 te komen moet je de Baalsestraat vervolgen tot de kruising met de Van Elkweg, links de tweerichting fietspad over , en dan weer links bij het infopanel de tweerichting fietspad volgen naar de rotonde.
Edit: Voor de duidelijkheid: De Baalsestraat is geen fietspad.
Jo,
Graag, al is het alleen zodat we begrijpen hoe je het bedoelde.
Als je knooppunt 26 (De Heister, Bemmel) ga gebruiken, stel ik voor dat ik nu de correcties in oneway=yes (of no) aanbreng. Ik denk dat dat alleen consequenties heeft voor route 26-30. Correct?
Zou je daarna even willen kijken of het nog klopt volgens jou systematiek?
P.S. En ik kijk uit naar je reactie op mijn vragen! Alvast dank.
Frank
Na een halve nacht en een hele dag (off and on) van editeren, knippen en plakken, is de pagina op de wiki nu voorzien van een aantal screenshots uit JOSM. Enerzijds geven die een indruk van wat je kan verwachten als je deze tips toepast:
(naar voren halen van nodes met een rcn_ref, markeren van de leden van network=rcn routes, zoals in Potlatch2 gebeurt, tonen van note tag langsheen deze routes, wegfilteren van irrelevante data. Wat niet tot uiting komt, zijn de name formatters)
Kan elk van jullie mij vertellen of ze nu een ‘staat van verlichting’ kunnen bereiken? Zoniet heb ik gefaald, maar dan ben ik ook aan het einde van mijn Latijn… Wordt het duidelijker, of nog waziger met al mijn langdradige uitleg?
Pas gerust de nodige correcties toe en laat me weten waar je denkt dat er nu een probleem zou kunnen ontstaan zijn.
Dat zit inderdaad niet in relatie 26-30. Het zou mogelijk zijn om nog een extra tentakel toe te voegen, al lijkt me dat onnodig. route 26-30 heeft haar eindpunt vlak bij dat infobord. Software kan intelligent genoeg geschreven worden om te bepalen waar het ‘eigenlijke beginpunt’, zoals ik dat pleeg te noemen ligt en dan van data in OSM gebruik te maken om mensen daarheen te leiden. Bij de tentakeloplossing werd totnogtoe geen rekening gehouden met de locatie van de infoborden. Als een meerderheid erop staat dat dat wel moet, dan pas ik de wiki aan en dan is dat vanaf nu zo. Het maakt niet zoveel verschil voor ‘the big picture’.
Er mag van fietsers ook enige intelligentie verwacht worden. Op hun GPS zien ze een symbool voor die kaart aan de overzijde van de weg. Misschien kunnen ze zelfs hun hoofd draaien en dit bord zelf opmerken, als ze het gemist zouden hebben op hun GPS. Fietstoeristen gaan per slot van rekening met de fiets om iets van de omgeving te zien en ‘mee te maken’. Daarenboven zou je ook kunnen stellen dat de fietser die uitgerust is met een GPS, dat soort infopanelen met kaart al veel minder nodig heeft. Maar goed, ik veronderstel dat er meer opstaat dan enkel een kaart (zo zou het hier in België zijn, een kaart da’s al. Je mag al blij zijn als je 's een overzichtskaart vindt bij zo’n knooppunt)
Om dus maar te zeggen dat die infoborden nog niet geïntegreerd zijn in mijn uitleg op de wiki. Ik leer voortdurend bij over de noden, verbonden aan de FKpN’en. Wat mij betreft kunnen we dat gaan toevoegen, maar KISS is ook een mooi principe (Keep it simple, stupid). Trachten om alles zo eenvoudig mogelijk te houden, zonder daarom aan functionaliteit te moeten inboeten, uiteraard.
Zou het kunnen dat dat één van de fouten is die ik ondertussen heb rechtgezet?
Van zodra een fietser een node bereikt die voorzien is van een rcn_ref, heeft hij wat mij betreft het einde van die route bereikt. Op een ander niveau werd beslist of hij nu verder moet naar 27, 30 of 98. De GPS-software kijkt naar de onderliggende OSM-gegevens:
-Welke wegen komen toe op dit kruispunt?
-Welke routes maken gebruik van deze wegen?
-Welke van deze routes hebben als tag network=rcn (en geen ref: omwille van taggingmethode in Duitsland)
-Welke van deze routes met tag network=rcn leidt de fietser verder naar het gewenste knooppunt?
26-98? het leven kan soms simpel zijn, ga hier rechtsaf
26-27? Kijk naar de tentakels aanwezig in deze route en vind het tentakel dat vanaf de huidige positie vertrekt
Volg deze tentakels. Als er een ander tentakel voorkomt in de relatie 26-27, negeer dit dan
En ga verder op het stuk weg dat aansluit op het tentakel dat net gevolgd werd. Rechtdoor dus.
26-30? Kijk naar de tentakels aanwezig in deze route (26-30 deze keer) en vind het tentakel dat vanaf de
huidige positie vertrekt.
Volg de wegen van dit tentakel totdat de eigenlijk start van route 26-30 bereikt wordt, ga dus linksaf,
voorbij het kruispunt.
Stel nu dat we geen gebruik hadden gemaakt van de tentakeloplossing, dan zouden fietsers die naar KP 98 wilden eerst naar het kruispunt geleid worden om het prachtige infobord te bewonderen en eventueel van buiten te leren (achteraf examen!), om dan opnieuw de weg te moeten oversteken (hopelijk worden ze niet aangereden bij al dat overbodige oversteken) en een stukje terug te keren op hun passen langs de straat die op een fietspad lijkt, maar dat niet is en dan naar links. Fietser komt moe, maar voldaan weer thuis en is klaar voor dat examen
Sorry, kon het maken van flauwe grapjes niet nalaten. Ik bedoel maar dat het soms een vrij grote omweg kan worden, die aangegeven wordt aan de argeloze fietser die het bordje richting 98 niet gezien had, toen hij van KP 25 kwam. Misschien moet een routeplanner van een optie voorzien worden: leidt mij langs alle infoborden.
We moeten er echter niet van uitgaan dat een GPS niet over de onderliggende data beschikt. Deze kan worden weergegeven (dat infobord bijv.) en ze kan worden gebruikt om een fietser weer op het juiste spoor te brengen als hij afgedwaald is. En dat is nu juist de kracht van een GPS, vind ik persoonlijk. Niet dat hij de reeds voorgekauwde data slaafs herhaalt. Dat kan hij natuurlijk ook, maar is slechts dan belangrijk als er wegwijzers zouden ontbreken. (Of als de routenetwerken door elkaar heen beginnen te lopen, zoals blijkbaar voorkomt in Duitsland)
mvg,
Jo
Edit: Ik heb de oneways nagekeken en voor zover ik kan zien, wordt er nergens van fietsers verlangd om verkeersregels te overtreden, in hoe ik de tentakels heb gedefinieerd.
Jo, dank voor alle moeite. Even een paar algemene principes en dan mijn reactie op de antwoorden op mijn vier casusvragen.
Eerste: Al zijn de principes van een fietsknooppuntennetwerk hetzelfde, de uitvoering is niet overal gelijk. Er zijn landelijke adviezen hier die aangegeven dat er routeborden (en verwijsborden) langs de weg worden geplaatst en één informatiepaneel (met kaart en nummer) bij het knooppunt. Wat ik zelf heb gezien in verschillende regio’s is dat er niet meerdere borden met dezelfde knooppunt aanduiding worden geplaatst vlakbij een knooppunt, i.t.t. wat ik lees over de situatie in België. (Maar omdat regio’s bepalen zelf hoe ze een netwerk uitvoeren, kan het hier ook plaatselijk anders zijn.)
Tweede: ik ga er van uit dat je van informatiepaneel naar –paneel fietst. Bij jou is het (door)fietsen langs een knooppunt , dat ook niet noodzakelijkerwijze bij een infopaneel zit. Ik zie die informatiepanelen (incluis knooppuntnummer) als onderdeel van de bebording van een routenetwerk, niet iets extra’s, en verwacht dat je daarlangs geleid wordt. (Als je dat niet wilt, fiets maar door!)
Derde: Fietsers moeten inderdaad alert blijven en kijken waar ze fietsen, maar als ze GPS navigatie gebruiken (en als die onze routerelaties volgt) moet het ze ook niet in verwarring brengen (bijvoorbeeld door aan te kondigen dat ze er al zijn terwijl een routebord aangeeft ‘fiets door, je bent er nog niet’).
Vierde: Het mappen moet voor ons allen te doen zijn, en het moet ook redelijk dicht op de werkelijkheid blijven; anders wordt het voorbehouden aan een paar “experts” (en dan houdt het op). Vandaar dat het van belang is dat je het aan ons uitlegt; daarvoor dank.
Casusvraag 1 knp 26 - knp 30: Alle routes waren sluitend (keerde terug op het beginpunt) en zijn dat nu niet meer. Is dat erg? Je zegt: “Software kan intelligent genoeg geschreven worden om te bepalen waar het ‘eigenlijke beginpunt’ … ligt”. (Je bedoelt het 2e rcn_ref 26 aan de overzijde van de weg). Ik kan ermee leven, maar vraag me af of navigatiesoftware inderdaad zo intelligent is (de mens wel).
Casusvraag 2: knp 98 – knp 26: Nee. Er is GEEN infopaneel aan de overzijde van de weg; die fietsers mogen draaien met hun hoofd wat ze willen, er is NIETS te zien. Ze staan dan namelijk helemaal niet bij het knooppunt (hier, de kruising). Zoals het routebord aangeeft, ze moeten nog even doorfietsen (pas daar bij de kruising zien ze aan de overzijde een infopaneel). Ik zou kunnen leven met nog een fictief knooppunt bij de kruising. Maar vereist het systeem dat je het zo ver weg plaats alleen omdat een ander route daar bij komt? Zo geeft het verkeerde informatie.
Casusvraag 3: knp 26 – 27: Ik weet niet of het nu goed is; dat is juist mijn vraag. Waarom zal navigatiesoftware je niet terugleiden de Baalsestraat in (rechtsaf) als je vertrekt vanaf het infopaneel? Er staan nu in de relatie drie keer knp De Heister (knp 26) en ik begrijp niet hoe dit te navigeren is (maar ik weet zeker dat het in de “oude” situatie wel te doen was).
Casusvraag 4: knp 25 – knp 26: Je zegt: “Van zodra een fietser een node bereikt die voorzien is van een rcn_ref, heeft hij wat mij [Polyglot] betreft het einde van die route bereikt. Op een ander niveau werd beslist of hij nu verder moet naar 27, 30 of 98.” Maar dit is knooppunt 26 niet, je hebt het zelf bedacht zonder dat het ergens te zien is in de werkelijkheid; zoals ik al eerder aangaf, hij moet doorfietsen naar de kruising om bij knp 26 te zijn. Een mapper die later langskomt, zal dit corrigeren (omdat uit de routeborden duidelijk blijkt dat knooppunt 26 nog niet is bereikt!). Even los van de discussie over infopanelen: hier ben je niet aan het vastleggen in de relatie wat in het veld te vinden is. Hoe is dit op te lossen?
Casusvraag 5 (door Jo gesteld in zijn “stel dat”): knp 25 – knp 98: Nee, een fietser onderweg van 25 naar knp 98 gaat niet via knp 26. Dat zou in OSM een ander relatie zijn die bij de bewuste aansluiting van het fietspad op de Baalsestraat gewoon naar rechts zou gaan. Hier zijn geen tentakels nodig maar relaties. Ik kan nu even niet nagaan of het een verbinding is dat in werkelijkheid (in dit geval de kaarten op de infopanelen en routeborden langs de fietspad) wordt aangegeven (het is niet in OSM opgenomen als relatie).
Extra: Infoborden wel/niet in de relaties: Eigenlijk behoren de infopanelen op zich niet opgenomen te worden op een weg maar, zoals alle tourism=information, gewoon er naast als node of area. Ze zijn dan niet routeerbaar. Maar in feite hebben velen in Nederland, als ook ik, anders gehandeld door een knooppunt op één plek, dicht naast een infopaneel, als rcn_ref=* op te nemen in de weg. Er is dus niet veel voor nodig om de infopanelen in relaties op te nemen (ze waren er al). Alle “extra” rcn_ref’s die je wegens de tentakels erin stopt, moeten dan een andere tag krijgen, zoals door Wimmel voorgesteld op talk-nl.
Tot slot: dank voor het nakijken. Als het nu volgens jou correct is, kan het dienen als een aardig use case.
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?
Ik ben niet van plan om knooppunt 26 De Heister zoals je het nu hebt uitgevoerd te gaan veranderen, tenzij er een consensus vormt om het anders te gaan doen (en dan veranderen zowel wiki als voorbeeld).
Ik had wel de hoop dat jij, Jo, zou inzien dat het ‘Baalsestraat knooppunt’ (44284208) niet goed was en het zou willen veranderen in iets beters dat het tentakelsysteem volgt en ook overeenkomt met de werkelijkheid.
Voor de mensen die later komen en door deze discussie heen worstelen nog dit:
Er is geen onduidelijkheid dat “in real life” knooppunt 44284208 NIET aangeduid mag worden als rcn_ref 26 De Heister. Als je daar aan komt fietsen (vanaf knp 98) staan er namelijk twee routeborden: één laat zien dat knp 26 nog rechtsaf is en de ander vertelt je dat je het knooppunt (d.w.z. knp 26) nadert. Je bent er dus nog niet. De routemakers (in real life, niet de relatiemakers in OSM) hebben het zo bepaald dat je nog door moet fietsen naar de kruising, want de kruising is knp 26 voor die planners .
Ik begrijp dat dat als routetechnisch onhandig wordt ervaren door Jo (er komt namelijk hier een tweede route, vanaf knp 25, bij) maar begrijp niet dat er dan wordt gekozen om de werkelijkheid te negeren.
Ik kan je niet zeggen of de illustraties helpen, Jo, want ik ken de situatie al veel te goed en heb je redeneringen hier en op talk-nl op de voet gevolgd. Iemand anders zal daarop moeten reageren. (heren, zijn jullie er nog ? … ).
Ik vind Frank’s suggestie van een note tag 25-26 - 98 wel een goeie wat dit soort situaties van overlappende routes komt hier ook veelvuldig voor.
Zie bijv http://www.openstreetmap.org/?lat=52.1459&lon=5.4228&zoom=14&layers=C
-route 63-66 overlapt met voor een groot deel met 63-97
-route 05-63 overlapt met 63-66
-route 78-96 overlapt op de Horsterweg met 78-09 (omdat de Engweg bij KP 78 uit de route is gehaald)
Ik ben het volledig eens dat het knopensysteem hier slecht en onlogisch in elkaar is gezet,
maar het is nu eenmaal de praktijk en om daar een ander logischer systeem van te mappen op OSM is ook niet goed.
Het zou interessant zijn te weten waar welke bordjes gebruikt worden. Bij mij in de omgeving staat (meestal) ook het knooppuntnummer op het bordje bij aankomst bij het knooppunt. Zie bijvoorbeeld http://wiki.openstreetmap.org/wiki/File:NL_Knooppuntbord_met_verwijzingen.jpg. Daarnaast is het paneel met kaart en knooppuntnummer soms afwezig en/of niet te vinden. Op basis hiervan had/heb ik geen moeite met de ‘tentakels’; vanuit mijn ervaring is dat een goede, werkbare oplossing die aansluit bij wat ik buiten zie.
De suggestie voor zo’n note tag kwam van mij. Je bent de eerste die daarop reageert. Ik begrijp heel goed dat het plaatsen van een knooppunt zo ver weg van het kruispunt wat controversieel is. Ik ga de situatie dus aanpassen. Eigenlijk is het zelfs goed, want nu kunnen die (toekomstige) screenshots, gebruikt worden als voorbeeld voor een route die als tag state=connection meekrijgt. En ik pas mijn script aan, zodat het overweg kan met dat soort constructies. Daar was ik namelijk nog niet aan toegekomen. (Ik moet gewoon de uitzondering toevoegen dat routes met state=connection niet gecontroleerd hoeven te worden op het hebben van nodes aan de uiteindes voorzien van een rcn_ref). Het script tracht echter ook routes ‘op te pikken’/te detecteren, maar voorlopig doe ik dat enkel op nodes die een rcn_ref hebben en niet op elke node van elk way-lid van de routerelaties.
Het script is zo opgezet dat als je een aantal nodes die een rcn_ref hebben, toevoegt aan een networkrelatie met network=rcn, dat het dan voor elk van die nodes gaat kijken welke routes kunnen worden toegevoegd aan de networkrelatie. Je kan dus starten met een networkrelatie die enkel uit nodes bestaat en als je daar het script op loslaat, heb je achteraf een networkrelatie waar alle routes mooi tussen de nodes worden ingevoegd, eventueel voorzien van een role=connection, indien het om een verbinding naar een knooppunt die behoort tot een andere networkrelatie gaat.
Mijn manier van werken is dus, als volgt:
alle routes uit een networkrelatie gooien, zodat er enkel nodes overblijven.
deze nodes sorteren op knooppuntnummer (dit helpt enorm bij het verwerken van het wikrapport achteraf)
dan het script laten lopen
gemelde problemen oplossen
script weer laten lopen, enz
nog even op ODbL controleren
naar de server versturen
Dat ga ik vanaf nu allemaal niet meer doen. Het is te tijdsintensief en er zijn genoeg mappers actief op deze netwerken die de fakkel kunnen overnemen.
Wat ik nog wel ga doen, is mijn script alle netwerken laten controleren (zonder neveneffecten) en het resultaat van die analyse posten op de wiki. Ik ben bezig met het downloaden/refreshen van alle netwerken in Nederland. Dus het rapport zal pas binnen een week of twee worden gepost.
En dan ga ik terug naar OV in Vlaanderen (De Lijn) en van zodra Toerisme Vlaanderen met data over de brug komt, begin ik daar een proces voor uit te werken om die te integreren in OSM, inclusief kwaliteitscontrole en vlotte manier om updates komende van upstream te verwerken.
