grüß euch,
ich muss mich auch noch in die dikussion einklinken.
zum argument "parallele fuß/radwege zu straßen sind zu kompliziert zum
routen möchte ich folgendes sagen (nachdem ich mich beruflich mit
routing beschäftige):
diese vielzahl an wegen macht einem modernen router nichts aus. klar
dauert es ein bisschen länger bei mehreren wegen, aber nur marginal. die
lösung zur komplexitätsreduktion beim routen ist in der literatur unter
'contraction hierarchies' bekannt und macht es möglich, dass z.B. die
OSRM in ein paar millisekunden eine route von berlin nach paris
berechnen kann.
// bis hierher bin ich mir sicher,
// darunter beginnt wohl persönliche meinung und spekulation
weil du (norbert) das schöne beispiel alserbachstraße gewählt hast: eben
wegen der hohen komplexität dieser straße (und kreuzungssituation) wäre
es für's routing (von allem außer autos) wünschenswert möglichst viele
der genannten details zu wissen.
es macht z.b. schon einen unterschied ob die schienen direkt befahren
werden oder die staßenbahn getrennt wird, schwellen vorhanden sind oder
nicht (auto überholt radfahrer und kann ausweichen oder nicht), welcher
teil der straße welchen belag hat und wo genau die fuß- und radübergänge
sind.
ich denke die lösung liegt im mittelweg zwischen alles in einen way und
für alles einen eigenen way.
radwege mäandern meist von/zur straße hin/weg, mit bäumen, parkenden
autos oder doch keinem abstand zur straße, da ist es teilweise praktisch
einen eigenen weg zu zeichnen.
ein wichtiges argument für getrennte wege ist möglicherweise, dass die
interessensgebiete der mapper so gebündelt werden, die tagmenge pro way
übersichtlich bleibt und so wenig versehentlich zerstört wird?
auch eine komplexe situation wo es noch eine schöne herausvorderung wäre
fußgängerrouting zu betreiben, das schottentor:
http://radlkarte.at/?zoom=18&lat=48.2139&lon=16.36248&layers=B000
best,
markus
On 2011-09-04 19:53, Norbert Wenzel wrote:
On 09/04/2011 05:44 PM, Flaimo wrote:
wenn jemand der meinung ist, dass getrenntes erfassen noch
schwachstellen hat, dann soll er ein proposal zur verbesserung
schreiben, aber bitte empfehlt dann nicht als gegenargument eine
ungenauere art zu mappen anno 2008.
Ok, nehmen wir mal unser Lieblingsbeispiel hier her, die Alserbachstraße.
Gehwege auf beiden Seiten, Radstreifen auf beiden Seiten, in jeweils
eine Spur und in der Mitte noch zwei betonierte Straßenbahngleise, vom
Verkehr durch Schwellen getrennt, die zwar theoretisch befahrbar,
praktisch aber verboten sind. Jetzt zählen wir mal die Ways.
2x Gehsteig
2x Gehsteigkante (Barrier, is ja schließlich nicht für Rollstuhlfahrer
geeignet)
2x Radstreifen
2x Fahrstreifen
2x Schwelle (Barrier, ist ja schließlich für irgendwen sicher auch ein
Problem)
2x Schiene
Das ergibt 8-12 Ways (je nachdem ob ich die barriers auch einzeichne und
ich mich nicht verzählt hab).
Die Alserbachstraße kreuzt die Lichtensteinstraße. Die hat jeweils zwei
Spuren an der Kreuzung und zwei Gehsteige. Wobei die Gehsteige nicht so
einfach hergenommen werden können, denn schräg läuft auch noch die
Boltzmanngasse hinein.
Gehen wir hier mal an der Kreuzung der Einfachheit halber von 6 Ways für
die Liechtensteinstraße aus und ignorieren die Boltzmanngasse.
Wenn ich das jetzt richtig rechne haben wir für die eine Kreuzung 48
Schnittpunkte. 48 Punkte an denen ein Router testen muss, ob er da
entlang fährt.
Also lassen wir mal die Schwierigkeiten bei Editieren dieser Wege auch
noch weg. Solang du mir keinen Rechner hinstellt, der den Sauhaufen
Rendern kann und dann auch noch sinnvolle Routing Informationen erzeugt,
bleib ich bei 2008.
Btw. der Vorteil eines Plans ist die Abstraktion. Wenn du ein Luftbild
abmalen willst, dann tu das, aber erwart bitte nicht, dass ein Computer
mit den Unmengen an Daten dann auch noch rechnen kann.
So, Ende der Polemik.
Norbert
_______________________________________________
Talk-at mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-at
_______________________________________________
Talk-at mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-at