[Talk-at] Stra?enbahnen in Linz (war: Spurmapping Stra?enbahn: Heute mal Wien)

[Flaimo]

> Message: 2
> Date: Mon, 23 Jan 2012 22:53:38 +0100
> From: Holger Sch?ner <numenor at ancalime.de>
>
> Doch, mir ist zumindest ein Fall bei mir in der N?he, n?mlich die Kaarstra?e
> in Urfahr, bekannt (http://osm.org/go/0JhNO8VTp--). Die hatte ich vor ein
> paar Monaten (Stra?enbahn-)zweispurig gemappt; die Stra?e habe ich dann,
> trotz (weitgehend) fehlender Trennung in zwei Ways, f?r jede Richtung einen,
> zerlegt. "flaimo" hat die Stra?e wohl letztens wieder zu einem Way
> zusammengefasst.

> @flaimo: Was sprach denn gegen die Zweiteilung der Kaarstra?e? In deinem
> Changeset-Kommentar sprichst du von "unn?tige aufplittung Kaarstra?e wieder
> auf einen highway zusammengef?hrt (richtungen sind nicht physisch
> getrennt)". Zum einen ist diese in einem Teilst?ck an einer
> Stra?enbahnhaltestelle zumindest durch einen Bordstein physisch getrennt,
> zum anderen lassen sich durch die Richtungsfahrbahntrennung, finde ich, die
> tats?chlichen Verh?ltnisse ganz gut abbilden. So lange man darauf achtet
> (was ich dachte getan zu haben), dass die Abbiegerelationen richtig gesetzt
> sind, ist das Routing auch nicht problematisch, und f?r die Fu?g?nger (f?r
> deren Routing) waren glaube ich auch die relevanten Fu?g?nger-?berwege
> eingetragen, oder? Und auch (nicht nur ;-) ) das Rendering hat nach meinem
> Empfinden gut gepasst.
>

wenn wirklich in der mitte der straße eine bordsteinkante ist (was auf
den linzer orthofotos nicht erkennbar ist), wäre es theoretisch
richtig, wobei glaube ich, die richtlinie gilt, dass selbst bei kurzen
blockierungen von der größe einer verkehrsinsel eigentlich noch keine
trennung stattfinden sollte und man im falle eines falles drüberfahren
könnte (zB bei umleitungen). ich vermute mal, dass hier bei jeder
hausausfahrt und einmündenden straße diese blockade zusätzlich auch
unterbrochen wird. wenn in der mitte gras wäre, wäre der fall klar.
ich persönlich habe das eher als eine asphaltfläche eingestuft und
demnach zusammengelegt (und in dem zuge die routenrelationen
korrigiert, die durch die aufsplittung kaputt waren).

weiters schaut es so aus als ob die schienen nicht genau in der mitte
der asphaltfläche liegen sondern eine schiene genau in der mitte liegt
und die zweite auf der fahrspur richtung umkehrschleife. auf der
fahrspur richtung brücke ist anscheinend gar keine schiene. somit
würde sich das auch mit nur einer eingezeichneten schienenspur auf dem
highway nicht richtig abbilden lassen. das ganze areal rund um den
hinsenkampplatz ist leider ein echter grenzfall insofern denke ich,
dass die zeit und zukünftige applikationen die anforderungen an das
mapping definieren werden und dementsprechend dann ja umgemappt werden
kann. ev bauen sie ja auch die linie 2 unterirdisch, dann löst sich
das problem an dieser stelle später von selber auf.

die zwei fahrspuren für die bim sind auf jeden fall physisch
voneinander getrennt. die straßenbahn kann nicht mal so schnell auf
die andere spur "rüberhupfen". später, bei der umkehrschleife, geht
eine der schienen genau in der mitte der straße. dort wurde diese auch
auf die gleichen nodes gelegt. die bushaltestellen waren auch noch
falsch, da die stops auf den tram schienen, statt dem highway waren.
ich vertrete weiterhin die meinung, dass – sofern die informationen
gewünscht sind – die zusammengehörigkeit zwischen straße und schiene
(und ev gehsteigen) über eine relation gelöst werden sollte. einen
wirklichen mehrwert dieser information konnte ich bis jetzt aber eh
nicht finden (im gegensatz zu exakten crossings).

die reindlstraße war ein ähnlicher fall. zwei highways und in der
mitte nicht verbunden eine schiene. das hab ich, nach rückspache im
IRC auf eine fahrbahn mit darüberliegender schiene umgeändert (hier
ist wirklich nur eine schiene in der mitte der straße).


> Aber auch im aktuellen Zustand finde ich das noch sinnvoller, als die
> Stra?enbahn immer (oder immer bei Verlauf auf Stra?en) nur einspurig zu
> taggen. Es gibt einfach Details, die sich damit nicht darstellen lassen,
> gerade der Verlauf von Schienen, Fahrbahnen und Fu?g?nger?berwegen an
> Kreuzungen, aber auch an Stra?enbahnhaltestellen. Und das mag (nur als ein
> Beispiel) f?r Karten f?r Sehbehinderte recht wichtig sein.

weitere anwendungsfälle sind offi-karten bzw fahrplanaushänge mit
umgebungsplan. abgesehen davon ist das durchgängige mappen eines stils
mit eigenständigen ways auch einfacher wartbar, weil man nicht auf
abhängigkeiten rücksicht nehmen muss.


> Message: 5
> Date: Tue, 24 Jan 2012 09:45:00 +0100
> From: "Andreas Uller" <a.uller at gmx.at>

> Zusammengefasst meine Meinung: Solange Stra?en nur als 1 Linie dargestellt sind (und das ist dzt. Standard und mangels Alternativkonzept auch gut so), sollten auch Stra?enbahnstrecken, die direkt auf der Fahrbahn fahren, auch nur als 1 Linie (n?mlich als die selbe) dargestellt werden.

weil du von der, meiner meinung nach, fälschlichen premisse ausgehst,
dass der railway key genauso gehandhabt werden muss wie der highway
key obwohl die zielgruppen komplett unterschiedliche anforderungen
haben. die möglichkeit des spurtreuen mappings wird sogar explizit auf
der wikiseite beschrieben: "When modeling multi-track parallel railway
lines in close proximity they can either be modeled as a single way
with tracks=*, or as a number of parallel ways."
(http://wiki.openstreetmap.org/wiki/Railways#Railway_lines)


> Message: 6
> Date: Tue, 24 Jan 2012 09:51:38 +0100
> From: "Stefan Schiffer" <stefan at schiffer.at>
>
> Ich mache aktuell an der JKU mit Wirtschaftsinformatikstudenten ein Projekt
> im Rahmen von Apps4Linz zur Visualisierung der Stra?enbahnen und Busse. Die
> Studenten hatten ziemliche M?he, den eingleisigen Datenbestand der Linz AG
> so aufzubereiten, dass sich die Stra?enbahnen bei den Umkehrschleifen und
> anderen Stellen mit unterschiedlicher F?hrung der Fahrtrichtungen  richtig
> bewegen (siehe http://goo.gl/NEEhc - noch ein Prototyp; Feedback
> willkommen).

schaut super aus! wie verhält sich das system wenn eine diskrepanz
zwischen eingezeichneter strecke und tatsächlicher strecke vorhanden
ist? (weil zB eine neue streckenführung noch nicht nachgezogen wurde)?
die umstellung auf das neue public transport schema ist nämlich schon
über ein jahr her und da werden vermutlich nicht alle daten fehlerfrei
sein, noch dazu wo ich das zu einer zeit gemappt habe wo es weder bing
noch geoimage bilder gegeben hat.


> Message: 8
> Date: Tue, 24 Jan 2012 10:28:57 +0100
> From: Boris Cornet <borisC at osm-at.org>
>
> Das Datenbankmodell von OSM f?hrt nicht baulich getrennte Stra?en -
> egal mit wie viel Spuren - als einen Strang. Es ist nicht logisch,
> dass Schienen, die Teil der Fahrbahn sind, unabh?ngig davon
> eingezeichnet werden sollten. Daher werden Schienen, die Teil der
> Fahrbahn sind, eben als genau das, n?mlich TEIL DER FAHRBAHN
> eingetragen, und die Zahl der Schienenpaare angegeben.

wie man am beispiel der echtzeitanzeige der öffis in linz sieht
besteht für applikationen aber die notwendigkeit von durchgängiger
spurentreue. da macht es keinen sinn dogmatisch an einem theoretischen
konzept festzuhalten, was sich vor zig jahren mal ausgedacht hat.
besser ist es hier ein neues schema anzudenken und zu verwenden
(wiederum stichwort "relationen").  wenn es nur um das visuelle geht,
dann bietet die route_master-relation aus dem öffi-schema genug
informationen um aus zwei linien links und rechts eine linie in der
mitte zu zaubern.
für autofahrer hat die info eigentlich keinen mehrwert ob schienen in
der straße sind oder nicht, höchstens noch für radfahrer, aber da
werten ja routingprogramme noch nicht mal die elementarsten dinge aus,
geschweige denn schienen in einer straße. insofern hat natürlich die
applikation die zuerst rauskommt und ihre anforderungen präsentiert
einen vorteil.