Routing bij fietsknooppunten bij kruisingen met "tentacles"

@ligfietser en andere belangstellenden:

User:Polyglot (Jo) is al een tijdje bezig alle fietsroutenetwerken in België en Nederland onder handen te nemen. Hij heeft ook op de wiki (Cycle Node Network Tagging) het e.e.a. aangepast om dit te documenteren. Discussie daarover voert hij op talk-nl. Een controle pagina heeft hij ook aangemaakt met door hem geconstateerde ‘fouten’.

Nu hij FRN Stadsregio Arnhem Nijmegen onder handen neemt, zie ik de consequenties voor mijn eigen werkwijze bij “complexe” kruisingen (en rotondes) waar fietspaden een rol spelen. De discussie gaat over kruisingen/rotondes met vrijliggend fietspaden.

Ik heb steeds een rcn_ref gezet alleen bij de kruising van de fietspaden (in FRN SRAN staat daar een infopaneel) en met role=forward (evt =backward) de route naar dat punt geleid. Er zijn uiteraard meestal meerdere routes die om de kruising heen geleid moeten worden; en er zijn de verkeersborden en -regels waar je rekening mee moet houden (soms wel, soms geen tweerichting fietspaden).

Ik begrijp dat zijn werkwijs inhoudt dat er meerdere rcn_ref voor dezelfde knooppunt komen. Hij behandelt dit onder: “Split nodes and the tentacles extending the routes to connect them”.

Hij heeft nu zo’n kruising aangepast-- in relatie 957169 (25-26) --en vraagt men (op mijn verzoek) op talk-nl te reageren, zie:
http://lists.openstreetmap.org/pipermail/talk-nl/2011-November/013432.html.

Ik ben tegen de “tentacle”-oplossing bij knooppunten waar er niet fysiek een tweede (derde, vierde) paneel of bord te vinden is in het veld, want het wordt zo een stuk ingewikkelder voor mappers om gewoon een route te volgen en vast te leggen in OSM. Maar als dat de consensus wordt, zal ik me bij neerleggen.

@ligfietser: Ik wil echter weten wat er met routing werkelijk gebeurt bij zo’n kruising. Of maakt het niets uit voor de router?

(Dit is denk ik functioneel niet anders dan de Goudappel oplossing om meerdere rcn_ref te leggen bij rotondes; maar daar was ik ook niet echt blij mee.)

Edit: kruising en relaties zijn sindsdien aardig aangepast. url gaat naar huidige situatie, wat enigszins verwarrend werkt.

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

Ik heb ook zo vaag-weg de discussie gevolgd op talk-nl (het is een boel tekst, dus ik heb niet alles gelezen), maar ik heb ook de indruk gekregen dat niet de werkelijkheid wordt gemapt, maar dat er ‘kunstmatige’ knooppunten worden ingetekend, ten dienste van bepaalde routerings-software.

Aannemende dat die indruk juist is, lijkt mij dit niet een wenselijke ontwikkeling. Als er maar één knooppunt is, moet er ook maar één worden getekend. Eventuele routerings- of andere sofware die daar niet mee overweg kan, moet dan maar slimmer worden geprogrammeerd.
Anders wordt het ‘mappen voor de renderer’, m.i. een heilloze weg.

Na het verhaal half gevolgd te hebben (het was mij iets te lang) over het splitsen van de knooppunten vraag ik mij ook af of het zo niet onnodig moeilijk wordt.
Wat vooral niet moet gebeuren dat de werkelijkheid niet te herkennen is op de kaart (of andersom).

Als je een knooppunt splitst naar 2 kanten van een weg, dan zou je voor de compleetheid ook weer routes moeten maken om deze aan elkaar te knopen.
Bv. van knooppunt 1 naar 2 over een fietspad aan een van de weg. Hier kun je verder naar knooppunt 3. Je kunt ook weer terug van knooppunt 2 naar 1 door de weg
over te steken naar het fietspad aan de overkant en dan terug te fietsen.

OFF TOPIC :
Er staat ook ergens een opmerking dat wandelnetwerken gemakkelijker zijn.
Dat is ook zo wat betreft de heenweg en terugweg, maar daar zijn ook zaken anders dan bij veel fietsnetwerken:

  • De nummers gaan in Brabant/Noord Limburg van 0-99. Binnen een netwerk komen meerdere keren dezelfde nummers voor, maar op de nodige kilometers afstand.
  • Soms zijn er 2 verschillende routes mogelijk tussen twee knooppunten, die beide gemarkeerd zijn.
  • Soms staat een knooppunt niet bij een kruising, maar bij een afslag naar links. Een klein stukje verder is er een afslag naar rechts. Op beide plekken staat dat een knooppunt paaltje met hetzelfde nummer. Zelf zet ik dan bij 2 paaltjes in de echte wereld ook 2 paaltjes op de kaart (rwn_ref). Om de route compleet te maken komt er een route tussen de knooppunten met hetzelfde nummer (zelfs 3 of 4 paaltjes met hetzelfde nummer heb ik gezien).

Natuurlijk. Had ik zelf moeten bedenken. Is een soort Pavlov-reactie: men zegt ‘routeerder’ ik denk “OFM”. :slight_smile:

Het effect treedt op bij hoge zoom (meer dan zoom12); op een kruising zie je (base layer op Cycle Map):
http://www.openstreetmap.org/?lat=51.4282&lon=5.4125&zoom=17&layers=C
Hangt er dus vanaf welke zoom je kiest.

Dat is wat er gebeurt.

Dat dacht ik ook, maar ik merk uit een reactie van Ben Laenen dat men er anders over denkt. Waar het infopaneel staat, wordt dan niet gezien als het knooppunt; dat informatiebord moet maar apart opgenomen worden (wat op zich wel waar is; tourism=information?). Het kruispunt in zijn geheel wordt kennelijk gezien als het knooppunt. En dan (@JanWandelaar) volgt het tentakelverhaal wat nodig is om de knooppunten met hetzelfde nummer weer onderling met elkaar te verbinden. Edit: ik begin dus erg te twijfelen wat nu wijs is.

Toch niet zo off-topic, want analoog aan de fietsnetwerken zouden de wandelnetwerken ook zo behandeld kunnen worden (als je wandelaars langs het ene fietspad heen en het ander fietspad terug laat lopen). Ik doe geen wandelknooppunten maar voor de LAW splits ik wel bij zo’n weg met fietspaden, zodat de route loopt waar ook werkelijk de verwijsborden staan (anders mis je ze, en alleen vertrouwen op je GPSje is maar niks.)

De tentakels zijn uitgevonden in België en zijn een logisch gevolg van de manier van bewegwijzeren aldaar. Als je in België bij een knooppunt aankomt ziet het laatste bordje er uit zoals deze:
http://wiki.openstreetmap.org/wiki/File:Knooppunt-Waasland.jpg
Vanaf elke richting dat je bij het kruispunt aankomt staat er zo’n bordje, waarop dus het knooppuntnummer van het knooppunt waar je bent vermeld is. Bij complexe kruispunten staan deze dus bij kruisingen van verschillende ways in OSM. Bovendien staan er in Belgie (bijna) nergens borden met een kaart erop.

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.

Tja, dat verandert de zaak.
Ik ben net bezig geweest met knooppunt 50 in Alkmaar (http://www.openstreetmap.org/?lat=52.633002&lon=4.755753&zoom=18&layers=M&mlat=52.63320&mlon=4.75480) en wil graag weten of ik het nou wel goed heb gedaan.

Ik begrijp dat in Belgie op 1 kruispunt meerdere borden kunnen staan met de mededeling dat ‘hier’ het knooppunt is.

Weet iemand een voorbeeld van waar die ‘tentakels’ te zien zijn?

De uitleg op http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging#Split_nodes_and_the_tentacles_extending_the_routes_to_connect_them begrijp ik eerlijk gezegd niet zo.

Lijkt mij wel goed (als je mapt zonder “tentacles”). Routerelatie doorleiden naar één knooppunt (waar er ondertussen een bord of paneel staat, hopelijk). Zo heb ik het ook steeds gedaan.

Nog twee dingen:

  1. Voorheen stond er op de wiki dat je ook het knooppunt in de routerelatie opneemt; dat vindt Polyglot niet nodig en heeft hij die instructie nu uit de wiki gehaald (en bij behandeling van de netwerken, uit de routerelaties ook). Ik heb hem gevraagd om voor FRN Stadsregio Arnhem Nijmegen het (voorlopig) niet uit de routerelaties weg te halen, want ik gebruik ze zelf wel.

  2. Het knooppunt zelf neem je hoe dan ook op in de netwerkrelatie (zo te zien is dat Noord-Kennemerland: relatie 305534, want zo staat het nog op de weg (node 47047628).

Edit: fietspad 136885099 kruist fietspad 135586317. Moet een van die twee niet bij die kruising een brug zijn (of een tunnel), of is het gelijkvloers? (En is dat ook zo voor een aantal van die andere kruisingen?)

Edit2: fietspad 136885099 heeft geen forward role. Dat is wel nodig.

Een voorbeeld heb ik hierboven genoemd (van Polyglot), al begrijp ik nog niet helemaal hoe dat moet werken. (Hij zegt dat het hem ook wat hoofdbrekens en misstappen heeft gekost.) Ik zie nog niet waarom we deze tentakel-oplossing nodig hebben, tenminste niet als we in het veld gemarkeerde knooppunten hebben.

Edit: URL was onjuist.

Goed, waar OSM-gebruikers gaan om te communiceren, zal ik volgen. Ik ben er niet zo blij mee dat ik deze discussie zowel op talk-be als talk-nl moest crossposten en heb er geen idee van hoe dat moet om alle betrokkenen te bereiken, als er ook nog een forum in het spel is. Maar ik pas me wel aan.

Ik zal beginnen met uit te leggen wat ik probeer te doen (en verontschuldig me vooraf dat dit weeral een lang epistel zal worden. Het kost mij echter moeite (en tijd) om het allemaal neer te pennen, dus wees a.u.b. zo beleefd om het ook even HELEMAAL te lezen)

Uitgangspunten:

  • liefst eenvormige regels, die dus over de grenzen van onze kleine landjes heen kunnen gelden voor alle knooppuntennetwerken (fiets, wandel, ruiter)
  • deze regels moeten zo eenvoudig mogelijk zijn, terwijl ze toch een accurate en bruikbare weergave van de werkelijkheid zijn

Ik ben dus, naar aanleiding van Fietsnet.be, vol goede moed begonnen aan het nakijken, hoe het zat met de kwaliteit van de ‘codering’ van de fietsroutenetwerken op OSM. Als ik vooraf had beseft wat ik me op de hals ging halen, was ik er waarschijnlijk gewoonweg niet aan begonnen. Ik ben nu echter ongeveer halfweg en vanaf nu is het dus zwemmen of verzuipen.

Ik heb zelf een drietal jaar geleden het FRN in mijn eigen omgeving (het oosten van Vlaams-Brabant) in kaart helpen brengen. Dat was toen kersvers en leuk om te doen. Ondertussen heb ik me met heel wat andere zaken, zoals bushaltes/routes, huisnummers, enz bezig gehouden.

Als ik nu met FRN’en aan de slag ga, is de insteek iets of wat anders. Ik kan niet overal gaan kijken hoe de situatie ter plaatse precies in elkaar zit en aangeduid is. Ik denk echter wel dat een top down aanpak even belangrijk is dan de gebruikelijke bottom up.

Dus ben ik knooppunten beginnen samenvoegen tot netwerken en netwerken weer gaan samenbrengen in collecties, zodat ik aan een kwaliteitscontrolescript een parameter kan meegeven om aan te geven wat ik op dat moment wil nakijken. Een (paar) route(s), een (paar) netwerk(en) of alle netwerken in een heel land.

En ik ben begonnen met het maken van een Pythonscript om de routes tussen deze knooppunten aan het netwerk toe te voegen, na te kijken of er wel degelijk aan beide uiteindes een knooppunt met een rcn_ref zit en of er wel degelijk van het lage naar het hoge KP en weer terug een continue weg beschreven wordt.

Daarbij ben ik in vele valkuilen getuimeld. KP’en met eenzelfde nummer met elkaar verbinden met een xx-xx routerelatie is er daar één van. (Ik had alle ‘tentakels’ op een bepaald moment gewoon in de prullenmand gegooid, omdat ik er niets van begreep wat al die stukjes weg met een role in die relaties zaten te doen)

Dit tot grote ontevredenheid van Eimai en nog een paar anderen die ‘het licht’ wel reeds hadden gezien.

Na veel vijven en zessen en kopbrekens (van mijnentwege) en weerstand (omdat ik niet inzag hoe ik m’n controlescript kon aanpassen, om ermee om te gaan) heb ik nu echter wel begrepen wat de kracht van die ‘tentakels’ is en ik zie nu in dat het wel degelijk een elegante oplossing is. En als een ‘evangelist’ ga ik nu dus verder noordwaarts om de ‘blijde boodschap’ te verkondigen :slight_smile: Als een recentelijk bekeerd man, begrijp ik volkomen dat deze manier van werken ook bij anderen heel wat weerstand oproept. En ik moet dus dringend een manier vinden om het op een bevattelijke(r) manier te beschrijven op de wiki. (sorry voor de metaforen, zo gelovig ben ik niet eens, maar ik vind het wel toepasselijk. Wil wel even opmerken dat ik geen ‘geloof’ tracht te verspreiden. 't Is meer zoals iemand die de kracht van, neem maar Linux, 10 jaar geleden al inzag en dat gaat ‘verkondigen’).

Hierbij wil ik opmerken dat er, tot voor kort, (toen ik die pagina voor het eerst las) helemaal niets te vinden was over die tentakels en gesplitste knooppunten die er aanleiding toe geven. Ik ben dus door schade en schande wijzer moeten worden. En heb ondertussen de ‘schade’ die ik, als een dolgedraaide olifant, had aangericht weer hersteld. (Gelukkig is het niet te moeilijk om routes tussen twee KP’en met hetzelfde nummer terug te vinden; xx-xx i.p.v. xx-yy).

Nu goed. Ik ben begonnen aan een titanenwerk en Jeroen heeft het script ook geïnstalleerd in JOSM en is nu bezig in Rotterdam, nadat hij wat routes had toegevoegd in Overflakkee. Hij ziet ondertussen in aan wat voor een monsterkarwij ik eigenlijk begonnen ben en van hem krijg ik veel steun en misschien zelfs enige bewondering.

Ik denk namelijk dat ik al wel het een en ander bereikt heb. Ik kan namelijk op regelmatige tijdstippen alle Belgische netwerken op een paar minuten tijd nakijken. Zo vind ik regelmatig fouten die geïntroduceerd worden door minder ervaren gebruikers, of medewerkers die rcn_refs zelfs gewoon verwijderen, omdat ze niet snappen waarvoor die dienen. Soms gaat het stomweg over het weer samenvoegen van twee ways o.i.d.

Maakt niet uit, mijn script pikt dat op (en ook nieuw toegevoegde routes) en geeft aan of er zich ergens problemen voordoen. Als we wensen dat onze data bruikbaar is/wordt voor buitenstaanders (zoals in dit geval Fietsnet.be), dan is deze oefening nodig en zels onontbeerlijk.

Nu wil Fietsnet zich niet echt beperken tot België. De Belgische fietsers keren ook niet plots om, als ze de (nagenoeg onzichtbare) grens bereiken. Vandaar dat ik dat ook niet heb gedaan. Ik krijg echter de indruk dat hoe langer ik bezig ben en hoe meer ervaring ik opdoe en hoe intelligenter ik mijn script ondertussen heb gemaakt, hoe trager ik vooruit schijn te komen. Ik heb al ettelijke obstakels overwonnen en ben al uit vele valkuilen geklommen, maar deze reactie had ik, eerlijk gezegd, niet verwacht.

Daarom ga ik dit hele project nu wat laten rusten. De gemoederen laten bedaren en alles wat laten bezinken.

Voor mij persoonlijk hoeft het niet zo nodig, maar ik had graag gehad dat we overal alles hetzelfde deden en dat we met een ‘open mind’ naar eventuele veranderingen in conventies zouden kijken, in plaats van die zonder meer af te wijzen.

Ik kan heel gemakkelijk zeggen: goed, dan neem ik dat netwerk niet mee op in m’n kwaliteitscontrole en daarmee is voor mij dan de kous af. Ik denk echter dat, alles wat ik in de voorbije maanden geleerd heb, dat ik dat in dat Pythonscript gecodeerd heb.

Ik heb dat gedaan met een extra bedoeling: het hebben van een referentie-implementatie voor iemand die aan routering wil gaan doen.

Het zou ook kunnen dat er gezegd wordt: het maakt niet uit dat mensen naar links gestuurd worden, dan gevraagd wordt om rechtsomkeert te maken en dan pas op de eigenlijke nieuwe route terechtkomen. Mij maakt dat eigenlijk ook niet uit en m’n script geeft er ook niet om. Er zit ondersteuning in om overweg te kunnen met die tentakels, maar als er nu netwerken zijn die daar geen gebruik van (willen) maken, voor mij geen probleem. Als de routes continu zijn, dan passeren ze de test. (1 rechte lijn van punt A naar punt B). Als er echter vorken inzitten (aan de uiteindes), zonder dat er meerdere KP’en inzitten met eenzelfde rcn_ref, dan wordt er een probleem gemeld.

Ik heb daar verder geen last van. Als ervoor gekozen wordt, om routes te ‘coderen’ met meerdere relaties die van punt tot punt gaan (maar dezelfde wegen dus meermaals gebruiken), ook geen punt.

Je gaat echter zien, dat als er twee standaarden zijn, twee werkwijzes in zo’n klein gebied, dat dat ook problemen gaat geven. Ik ben geneigd om alles te gaan splitsen wat niet expliciet op één enkele kruising van wegen toekomt en er zijn vele redenen waarom dit het geval kan zijn, steeds meer eigenlijk:

KP’n aan weerszijden van een (kanaal)brug
vrijliggende fietspaden
fietspaden rondom een rond punt
eigenlijk alle KP’en waar meer dan 3 routes samenkomen en waar dit niet op exact dezelfde node gebeurt

Zo, nu ga ik maar eens afsluiten. Bedankt aan wie tot hier meegelezen heeft en

een fijn weekeinde,

Jo

PS: sorry kan het niet laten (ben thread even aan het herlezen). Wat betreft het opnemen van KP’en in routerelaties. Aangezien ik de eenvoudigst mogelijke implementatie wens te bekomen, vind ik dat niet nodig. Frank heeft me echter gevraagd om die bij zijn netwerk niet weg te halen, dus heb ik het script aangepast om ze weer toe te voegen (want off line had ik ze al weggehaald). Voor het script is dat dus geen probleem, maar ik vind dat het extra en onnodige complexiteit toevoegt (en dus ook, in mijn ogen, meer overbodig werk betekent).

Je kan ook nog meedoen op irc misschien om te discussiëren :slight_smile: Maar dit is dus ook waarom ik geen grote fan ben van het forum: nog een plek waar de discussie plaats vindt.

En dan even cru stellen: er zijn al ellenlange discussies gebeurd over meervoudige knooppunten en hoe die te mappen en waarom. Om dit hier nu nogmaals opnieuw te doen, sorry, maar duik dan maar in de archieven van de andere kanalen. We hebben een systeem dat quasi volledig werkt, nauwkeurig de realiteit weerspiegelt, en niet moeilijk is eens je de moeite doet om het te begrijpen. Bij mijn weten is heel Vlaanderen nu op die manier gemapt, als NL niet mee wil, mij een zorg, maar dan hoop ik dat de reden meer is dan “wat lijkt me dit moeilijk”, of “er staat maar één overzichtsbord”.

Ja, er mag dan maar één overzichtsbord staan (er staat er soms ook één in België), nee het is niet zinvol om alle routes op dat exact punt te laten eindigen en vertrekken als daar in de realiteit niks voor bewegwijzerd is, door arbitraire stukjes toe te voegen op het einde of begin van elke route naar dat punt. Is FRN SRAN wel zo bewegwijzerd, dan ga ik eerst eens diep zuchten over wat ze daar hebben uitgespookt met die bewegwijzering, maar dan heb je ook niet veel keus om het zo te mappen. Ik ken het netwerk niet, dus zal je het zelf moeten weten. Maar als er niks van bewegwijzering naar dat overzichtsbord is, dan zijn de kruispunten waar je de bordjes vindt met de nieuwe knooppuntnummers – en ik heb nooit begrepen waarom ze in NL niet dat knooppuntnummer zelf daarop hebben gezet – de nodes waar je rcn_ref zal moeten gebruiken.

Hartelijk dank voor deze uitgebreide uitleg.
Het is erg goed om de uitleg nog een keer op een rij te hebb staan.

PS. Talk-nl lees ik wel af en toe, maar met posten beperk ik mij tot het forum.

In feite is niet enkel België/Vlaanderen nu reeds volgens het principe van gesplitste knooppunten (waar deze zich volgens een duidelijk gedefinieerde logica bevinden, op de eindpunten van elke route) en de tentakels (om fietsers van een ander netwerk naar het eigenlijke begin van de door de routerelatie beschreven route te leiden), maar alle netwerken ten zuiden van de Maas en Jeroen is in Rotterdam begonnen volgens dezelfde principes. Daarenboven ben ik ook in Duitsland de olifant gaan uithangen en ook daar zijn Kreis Heinsberg en Kreis Aachen al volgens deze inzichten aangepast.

In Duitsland ben ik trouwens ook nog wat andere problemen tegengekomen, zoals het gebruik van ‘rcn’ voor andere netwerken dan knooppuntennetwerken (deze hebben dan echter een ‘ref’ en zijn daaraan herkenbaar), maar ook de (voor ons) eigenaardige tendens om een losse node met een rcn_ref voor de knooppunten te gebruiken.

Ik had dat dus allemaal graag op één, zo eenvoudig mogelijke, noemer te geplaatst. Ik heb door dit allemaal te doen en door het te ‘formaliseren’ in

  1. een wikipagina met documentatie
  2. een Pythonscript

een onschatbare berg ervaring opgedaan en ik zou het op prijs stellen, als daarvan gebruik zou worden gemaakt, bij het bepalen van een ‘standaardmanier’ om die fietsknooppuntennetwerken te ‘coderen’. Ik zeg coderen i.p.v. in kaart brengen, omdat het daar eigenlijk op neer begint te komen. Wat hierbij zeer belangrijk is, is dat als iemand die de lokale situatie niet kent (en dat zijn de meeste van ons voor de meeste lokaties), die route zou willen nakijken, dat die dan tot dezelfde conclusies komt, dan de persoon die wel de kans heeft gekregen om het lokaal te gaan bekijken.

Ik kan me voorstellen dat dit wordt ervaren als IK die de regeltjes wil komen opstellen en opleggen, maar de meeste van die regeltjes heb ik niet uitgevonden. Het is wat ik geleerd heb, tijdens de voorbije maanden en waar ik nu dus ook volledig achter sta.
En jawel, ik heb ook geëxperimenteerd met andere manieren om het aan te pakken en ben daarvan teruggekomen.

mvg,

Jo

Ha Jo,

'k Heb het met bewondering gelezen. Geen idee dat er nog zoveel werk aan vast zit. Ben wel eens in het begin voorzichtig begonnen met die knooppunten in de Alblasserwaard, maar voelde me al snel die “olifant in de porseleinkast” met al die relaties.
Wel grappig dat Jeroen de routes al over m’n van de zomer gemapte nieuwe fietspaden in Flakkee heeft gelegd. Daar ben ik toen flink aan het “mappen” geweest.

Groet,
Eggie

Ik heb net telefonisch overlegd met Koen van Fietsnet.be. Ik had hem een paar dagen terug gevraagd om het wikidocument eens kritisch te lezen en na te gaan of hij er zo mee aan de slag kan. Hij had nog wat bedenkingen/vragen, die nu volledig uitgeklaard zijn. Hij ziet dat wat we nu beschreven hebben zeer weldoordacht is en kan de data zo gebruiken voor zijn routering en het geven van ‘instructies’ aan fietsers. (Dat is zijn belangrijkste aandachtspunt).

We gaan ook een bijeenkomst organiseren voor medewerkers van Fietsnet.be, waar ik dan uitleg zal geven over hoe JOSM te gebruiken voor het zo gemakkelijk mogelijk ingeven van fietsroutes/-netwerken. Ik heb Leuven voorgesteld, maar als blijkt dat er interesse is vanuit Nederland, dan wil ik dat ook wel naar Antwerpen proberen te verplaatsen, of een extra Mapping Party te organiseren, specifiek voor die fietsroutenetwerken.

Zo’n extra bijeenkomst kan voor mij dan zelfs ook in Tilburg ('t is lang rijden met de bussen van De Lijn (±3,5 uur, overstap in Turnhout), maar ik geraak daar helemaal gratis met m’n busabonnement). Verder naar het noorden zijn er geen bussen van De Lijn meer. Aan de andere kant zou ik wel eens een reden willen hebben om de 307 helemaal tot in Hamont te nemen. Maar dat ligt ‘in the middle of nowhere’ en daarenboven zo ongeveer aan het einde van de wereld en is eveneens een busrit van 3 uur (zonder overstap).

Jo

Jo,
Weet jij toevallig of ze bij Fietsnet.be ook van plan zijn een OSM kaarten overlay te maken? Ik zie nu alleen Google maps. Zou ook mooi zijn als dat tzt doorgetrokken kan worden naar Nederland.

Dat was alleszins één van mijn eerste opmerkingen toen we elkaar ontmoet hebben in Brussel ergens eind augustus… Dus, ja, ik denk het wel dat dat de bedoeling is. Het is natuurlijk niet echt eenvoudig, als ze dan zelf een tile server moeten opzetten, maar misschien kan er wel gebruik gemaakt worden van de tile server van openfietskaart.nl. Dat is een discussie die nog niet gevoerd werd.

Ik denk alleszins dat het er wat vreemd zou gaan uitzien, als ze de data van OSM voor de overlay zouden gaan uitzetten op Googlemaps. Want meer dan de helft van de wegen (fietspaden) zijn helemaal niet aanwezig op GM.

Daar wordt dus zeker over nagedacht.

mvg,

Jo

Maar die fietsroutes lopen toch over de fietspaden? Juist daarom is het beter dat ze OSM als overlay gebruiken ipv Google. GM is minder geschikt, hoewel daar ook steeds meer en meer fietspaden en routes op verschijnen (sommige wegen hebben al de naam van LF-routes, wat te maken kan hebben met de fietsrouteplanner die Google tzt zal gaan invoeren). Op de site van http://ridewithgps.com kan je de google fietsplanner al in werking zien, evenals een overlay van OSM met werkende routeplanner (gebruikt de cloudmade engine).

@ligfietser: Ook een leuk discussie, maar sta me toe als OP om de vraag weer te richten op hoe we de mapping voor elkaar krijgen in OSM? :slight_smile:
@Polyglot: Ook welkom op de nl-forum, Jo. Voor alle duidelijkheid, ook ik heb waardering voor je werk. Het gaat me om de consequenties voor de lokale mapper bij het in kaart brengen en onderhouden van die dingen.

Het zou mij (en misschien anderen) enorm helpen als je hier zouden willen uitleggen hoe de tentakeloplossing werkt aan de hand van een praktijkgeval. Als we dit willen gaan implementeren, is enige onderricht zeker nodig!

Edit: Ondertussen is er aardig wat gewerkt aan de kruising in Bemmel bij knooppunt 26 De Heister. URL’s hieronder leiden nu nog naar de huidige (dus aangepaste) situaties, wat verwarrend kan werken. Caveat Lector).

Casus
Bemmel, gem Lingewaard: Van Elkweg (N839) X Papenstraat/Baalsestraat
Fietsknooppuntnetwerk rcn_ref=26

Relaties
Er komen vier routerelaties uit bij knooppunt 26 De Heister. Hier zijn ze na de “tentakelaanpassingen” op de kaart (voorheen werden ze alle vier naar één knooppunt geleid).

106974 (26-30)
106973 (26-98)
1686570 (26-27)
957169 (25-26)

Nodes
Er is een rcn_ref=26 op de kruising van de fietspaden bij het infopaneel (apart opgenomen).

Je voegt twee “split nodes” toe: hier bij de kruising zelf en hier een heel stuk verder weg. Edit; extra knooppunt 26 tag ondertussen verplaatst door Polyglot naar kruising.

Uitgangspunt
Voor toeristische fietsers worden de knooppuntennetwerken tegenwoordig hier vaak uitgevoerd met informatie bij een knooppunt zelf (informatiepaneel op het knooppunt, net om de hoek, of eventueel verder weg en aangeven met een verwijsboord waar het paneel te vinden is).

Ik ga ervan uit dat het handig is als men daar uit komt (maar ik geef toe dat het qua routeren wat last kan geven als je door wilt fietsen).

Vragen over de routeerbaarheid
Het is mij onduidelijk hoe de volgende zaken liggen:

  1. Als een fietser vertrekt vanaf het infopaneel knp 26 (waar er lezenswaardige informatie gegeven wordt over de directe omgeving) richting knp 30 (Papenstraat in), hoe wordt zij/hij geleid? Het lijkt niet in de relatie te zitten.

  2. Als een fietser aankomt vanaf knp 98 (langs de Baalsestraat), eindigt zijn/haar tocht bij node 44284208 (deze ligt ver weg van de knooppunt-kruising en er is geen infopanel te zien). Hoe wordt zij/hij verder gebracht naar --op zijn minste-- de kruising waar er kans is dat zij/hij het infopanel opmerkt (aan de overzijde van de --brede-- weg)? (Let op, de routeborden zelf geven aan dat zij/hij er nog niet is en moet doorfietsen.)

  3. Een fietser vertrekt van het infopanel Knp 26 richting knp 27. De fietser moet eerst oversteken (de fietspaden aan weerzijds van de N839 zijn enkelrichting vanaf de noordkant van de kruising). Wordt de fietser niet eerst terug geleidt naar node 44284208? Zo niet, hoe werkt dat dan wel? Als men fietst van knp 27 naar knp 26, hoe wordt men geleid naar knp 26 (want het zit in die richting toch niet in de relatie)?

  4. Vanaf knp 25 richting knp 26: Fietser eindigt hier weer bij de Baalsestraat. Hoe komt zij/hij bij knp 26?

Notitie aan zelf: oneway=yes/no net nagekeken ter plekke op alle fietspaden; niet helemaal goed ingebracht in OSM maar dat verandert de principe niet . Aanpassingen breng ik straks in OSM.

Het is duidelijk dat ik illustraties nodig zal hebben om dit op een duidelijke wijze uit te leggen. Dus heb ik Maperitive en Inkscape er nog eens bijgehaald.

En ik zal de wiki dus eens gaan bijwerken.

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

De eerste illustratie is klaar. De rest zou nu wel vlotter moeten gaan. Ik ga de puntjes die je aanhaalde één voor één behandelen, maar ik wil nu eerst even die illustraties afmaken. Dat zou moeten helpen om de zaak te verhelderen.

mvg,

Jo