Routing bij fietsknooppunten bij kruisingen met "tentacles"

Frankl2009 · 2011-11-28T18:16:08.000Z

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.

Polyglot · 2011-11-28T19:59:12.000Z

Frankl2009:

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.)

Toch lijkt het mij interessant om globaal zoveel mogelijk dezelfde basisregels te kunnen toepassen

Frankl2009:

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!)

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.

Frankl2009:

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’).

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.

Frankl2009:

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.

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.

Frankl2009:

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).

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.

Frankl2009:

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.

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)

Frankl2009:

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).

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.

Frankl2009:

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?

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.

Frankl2009:

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).

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.

Frankl2009:

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.

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)

Frankl2009:

Tot slot: dank voor het nakijken. Als het nu volgens jou correct is, kan het dienen als een aardig use case.

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

Frankl2009 · 2011-11-29T09:57:11.000Z

Polyglot:

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.

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.

Polyglot:

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 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 ? … ).

ligfietser · 2011-11-29T10:52:37.000Z

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.

Jeroen_Muris · 2011-11-29T11:12:06.000Z

cartinus:

Als je in (het grootste deel van) Nederland bij een knooppunt aankomt zie je een bordje zoals deze:
http://wiki.openstreetmap.org/wiki/File:NL-knooppunt.jpg
Daarop is niet te zien bij welk knooppunt je zojuist bent aangekomen. Dit staat alleen op de grote borden met de kaart. Ik weet minstens één plaats waar dit grote knooppuntbord zeker 50 meter van het kruispunt vandaan bij een bankje staat. Toch taggen de meeste Nederlanders dan de lokatie van het bord en niet van het kruispunt met de rcn_ref tag.

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.

Polyglot · 2011-11-29T11:30:24.000Z

ligfietser:

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.

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.

Er is nog genoeg te doen…

ligfietser:

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.

Geen probleem.

ligfietser · 2011-11-29T11:35:57.000Z

In de regio Utrecht staan er nooit knooppuntnummers op de bordjes bij het knooppunt zelf

Er is wel meestal een overzichtsbord:

JanWandelaar · 2011-11-29T11:47:07.000Z

Bij het netwerk dat ik in Noord Limburg ken staat het nummer ook steeds op het bord met de overzichtskaart (en niet op de richtingsborden)
Bij mijn weten staat er altijd een overzichtskaart bij een knooppunt (van die 4 knooppunten die ik dagelijk zie is dit zeker zo).

De routeborden naar het volgende knooppunt zien eruit zoals op de foto van Cartinus :
http://wiki.openstreetmap.org/wiki/File:NL-knooppunt.jpg

Frankl2009 · 2011-11-29T21:55:44.000Z

Jeroen Muris:

Het zou interessant zijn te weten waar welke bordjes gebruikt worden.

In Stadsregio Arnhem Nijmegen zijn de informatiepanelen op (of dichtbij) de knooppunten en routeborden langs de weg zo uitgevoerd (naar Picasa).

Frankl2009 · 2011-11-29T22:36:05.000Z

ligfietser:

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.
…
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.

Suggestie was van Jo (maar dat had hij al opgemerkt). Ik vind niet dat het hier onlogisch is opgezet (dat zal dus afhangen van de regio waarin je fietst).
Mijn doel was: uitzoeken of wat ik als mapper vind in het veld ook zo overgenomen wordt in het systeem dat hij nu voorstelt. Het “Baalsestraat” knooppunt en het 5e casusvraag (hoe moet je van knp 25 bij knp 98 komen?) bleven nog in spel.
Ik heb nu het routekaart op het infopaneel bekeken en de route nagelopen in het veld. (Picasa url boven).

Route 25-98 staat niet op de kaart bij het infopaneel.

Op de routeborden onderweg van knp 25 naar knp 26 staat alleen knp 26 aangegeven, tot aan het Baalsestraat knooppunt.

Voor mij betekent dat dat 25-98 terecht niet in OSM als relatie is opgenomen. (Ik zou het zelf niet toevoegen, en als het er wel was, zou ik het, na overleg, willen verwijderen.)

Het is niet mogelijk om direct van 98 naar 25 te fietsen (wegens het enkelrichting fietspad); dat kan alleen via knp 26.

Het is wel mogelijk om van 25 direct naar 98 te fietsen zonder knp 26 aan te doen; er staat namelijk onderweg van knp 25 naar knp 26 één keer een routebord richting knp 98 (en wel bij dat Baalsestraat knooppunt in de rij richting als je uit het eenrichting fietspad komt).

Er is dus een oneffenheid in de werkelijke knooppuntroute.

Vraag is of we zo iets ook in OSM moeten modeleren? Of die “state=connection” de oplossing is? En wat dat dan gaat inhouden?

Polyglot · 2011-11-29T22:44:49.000Z

Ik ga nu aan de slag met het ombouwen van het model waarbij ik KP 26 had uitgebreid, naar een model waarin 25-26 - 98 als een route met tag state=connection wordt beschouwd.

Ik ben het ermee eens dat dat inderdaad logischer zou zijn. (Ik had zelf ook pas laat opgemerkt dat er daar nog een extra route op dat knooppunt leek toe te komen). Mijn eerste reflex was om dan KP 26 uit te breiden, wat me eenvoudiger lijkt naar routing toe. Het weerspiegelt inderdaad niet de werkelijkheid en is dus bijgevolg niet hoe we dat willen ‘coderen’ in OSM.

Ik ben blij dat nu de discussie daarover gaat en niet over de tentakeloplossing in haar algemeenheid. Ik had gaarne van anderen bevestiging gekregen of de door mij gemaakt screenshots verheldering brengen in het begrip van het hoe en waarom van die ‘extensies’, die ik tentakels ben gaan noemen. (Omdat dat een woordje is dat goed werkt in het Engels en Nederlands en omdat ik ze in eerste instantie ook wat ‘lelijk’ vond)

Ik zal deze post bijwerken als ik klaar ben met het aanpassen van de routerelaties. Het aanpassen van de screenshots, zal wat langer in beslag nemen.

Jo

Update: Ik heb het knooppunt De Heister 26 aangepast en had graag geweten of het zo acceptabel is, nu.

Polyglot · 2011-11-30T00:06:35.000Z

ligfietser:

Hoi Frank,
Maakt voor mijn OFM niets uit, die trekt zich niks van rcn_ref tags aan. Wel vervuilt het al de fietskaarten aanzienlijk als bijv op een rotonde meerdere rcn_refs worden geplaatst, ik ben er daarom ook geen voorstander van. Ik heb de indruk dat alles wat niet in zijn systematiek past hij wil gaan aanpassen op OSM en dat lijkt me een verkeerde werkwijze. Zo heeft hij allemaal onbekende of onduidelijke knooppunten negatieve nummers gegeven in OSM (gelukkig nog niet in Nederland) als een soort FIXME, zie http://www.openstreetmap.org/?lat=50.5971&lon=6.2967&zoom=13&layers=C

Die negatieve knooppuntnummers waren een reactie op andere mappers die aan beide uiteinden van een route met als tag state=connection, grote vette X’en hadden geplaatst. Aangezien ik tracht om dat om te zetten naar een geheel getal, verslikte mijn script zich daarin. Waar ik het in Nederland had toegepast, heb ik het ondertussen gewijzigd/verbeterd/rechtgezet. Waar ik het in Duitsland heb toegepast, verwacht ik dat een lokale mapper deze negatieve nummers vervangt door ofwel het eigenlijke knooppuntnummer (dat kan ik onmogelijk doen), ofwel verklaart dat daar eigenlijk geen knooppunt is.

Dit vraagt enige toelichting: In Duitsland bestonden sommige networkrelaties niet uit nodes en routerelaties, maar uit ways. Ik heb er zo twee aangepast, bij wijze van ‘seed’, in de hoop dat ze het hiërarchische systeem, dat wij ontwikkeld hebben, daar ook gaan toepassen. Ik heb daar nog verbazingwekkend weinig reactie op gekregen, wat enigszins teleurstellend is, want dat betekent dat daar weinig mappers echt actief met de knooppuntennetwerken bezig zijn. Ik ken er slechts 2 en die zijn ook in Nederland, resp. België (Oostkantons/Hoge Venen) actief.
Daar bleken dus op somige plaatsen 3 routes bij elkaar te komen, maar ik miste dus het knooppuntnummer. Een negatief nummer lijkt mij een vrij duidelijk signaal dat er daar iets mis is, maar mijn script heeft er geen moeite mee.

Een ander probleem in Duitsland is dat niet enkel knooppuntenrouterelaties, maar ook andere regionale netwerken network=rcn meekrijgen. Deze kunnen echter worden herkend, omdat ze dan blijkbaar steeds een ref-tag hebben. Terwijl dat voor onze routes niet het geval is.

Zo hebben jullie wat anecdotes over wat ik al ben tegengekomen tijdens m’n virtuele ontdekkingstocht langsheen de fietsknooppunten

mvg,

Jo

Polyglot · 2011-11-30T09:42:40.000Z

Frankl2009:

Vraag is of we zo iets ook in OSM moeten modeleren? Of die “state=connection” de oplossing is? En wat dat dan gaat inhouden?

Ik heb het kruispunt aangepast, waarbij ik rekening heb proberen te houden met je opmerkingen. Kan je eens gaan kijken of het nu eerder de ‘aangeduide’ werkelijkheid benadert? Zo ja, dan maak ik nieuwe screenshots voor de wiki.

Er is een sterke vereenvoudiging opgetreden door dit toe te passen. Dat is dus zeker positief. Ik kan eigenlijk niet inschatten of zo’n route met als tag state=connection vlot werkt bij het routen, maar dat hoeft geen beletsel te zijn. Het enige wat ik nu probeer te bekomen, is een toestand, waarin kwaliteitscontrole mogelijk wordt, zodat er gedetecteerd kan worden, wanneer routes onderbroken geraken door wijzigingen aan de leden (ways) die er deel van uitmaken.

Bedankt,

Jo

Frankl2009 · 2011-11-30T15:55:08.000Z

Polyglot:

Ik heb het kruispunt aangepast, waarbij ik rekening heb proberen te houden met je opmerkingen. Kan je eens gaan kijken of het nu eerder de ‘aangeduide’ werkelijkheid benadert? Zo ja, dan maak ik nieuwe screenshots voor de wiki.

Na enige naspeuringen denk ik dat je:
(a) verwijdert rcn_ref=26 en naam van node 44284208
(b) voegt een rcn_ref=26 en naam toe aan node 44287540
(c) relaties 1686570 (26-27) en 957169 (25-26) aanpast om naar node 44287540 te lopen (met role=forward op de ways).
(d) relatie 106974 (26-30) aanpast om van node 44287540 te lopen (met role=forward) via node 471420303 , wat ook voorzien is van rcn_ref=26 en naam tags.
(e) relatie 106973 nu laat vertrekken van het “Baalsestraat” node , 44284208

Je vraag was hoe ik het als local mapper bekijk:

Wat meteen opvalt (punt (e)), is dat relatie 106973 op de kaart niet vertrekt van de knp 26 kruising.

Ik weet niet of navigatiesoftware de fietsknooppuntroute vanaf knp 26 richting knp 98 vindt.

Het lijkt me dat het problemen zal geven bij het maken van een kaart, met route knp 26 - knp 98.

Ik denk dat een mapper in het veld dit nooit zo zal mappen. Ook niet met meer uitleg.

Voor wat de navigatie en kaart kwesties betreft: Ik weet niet of het zou helpen zo'n "hulpstukje" relatie met state=connection te maken en die toe te voegen aan de relatie 26-98 om de gat te vullen. Maar het wordt wel nog ingewikkelder en ik betwijfel of mappers het zo gaan doen. Ik zit er te dicht op om te weten of ik het zou snappen, zonder alle voorgeschiedenis. Iemand anders misschien?

Dan punt (d): er zal een reden zijn om relatie 106974 (26-30) langs twee rcn_ref=26 nodes te leiden, maar het likt me niet logisch. Edit: en het probleem is, als het niet logisch is, denk ik dat mensen het gewoon niet gaan doen.

Polyglot · 2011-11-30T22:01:44.000Z

Frankl2009:

Polyglot:

Ik heb het kruispunt aangepast, waarbij ik rekening heb proberen te houden met je opmerkingen. Kan je eens gaan kijken of het nu eerder de ‘aangeduide’ werkelijkheid benadert? Zo ja, dan maak ik nieuwe screenshots voor de wiki.

Na enige naspeuringen denk ik dat je:
(a) verwijdert rcn_ref=26 en naam van node 44284208

Dat was het eindpunt van wat voorheen route 26-98 was. Deze route heeft nu niet meer te maken met KP26 en eindigt hier, maar het het heeft dus geen zin meer om dit KP26 te blijven noemen.

Frankl2009:

(b) voegt een rcn_ref=26 en naam toe aan node 44287540

Dit is het nieuwe eindpunt van 25-26 en hier komt dus een rcn_ref=26

Frankl2009:

(c) relaties 1686570 (26-27) en 957169 (25-26) aanpast om naar node 44287540 te lopen (met role=forward op de ways).

25-26 moet uiteraard een beetje worden verlengd tot aan haar nieuwe eindpunt. 26-27 heeft geen tentakel meer nodig om verkeer komende van 98 of 25 te begeleiden tot aan haar eigenlijke startpunt.

Frankl2009:

(d) relatie 106974 (26-30) aanpast om van node 44287540 te lopen (met role=forward) via node 471420303 , wat ook voorzien is van rcn_ref=26 en naam tags.

Dat is een tentakel dat verkeer komende van 25 begeleidt tot aan het eigenlijke startpunt. Dit startpunt is toevallig ook het eindpunt van 26-27 (of 27-26, zo je wilt) en heeft dus een rcn_ref=26 (en een naam omdat dat in dit netwerk blijkbaar gebruikelijk is).

Frankl2009:

(e) relatie 106973 nu laat vertrekken van het “Baalsestraat” node , 44284208

Je vraag was hoe ik het als local mapper bekijk:

Wat meteen opvalt (punt (e)), is dat relatie 106973 op de kaart niet vertrekt van de knp 26 kruising.

Het is een route tagged met state=connection geworden tussen KP 98 en een punt ergens tussen 25 en 26. Ik kan natuurlijk niet zien wat er aan weerskanten van de wegwijzers op die route staat. Als de ene kant 98 en de andere kant 26 heeft, dan was mijn vorige manier van werken perfect geldig, want dan is dat wel een route met als eindpunt KP 26.

Maar goed, ik voel de nattigheid al. Je wilt dat deze doorgetrokken wordt tot waar ik het eindpunt van 25-26 nu geplaatst heb? Ach ja, waarom ook niet. Ik houd er niet van om ways dubbel te gebruiken voor iets anders dan tentakels, maar waarom ook niet. Voor mijn kwaliteitscontrole maakt dit niets uit. Als je het zo wilt, dan moet (wat nu dan weer 26-98 geworden is, dezelfde ‘tentakels’ krijgen als 25-26 (maar dan omgekeerd)).

Frankl2009:

Ik weet niet of navigatiesoftware de fietsknooppuntroute vanaf knp 26 richting knp 98 vindt.

Dat was inderdaad de reden waarom ik in eerste instantie de andere oplossing had voorgesteld. Zonder kennis van welke bordjes nu precies waar staan, was dat nog niet zo’n slechte benadering, al zeg ik het zelf.

Frankl2009:

Het lijkt me dat het problemen zal geven bij het maken van een kaart, met route knp 26 - knp 98.

Als die route een route is met als tag state=connection, dan bestaat die niet als route 26-98, dan is dat route “25-26 - 98”

Frankl2009:

Ik denk dat een mapper in het veld dit nooit zo zal mappen. Ook niet met meer uitleg.

Ik moet toegeven: het is eigenlijk een absurde situatie die ze daar gecreëerd hebben. Ondertussen heb ik begrepen dat het enkel nog maar gekker wordt… en ik begin hoe langer, hoe meer zin te krijgen om zo snel mogelijk van de hele zaak weg te lopen, euh fietsen. Als ik had geweten in wat voor een wespennest ik m’n neus heb gestoken, was ik er waarschijnlijk helemaal niet aan begonnen. Lennard wist hoe ingewikkeld het allemaal in elkaar zat en heeft ‘urge’ om iets gelijkaardigs te doen onderdrukt.

Van de andere kant ben ik blij dat ik toch al zover ben gekomen als dit en waarschijnlijk moet ik het nu allemaal wat proberen los te laten.

Frankl2009:

Voor wat de navigatie en kaart kwesties betreft: Ik weet niet of het zou helpen zo’n “hulpstukje” relatie met state=connection te maken en die toe te voegen aan de relatie 26-98 om de gat te vullen. Maar het wordt wel nog ingewikkelder en ik betwijfel of mappers het zo gaan doen. Ik zit er te dicht op om te weten of ik het zou snappen, zonder alle voorgeschiedenis. Iemand anders misschien?

Dan punt (d): er zal een reden zijn om relatie 106974 (26-30) langs twee rcn_ref=26 nodes te leiden, maar het likt me niet logisch. Edit: en het probleem is, als het niet logisch is, denk ik dat mensen het gewoon niet gaan doen.

De reden is, zoals altijd, zeer logisch: Die twee knooppunten met rcn_ref 26 zijn allebei eindpunten van één van de routerelaties die toekomen op KP26.
Van elk van de eindpunten van de andere relaties die toekomen op een KP, worden er tentakels gelegd om fietsers te begeleiden naar het eigenlijke startpunt van de relatie waar we mee bezig zijn. Deze tentakels hebben altijd een role; forward of backward. Soms zijn deze tentakels ‘telescopisch’ Ze vormen een aaneenschakeling. Soms is het eerder een vork, met als gemeenschappelijk punt het eigenlijke startpunt van de route.

Ik merk dat de illustraties, spijtig genoeg, niet geholpen hebben voor een beter begrip van het hoe en waarom van de tentakels. En ik weet niet meer hoe ik ze op een betere wijze kan uitleggen.

Ik heb prille plannen om op 10 december naar Baarn te komen. Is dat heel ver weg voor jou/jullie?

http://www.GeoFreedomDay.nl

Of heeft het zin dat ik op 11 december via Arnhem/Nijmegen/Den Bosch of Tilburg terugreis? (De laatste 2 liggen voor mij meer voor de hand).

Jo

Frankl2009 · 2011-12-01T01:54:22.000Z

Polyglot:

Frankl2009:

je verwijdert rcn_ref=26 en naam van node 44284208

Dat was het eindpunt van wat voorheen route 26-98 was. Deze route heeft nu niet meer te maken met KP26 en eindigt hier, …

Frankl2009:

Wat meteen opvalt (punt (e)), is dat relatie 106973 op de kaart niet vertrekt van de knp 26 kruising.

Het is een route tagged met state=connection geworden tussen KP 98 en een punt ergens tussen 25 en 26.
…

En daar gaat het fout, want de route is altijd 26-98 geweest. Zo had ik het in de relatie vastgelegd (vanaf infopaneel bij knp 26 t/m knp 98). Dat is de werkelijkheid en is niet aan te passen omdat dat beter uitkomt in de theorie.

Polyglot:

Ik kan natuurlijk niet zien wat er aan weerskanten van de wegwijzers op die route staat.
…

Gelukkig ik wel.

Als je vanaf knp 26 infopaneel de weg oversteekt naar dat nieuwe rcn_ref=26 van je dan zie je een routebord met pijltje rechts naar knp 98; even verder (bij het beruchte Baalsestraat bij de bocht) weer een bord met pijltje links naar knp 98.

In omgekeerd richting vanaf knp 98 zie je bij die bocht een pijltje rechts naar knp 26 met een onderbord ‘je nadert het knooppunt’

Polyglot:

Je wilt dat deze doorgetrokken wordt tot waar ik het eindpunt van 25-26 nu geplaatst heb? Ach ja, waarom ook niet. Ik houd er niet van om ways dubbel te gebruiken voor iets anders dan tentakels, maar waarom ook niet. Voor mijn kwaliteitscontrole maakt dit niets uit. Als je het zo wilt, dan moet (wat nu dan weer 26-98 geworden is, dezelfde ‘tentakels’ krijgen als 25-26 (maar dan omgekeerd)).

Niet wat IK wil, maar wat er op de borden staat, Jo. Ga er van uit dat de relatie accuraat was toen je hem aantrof. Gewoon twee rcn relaties op dit stukje weg, met role=forward op die vanaf 25 naar 26 en niets op die van 26-98.

Polyglot:

Ik moet toegeven: het is eigenlijk een absurde situatie die ze daar gecreëerd hebben.

Het is eigenlijk helemaal niet absurd maar heel duidelijk, als je daar fietst. En er is maar één onvolkomenheid (en gelukkig dat hij er is): een extra routebord bij het “Baalsestraat” node die je, als je dat wilt, direct richting knp 98 leidt i.p.v. eerst naar knp 26.
Niets tegen twee verschillende routes over eenzelfde stukje weg, toch? Nogmaals, het geeft geen enkel last als je daar fietst en de routebordjes volgt.

Polyglot · 2011-12-01T07:05:46.000Z

Frankl2009:

Polyglot:

Je wilt dat deze doorgetrokken wordt tot waar ik het eindpunt van 25-26 nu geplaatst heb? Ach ja, waarom ook niet. Ik houd er niet van om ways dubbel te gebruiken voor iets anders dan tentakels, maar waarom ook niet. Voor mijn kwaliteitscontrole maakt dit niets uit. Als je het zo wilt, dan moet (wat nu dan weer 26-98 geworden is, dezelfde ‘tentakels’ krijgen als 25-26 (maar dan omgekeerd)).

Niet wat IK wil, maar wat er op de borden staat, Jo. Ga er van uit dat de relatie accuraat was toen je hem aantrof. Gewoon twee rcn relaties op dit stukje weg, met role=forward op die vanaf 25 naar 26 en niets op die van 26-98.

Polyglot:

Ik moet toegeven: het is eigenlijk een absurde situatie die ze daar gecreëerd hebben.

Het is eigenlijk helemaal niet absurd maar heel duidelijk, als je daar fietst. En er is maar één onvolkomenheid (en gelukkig dat hij er is): een extra routebord bij het “Baalsestraat” node die je, als je dat wilt, direct richting knp 98 leidt i.p.v. eerst naar knp 26.
Niets tegen twee verschillende routes over eenzelfde stukje weg, toch? Nogmaals, het geeft geen enkel last als je daar fietst en de routebordjes volgt.

Misschien is het slechts een persoonlijk bezwaar van mijnentwege. Ik pas het straks nog 's aan, aan de nieuw verworven inzichten. Het zal op zich wel geen echt bezwaar zijn om stukken weg in meerdere relaties te gebruiken, maar ik vind dat dat dan tentakels hadden moeten zijn.

Wat mij betreft, is dit knooppunt nu niet meer geschikt om als ‘referentievoorbeeld’ te dienen op de wiki. Een mooie casus, voor wat er allemaal fout kan gaan bij het ontwikkelen van een netwerk, maar geen referentie om als voorbeeld te dienen om een aantal concepten zoals tentakels en routes met een tag state=connection uit te leggen.

Jo

Frankl2009 · 2011-12-02T18:40:25.000Z

Dank voor alle moeite, Jo.
Hopelijk komen er niet al te veel van dit soort knooppunten voor, al ben ik bang dat bij alle rotondes en kruisingen met aparte fietspaden het aan de orde is.
Ik ga in alle rust nadenken wat dit betekent voor de relaties die ik nog moet gaan invoeren of afmaken.
Ik ben het wel met je eens dat het nuttig is om op een consistente manier de routes in te voeren in OSM.

Polyglot · 2011-12-02T19:56:06.000Z

Hallo Frank,

Ik denk inderdaad dat er zo nog veel knooppunten zijn die gesplitst kunnen/zouden moeten worden. Maar bij de meeste zal daar niet een paar honderd meter verder op de valreep nog een route bijkomen.

Ik heb 26-98 weer hernoemd, z’n tag state=connection er weer afgehaald en 'm verlengd tot aan KP 26. Nu heeft hij ook wel weer tentakels om fietsers die van de andere routes aankomen te begeleiden naar z’n eigenlijke startpunt.

Jo

Mattheus · 2011-12-24T19:38:38.000Z

Polyglot:

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:

http://wiki.openstreetmap.org/wiki/User:Polyglot/Some_ways_to_simplify_editing_cycle_node_routes_with_JOSM

(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?

http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging#Split_nodes_and_the_tentacles_extending_the_routes_to_connect_them

mvg,

Jo

Polyglot, als je weer correcties aanbrengt in OSM, zou je dan ter plekke willen kijken of de situatie klopt. Op 22 december heb je één van de knooppunten in de provincie Groningen verwijderd die er wel degelijk staat. Ik had nog geen verbindingen gemaakt omdat de knooppunten in dat gebied nog niet compleet waren. Vandaag heb ik de knooppunten in gebied gezocht en op de OSM gezet. Dit betreffen knooppunten die ik persoonlijk opzoek, fotografeer en pas dan op de OSM zet. Ik vind het teleurstellend als iemand m.b.v. een script knooppunten opspoort en verwijdert, terwijl ze er wel staan. De provincie Groningen werkt niet met infoschermen waarop het knooppuntnummer staat. De nummers staan op de bordjes. Ik ken vier gevallen waar hetzelfde knooppuntnummerdicht bij elkaar op twee plekken staat.

De knooppunten worden aangelegd door de firma Folkersma Verkeerstechniek uit Marum. Deze firma heeft ook de knooppunten geplaatst in Friesland. Ik zie dat jij daar ook druk bezig bent geweest met corrigeren. Ik hoop niet dat jij bestaande dingen hebt verwijderd.