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.
Jo wrote:
Het moet waarschijnlijk nog gecorrigeerd worden, ik had ook niet vanaf
het begin begrepen wat de beste werkwijze was en hier en daar heb ik
ook 1 knooppunt aangemaakt, waar ik er nu wel 2, 3 of 4 zou opsplitsen.
Ik kijk er straks even naar.
Jo
Op 24 november 2011 15:21 schreef Marc Gemis <marc.ge...@gmail.com
<mailto:marc.ge...@gmail.com>> het volgende:
Ik heb nog nooit op de bordjes voor fietsenknooppunten gelet.
Vanwege de discussie hier heb ik eens gekeken hier in de buurt
http://www.openstreetmap.org/?lat=51.073425&lon=4.424868&zoom=18&layers=M
<http://www.openstreetmap.org/?lat=51.073425&lon=4.424868&zoom=18&layers=M>
Knooppunt 51 heeft bordjes aan beide zijde van de Nete. Er zijn 2
knopen met rcn_ref 51. In OSM loopt Route 51->21 steeds over de
brug, terwijl dit niet nodig als je 50->51->21 wil volgen. Ik weet
niet hoe een routebegeleidingssysteem de huidige data zou
interpreteren. Zou dit niet op de een of andere manier moeten
gecorrigeerd/aangepast worden worden ?
Hetzelfde probleem treedt op bij de brug over de Dijle net ten
zuiden van de vorige brug
Gelukkig voor mij zijn er wel afzonderlijke knooppunten voor het
wandelnetwerk daar ;-)
Marc
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
http://lists.openstreetmap.org/listinfo/talk-be
------------------------------------------------------------------------
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
