Doppelte S-Bahn Linie S21 in Hamburg - mein Fehler?

Communities Deutschland (Germany)
1

Moin zusammen,
ich bin gerade darauf gestoßen, dass es zwei S21 Linien (S-Bahn) in Hamburg gibt.

http://www.openstreetmap.org/browse/relation/2089730
http://www.openstreetmap.org/browse/relation/2064636

Mir ist einfach nicht klar, warum dies so ist und wo mein Gedankenfehler liegt. Für mich unterscheiden sich diese Relationen einfach nicht.
Kann mir hier jemand einen Tipp geben?

VG
Fritz

2

Von den Tags her sind sie identisch, sollten also auch dieselben Objekte enthalten. Die Relation, die weniger Objekte enthält, führt allerdings über das falsche Gleis und die Reihenfolge der Ways in der Relation passt auch besser zur Gegenrichtung. Ich würde aus der “kürzeren” Relation eine Relation für die Gegenrichtung machen, also die Tags für from und to vertauschen und das fehlende Streckenstück bis Bergedorf hinzufügen.

/e: Mit “kürzerer” Relation meine ich r2064636, die bisher nur von Bergedorf nach Elbgaustrasse führt.

mfg~ray

3

Hi,

Das kann einem auch nicht klar sein, denn das was da steht ist einfach unklar.

Der Gebrauch von “forward” und “backward” passt zu Routen, die komplett in einer Relation erfasst werden.

Die Unterscheidung von “platform” und “stop” in den Roles und der Gebrauch von “from” und “to” passt dagegen dazu, jede Variante und Richtung als eine Relation mit sortiertem Fahrweg zu erfassen und diese in einer Master-Relation zusammenzufassen. Das ist es aber auch nicht.

Ich würde es für sinnvoll halten, die Routen nach dem zweiten Verfahren, also dem (beschlossenen)
Public Transport Vorschlag anzugeben:
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

D.h. insbesondere:

  • die beiden Routen als Richtungen nehmen wie rayquaza es vorgeschlagen hat
  • die Halte kommen zuerst, danach der Fahrweg
  • alle Halte haben entweder “platform” (Wartegebiet neben dem Fahrweg) oder “stop” (Halteposition auf
    dem Fahrweg) als Role. Man darf beides angeben. Leere Roles kommen dabei
    nicht vor. Das Bahnhofsgebäude (das lustigerweise als unter Spannung stehend
    getaggt ist) gehört nicht in die Route.
  • die Fahrwege werden in der Reihenfolge angegeben, wie sie vom Zug
    durchfahren werden. Daraus ergibt sich dann auch die Durchfahr-Richtung und
    daher fliegen alle “forward” und “backward” raus. Roles gibt es beim Fahrweg also nicht.
  • eine Master-Relation wird angelegt (type=route_master, route_master=train,
    ref=S21, operator=S-Bahn Hamburg GmbH, network=HVV, name=S21), die als
    Mitglieder die beiden Relationen enthält (ohne Role).
  • bei den Einzelrouten wird ebenfalls “train” statt “light_rail” genommen.

Die Halte selbst würde ich dabei in Ruhe lassen und nur die Routen in Ordnung
bringen.

MfG
Weide

4

Hallo Weide

Für mich sieht das nach einer unvollständig auf das aktuelle ÖPNV-Schema umgestellten Route aus.

Normalerweise wird forward/backward in der Tat nicht mehr benötigt. Es gibt jedoch eine Ausnahme, wo das sinnvoll sein kann. Wenn eine Route eine Schleife (z.B. über einen Busbahnhof) enthält, ist ein Wegstück zweimal in der Route enthalten, da ja dieses Wegstück real zweimal durchfahren wird. In dem Fall machen die Rollen forward, backward zur Unterscheidung durchaus Sinn.
Im konkreten Fall der S-Bahn Hamburg sollte diese Situation jedoch nicht auftreten.

route=light_rail wurde verwendet, um S-Bahnen von anderen Zügen unterscheiden zu können. Das war und ist eine sehr unglückliche Wahl, aber ob man das jetzt wirklich noch ändern sollte, darüber würde ich noch einmal nachdenken. Persönlich würde ich es im konkreten Fall eher belassen, wie es ist.

Bei den Haltestellen, sollte man sinnvollerweise die Reihenfolge prüfen. Änderungen sind nur dann notwendig, wenn die Reihenfolge nicht stimmt.

Edbert (EvanE)

5

Hi,

Ja, das sehe ich auch so.

Ja, sie machen schon Sinn – aber sie sind im Public Traffic Schema nicht vorgesehen. Ich habe den Fall auch schon gehabt, benutze es aber trotzdem nicht. Ich habe zuviel Angst, dass die ohnehin schon schlimme Vermischung der Schemata dann noch noch schlimmer wird. “forward” hätte zwar dieselbe Bedeutung wie sonst, aber das Weglassen von “forward” hätte eine andere Bedeutung und da verlangt man einfach zuviel von Otto Normalmapper.

Normalerweise lasse ich es auch so. Es ist zwar im Public Traffic Vorschlag nicht in der Liste, aber die Sache ist strittig. (Ich hatte es vorgeschlagen, weil hier sowieso kein Stein auf dem anderen bleibt.)

Oh ja, das hatte ich in der Aufzählung vergessen.

MfG
Weide

6

Da eigentlich noch keiner auf die Frage “mein Fehler” geantwortet hat. Der Fehler ist schon aus dem März 2012. Da ist wohl bei dem Upload [1] etwas schief gegangen und dann haben sich beide getrennt von einander weiterentwickelt. Mich wundert es, dass bei der Erstellung der Relation (auch März 2012) noch das forward/backward angewendet wurde.

[1] http://www.openstreetmap.org/browse/changeset/11025279

7

Warum wundert dich das? Ich würde es sogar heute noch it forward und backward anlegen. Einfach weil es nicht stört und zum anderen die Auswertung erleichtert. Das ist ja wie bei den Adressen. Dort geben wir auch addr:city und sogar das Land an. Also Informationen die in der Regel durch andere Polygone geregelt sind aber nur schwer auszuwerten sind.

8

Vielleicht übersehe ich da etwas, aber ich verstehe nicht, welchen Vorteil es hat, den Wegen die Rolle “forward” bzw. “backward” zu geben (war ja dazu gedacht, wenn der Weg nur in eine Linien-Richtung befahren wurde). Der (damals) aktuelle Konsens war ja, eine eigene Relation für jede Richtung zu machen.

9

Auf der Wiki-Seite zu “meinem” Verkehrsverbund lese ich dazu:

Einen Kommentar dazu spare ich mir.

10

Hi,

Nein. Es ist nicht die “Linien-Richtung” sondern die Way-Richtung.

Kreisverkehre und Einbahnstraßen, in denen der Bus nicht geisterfährt sind z.B. immer “forward”. (Außer beim Einsatz von oneway=-1, dann ist es umgekehrt) Mit Hin- und Rückweg hat das garnichts zu tun. (Bei “forward_stop” und “backward_stop” ist es verwirrenderweise anders.)

Es steckt also tatsächlich Information drin.

Weide

11

Diese Information kann genau wie die Adressinformation auch aus der Reihenfolge der Ways hergestellt werden. Das setzt aber vorraus, dass die Ways richtig gereiht sind und doppelte Wege doppelt drin sind und für die Routen Richtungsweise erfasst worden. Sprich hin und Rückrichtung etc. in je einer eigenen Route.