[OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen

[Jo]

Op 24-11-11 heeft Gerard Vanderveken<Ghia at ghia.eu> het volgende geschreven:
> Ik vind het hele gedoe met die tentakels een zeer hoog absurdistan
> gehalte hebben.
> Een route is simpelweg een aaneenschakeling van wegen tussen 2 punten:
> beginpunt A en eindpunt B.
> Een speciaal geval is wanneer A en B hetzelfde punt zijn, dan heb je een
> omloop.
> Dat het trajekt van A naar B verschillend kan zijn van het trajekt van B
> naar A is al genoeg komplikatie, maar daar zijn de forward en backward
> rollen voor.
>
> Maar wanneer je in 1 route 3 begin- en 3 eindpunten begint te mappen en
> bovendien bestaan er soms ook nog eens verschillende paden voor de heen-
> en terugweg, dan ben je volgens mij toch niet goed bezig.  Eigenlijk
> prop je dan een tiental routes in 1 relatie.
>
> Met zo'n relatie kan je echt niks aanvangen.  Daar kan je geen GPX of
> routing mee samenstellen zonder alle deelnemende straten te gaan
> analyseren en op die set een eigen routing te gaan toepassen om te zien
> welke wegen moeten behouden of uitgesloten worden.
>
> Dan getuigt de aanpak op fietsnet.be toch wel van een meer
> realistischer  en pragmatischer kijk op de dingen, die dan ook praktisch
> en makkelijk bruikbaar is.
> - Apart houden waar het moet, zie het hier onder  aangehaalde voorbeeld:
> http://www.openstreetmap.org/?lat=51.069&lon=4.42439&zoom=15&layers=C&relation=9754
> Op fietsnet zijn er 2 losse routes tussen de 3 in lijn liggende knopen
> met nr 52 en ook 1 tussen de 2 knooppunten 51.
> - Samenvoegen waar het kan: vb knooppunt 90 wat lager op de Zenne.
> http://www.openstreetmap.org/?lat=51.03433&lon=4.42266&zoom=16&layers=C&relation=9754
> Bij fietsnet is er maar 1 knoop en die ligt gewoon midden op de brug.
> (Hier onbreekt blijkbaar in OSM wel nog de verbinding tussen de 2 knopen
> nr 90 over de daar aanwezige voetgangers- (+fietsers-?)brug.)
>
> Wanneer twee of drie knoopunten zeer kort bij mekaar liggen, kies gewoon
> ergens 1 punt en maak dat het knooppunt.
> Bvb op het middenbeen van een T of een arbitraire arm op een rondpunt.
> Zoals hier
> http://www.openstreetmap.org/?lat=51.15636&lon=4.2292&zoom=17&layers=C&relation=9754
> Leid daarna alle routes van de nabuurpunten naar dat punt. Want eigelijk
> is er ook maar een knooppunt.
> Dat de resulterende aaneengeschakelde routes hierdoor een kleine krul
> kunnen bevatten vind ik dan nog niet eens zo erg. Die omweg is de prijs
> die de mensen betalen, die blindelings hun GPS volgen zonder zelf maar
> een poging te doen van op de bordjes te letten.
> Alternatief is dat je voor mikro-mapping gaat en alle 'losse'
> knooppunten met hetzelfde nummer gaat mappen, maar dan dien je ook voor
> deze kort bij elkaar liggende punten de aparte routetjes te worden
> voorzien. In het  voorbeeld van knoop 98 worden dat dan 3 aparte
> routetjes (er zijn blijkbaar geen eenrichtingsbaantjes of verplichte
> rijrichtingen bij) elk op hun zijde van de driehoek.
>
> Ik weet dat ik nogal skeptisch was tegen de aanpak van Polyglot die het
> eerst op die wijze implementeerde, vooral skeptisch dan op de zin ervan.
> Is zo'n fijn detail niet overdreven of wel nodig?
> Dat gevoel heb ik nog steeds, maar als er dan toch meerdere knopen voor
> 1 nummer gemapt worden, dan is het voor mij de enige goede manier en
> zeker stukken beter dan die tentakels.
> Gewoon een waardeloos systeem!
> Op die manier wordt OSM nooit praktisch bruikbaar om sites a la fietsnet
> op te zetten.
>
> Ook met de definities voor de rollen forward en backward heb ik het
> moeilijk. Die zijn voor mij ook absurd en zorgen enkel voor komplikatie
> zonder echt iets toe te voegen.
> Ik heb ook de indruk dat het dateert uit de tijd dat er nog geen
> volgorde kon worden gegeven (of behouden worden) aan de leden in een
> relatie.
>
> Wat betekent een rol hebben in een relatie?  Het betekent dat je als
> element in een relatie deelneemt, maar niet op dezelfde wijze als een
> ander element.
> Een 'way' in een gebied kan zowel een stuk van de buitenkant of van een
> enclave zijn. Daar geeft de rol outer of inner perfekt weer wat een
> bepaalde way komt doen in de relatie.
> Voor een route die in principe zowel van A naar B als van B naar A kan
> gevolgd worden, is het te volgen pad voor heen en terug meestal gelijk.
> Wanneer er eenrichtingswegen inzitten ontstaat er een verschillend pad
> voor die heen- en terugweg. Er zitten dus drie verschillende wegen in de
> relatie. Wegen die een rol spelen voor beide richtingen, of alleen in de
> heen-, of in de terugrichting worden gebruikt. Logischerwijs krijgt de
> heenrichting van A naar B de rol forward en de terugweg van B naar A
> backward. Een lege rol is niets speciaals en daar wordt de weg in beide
> richtingen gebruikt.  Heel simpel.
> Moet je een route  in een GPX gieten neem je gewoon de leden met een
> lege rol, aangevuld met de leden met of de rol  forward voor de
> heenrichting, of de rol backward voor de andere richting. Ook heel
> simpel uit te sorteren en gemakkelijk.
>
> Maar het door de Wiki voorgestelde systeem heeft gemeend te moeten
> rekening houden met de richting van de onderliggende weg en daar dan een
> rol aan toe te kennen.
>
> If a route should only be followed in one direction for some or all of
> its length, the "role" can indicate this for some or all of the
> constituent ways. "forward" means the route follows this way only in the
> direction of the way and "backward" means the route runs only against
> the direction of the way.
>
> Ik zie daar helmaal het nut niet van in.
> Meestal zijn de wegen die zo'n forward of backward rol moeten krijgen
> eenrichtingsstraten. Wat brengt dit nu bij?
> Een eenrichtingsstraat kan je alleen maar in 1 richting volgen en dat is
> de voorziene toegelaten richting. Dus altijd forward en nooit backward.
> Dus als je overal de rol one_direction zou gebruiken om de wegen uit het
> heen- of terugtrajekt aan te duiden, heb je precies hetzelfde, want nu
> zijn alle eenrichtingswegen met forward getagd. En omdat de weg reeds
> oneway is heeft de rol one_direction ook geen zin. Het voegt helemaal
> niets bij.
> Als een straat alleen maar 1 rol kan spelen in een relatie heeft het
> eigenlijk niet echt zin om daar een rol voor te verzinnen en bij te zetten.
> En als er toch al eens een normale tweerichtingenstraat in het heen- of
> terugpad zit, heeft het eigenlijk ook geen echt belang om specifiek voor
> die straat te gaan aanduiden in welke richting ze mag worden gebruikt.
> Door  te volgen op of vooraf te gaan aan een eenrichtingsstraat wordt ze
> eigenlijk voor de route ook automatisch zelf een eenrichtingstraat. Een
> routeringsanalyse die je toch helemaal moet maken als je uit de leden
> van een relatie met de rollen op deze manier opgesteld, de route van A
> naar B of van B naar A wil puren.
>
> Voor busroutes werd dit probleem omzeild door voor elke busroute een
> aparte route voor beide richting te maken (vb Leuven - Groenendaal en
> Groenendaal - Leuven). Maar om dit nu ook te gaan toepassen voor de
> fietsroutes ....
>
> mvg
> Gerard.

Ik zou die tentakels nooit geïmplementeerd/overgenomen hebben als ik
er de zin niet van inzag. Ik vind het dus wel degelijk een elegante
oplossing voor de fietsknooppuntennetwerken. Al was ik er
waarschijnlijk zelf niet opgekomen om het zo aan te pakken. Met
elegant bedoel ik dat wat Gerard een 'krul' noemt, niet hoeft voor te
komen. Je zou het ook een onnodige zijsprong kunnen noemen.

Roles op ways hebben wel degelijk zin. Neem één van de relaties die
door mijn script als geldig worden beschouwd, waar ways met roles
inzitten. (Zowat alle routes in België), maar zonder dat er tentakels
aan te pas komen of die gevorkt beginnen of eindigen. (Daar kan JOSM
ook niet mee overweg).

Verander nu de volgorde van de members willekeurig en klik dan op de
sorteerknop in de relatie-editor. Je zal zien dat ze correct worden
gesorteerd. Dat geeft voor mij aan, dat we, zeker wat de roles
betreft, op de juiste weg zitten.

Wat de busroutes betreft, die van A naar B gaan en waar dus voor elke
richting een relatie bestaat, vind ik dat je gelijk hebt, daar zijn de
roles overbodig geworden. Ik heb daar ook een script voor geschreven
(nog voor dat monsterscript van de fietsroutes) en daar hoef ik niet
eens naar de roles te kijken. Quod erat demonstrandum.

Voor de fietsroutes is het echter wel degelijk van belang om zowel de
roles correct toe te voegen aan de members, alsook de volgorde correct
in te geven. (Dan kan er in JOSM in de meeste gevallen ook al visueel
gezien worden dat de route 'klopt').

Fietsnet splitst ook knooppunten. Misschien minder dan wij, maar ze
splitsen wel degelijk. Geen idee of ze daarbij rekening houden met de
situatie zoals ze is aangeduid 'in het echt'. Ik betwijfel dat.

Wat ik wel vind, is dat als je eenmaal zegt: knooppunten kunnen
gesplitst worden en we gaan de aanloop en uitloop van een route met
tentakels 'decoreren', dan moet dat overal kunnen worden toegepast.
Eén regel, één wet, anders is er geen consistentie (en wordt het
bijgevolg veel moeilijker om aan kwaliteitscontrole te gaan doen of de
data op de een of andere wijze te gaan gebruiken).

Dus, ondanks dat het wel degelijk allemaal wat complexer geworden is,
dan ik zou wensen (of zelfs dan ik me ooit had kunnen voorstellen),
zijn we wat mij betreft nog steeds op de eenvoudigst mogelijke manier
de werkelijkheid aan het modelleren en meer mogen we eigenlijk niet
verlangen.

Ik ben erin geslaagd (OK, met de nodige hoofdbrekens) om in mijn
script een algoritme uit te werken, waarmee ik kan bepalen waar de
route werkelijk start (ondanks de afwezigheid van een KP met een
rcn_ref op die plaats) en waar de route eigenlijk stopt (Iets
eenvoudiger omdat dat gewoon is, wanneer het eerst een hooggenummerde
KP bereikt wordt). Als het nodig om GPX'en aan te maken die de
tentakels niet bevatten, of die de tentakels als aparte entiteiten
wensen te verwerken, dan is dat vandaag al mogelijk.

Ik denk dat als er iemand een router wil gaan maken aan de hand van de
wijze waarop ik tegenwoordige die fietsknooppuntenroutes 'codeer' in
OSM, dat mijn Pythonscript als een referentie-implementatie kan
gelden. Misschien is het een goed idee om de mensen van Fietsnet.be
eens te laten kijken naar de beschrijving op de wikipagina en naar
mijn script, maar ik vind wel dat we het er eerst zelf over eens
zouden moeten geraken, dat dit een goede manier van werken is.
Eigenlijk kan het ook gelijktijdig. Dat wordt mijn volgende mail.
Ik denk natuurlijk van wel, anders had ik het nooit zo
geïmplementeerd, neem dat van me aan.

Ik had aanvankelijk ook enige weerstand, omdat ik het in eerste
instantie niet begreep (en ook omdat ik niet meteen zag, hoe ik dat
moest gaan coderen in Python), dus ik begrijp dat het ook voor anderen
niet eenvoudig is en wat tijd vraagt.

Nu ga ik wat bushaltes op de kaart zetten...