[Talk-de] *:lanes und Straßenbahnschienen

[Garry]

Am 16.03.2013 18:01, schrieb Martin Koppenhoefer:
> Am 16. März 2013 11:02 schrieb Norbert Wenzel <norbert.wenzel.lists at gmail.com>:
>> Ich dachte dabei mehr daran, dass jemand die Ways räumlich trennt und zwei
>> Schienen zeichnet (für jede Fahrtrichtung eine) und diese Schienen dann mit
>> dem Luftbild so verortet, dass sie lagegenau sind, während die Straße als
>> ein Way für beide Richtungen in der Mitte der Schienen geschätzt wird.
>> Tatsächlich aber liegen die Schienen eben in der einen Straße und werden von
>> allen Fahrzeugen gleich benutzt.
>>
>> Das ist kein althergebrachtes Railwaymapping und diese Mischung aus
>> lagegenauen Einzelways für Spezialisten (bzw. den Detailbereich
>> Schienenfahrzeuge) und geschätzten Sammelways macht die Daten, ohne die
>> zusätzliche Information des Luftbildes, unbrauchbar. Das war der Punkt der
>> mich stört.
>
> Es ist halt immer nur ein Kompromiss, egal wie rum man es macht. Wenn
> Du mehrere Schienenstränge und eine Straße zu einem Verkehrsweg
> verquickst, und der dann auf einen way in OSM reduziert wird, dann
> hast Du zwar bei manchen Anwendungen leichteres Spiel, aber dafür
> gehen andere Dinge praktisch gar nicht mehr, oder nur sehr abstrakt,
> z.B. Gegenstände, Hindernisse etc., die sich zwischen den beiden
> Schienensträngen oder sonst auf der Straße befinden (Poller, Geländer,
> Jersey-barrier etc., die nur punktuell vorhanden sind). Oder macht man
> deren Nodes dann auch Teil des einen ways?
>
> M.E. ist es in komplizierten Fällen besser (insb. einfacher zu
> verstehen, zu mappen und zu überprüfen), einzelne Ways zu haben (d.h.
> einen für die Straße, je einen pro Schienenstrang), und diese dann
> ggf. per Fläche (so man Lust hat, alternativ auch per Relation, aber
> die Fläche ist meist auch abgesehen von der "Verkehrsweg-Betrachtung"
> ein Informationsgewinn) zusammenzufassen. Auch selbst wenn die
> Zusammenfassung (noch) fehlt (d.h weder Fläche noch Relation)
> "funktioniert" im Prinzip noch fast alles (falls man Angaben wie width
> oder lanes für den highway hat könnte man sogar noch einigermaßen gut
> abschätzen, ob die Schienen auf der Straße liegen oder daneben). Die
> einzige Frage, wofür man in einem solchen Fall "rechenintensives"
> Präprozessing machen müsste, ist, ob auf der Straße auch noch Schienen
> liegen (IMHO eher eine nicht so besonders häufige Anwendung).
>
> "unbrauchbar" finde ich eine maßlos übertriebene Einschätzung ;-)
>
Sehe ich auch so - geografische lagegenau Informationen sind für Mapper 
und Endnutzer einfacher und  praxisnäher als verschiedene Verkehrswege
abstrakt in einem Way zusammenzufassen und daraus eine eingeschränkte 
grafische Darstellung zu erstellen.

Die "Straßenbahnstraße"- und damit die über größere Abschnitte 
einheitlichen Tags - gibt es nicht. Wo möglich/finazierbar gibt man den 
Schienen einen eigenen Gleiskörper,
Mindestradien etc. setzen physikalische Grenzen wie gut Schienen einem 
Fahrbahnverlauf folgen können.
Haltestellen ergeben wieder andere Anforderungen. Teilweise setzt man 
diese gerne an den Fahrbahnrand um den
KFZ-Verkehr zur Straßenmitte hin vorbeiführen zu können, teilweise wird 
der KFZ-Verkehr auch mitten durch die Haltestelle
hindurchgeführt und im Falle einer haltenden Bahn per Ampel angehalten.
Beim heutigen Stand von OSM ist es so unabdingbar die exakte Position 
der Schienen als separate Ways festzuhalten.
Fahrbahn und Schienen haben keinerlei Zwangsverknüpfung. 
Schienenfahrzeuge können die Fahrbahn nicht nutzen und KFZ nicht die
Schienen. Sie laufen nur zufällig Abschnittsweise Deckungsgleich weil es 
die Platzverhältnisse (teilweise auch Kosten) nicht anderst zulassen
oder getrennt weil es z.B. fördergeldabhängige Zwangstrennungen der 
Verkehrswege gibt.
Wo ist das Problem jeweils Zusatztags zu verwenden dass der jeweilige 
Verkehrsweg Abschnittsweise durch andere Verkehrsmittel
beeinträchtigt wird? Gründe per Router Straßen zu vermeiden/zu 
bevorzugen die Schienen "mit sich führen" gibt es ohne weitere 
Differenzierung
in der Praxis ehr keine.

Garry