U-Bahn-Eingänge im PT-Schema

Ja, “wenn”! So oft hab ich Platformen bei U-Bahnen nocht nicht gemappt gesehen. (Wobei ich mit meinem Bsp auch nicht Dtld vor Augen hab.)

Warum?

Weil die Frage “Wie komme ich von hier zum Bahnsteig X” eine stationslokale Angelegenheit ist, die nicht direkt mit der Route zu tun hat. Es wären ja auch nicht zwei Varianten der Route, wenn es zwei Zugangswege gäbe.

Die Wege müssen ja auch sowieso rein. Und diese Wege sind ein echtes Highlight in OSM, weil die Zeitberechnung des Umsteigens eine Schwachstelle der meisten Verkehrsauskunftssysteme ist. Zwischen zwei Bussteigen einer Haltestelle liegen garnicht so selten über hundert Meter und da werden Fahrgäste sauer.

Weide

Ja, aber das ist doch ganz typisch für das neue Schema, dass p_t=platform eben auch in die Route kommt, obwohl “stationslokal”!

Wenn man die Platform in der Relation hat, wo der Zug hält, kann der Router selbst den richtigen Eingang finden. Ich fürchte das Warten von Routen wird sonst der Horror.

+1

In meinen Augen ist ein U-Bahn-Eingang nix anderes als eine Treppe/Weg zu einem bestimmten Ziel. So wie ein Fußweg zu einer Bushaltestelle führt. Des wegen gehören diese aber noch lange nicht in die Relation des Transportmittels. Schließlich kommt die U-Bahn mir nicht auf der Treppe entgegen oder anders gesagt: von der Treppe ins Verkehrsmittel geht nicht, den dafür gibt es dann noch den Bahnsteig. Und wenn ich ein Routing berechne, wird die Treppe als Weg eh berücksichtigt, da sie der einzige Weg zur U-Bahn ist. Um auf den Eingangspost zurück zu kommen, wenn ich an dieser Stadtion umsteigen will, muss ich die Treppe rauf auf die Straße.
Wenn nun aber die Treppe schon in der Relation der Route enthalten wäre, dann würde ich die Wegstrecke (Treppe des U-Bahn-Eingangs) nicht mehr berücksichtigen, den da fährt mich die Route/U-Bahn ja schon hin (Ergebnis: falsche Berechnung.)…

Hallo Weide, Geogast

Wenn railway=subway_entrance im P_T Schema überhaupt irgendwo hin gehört, wäre das als lokale Zugangsmöglichkeit in der stop_area-Relation.
Ich weiß auch dort ist es nicht beschrieben. Die Rolle wäre sinncoll access oder entrance.

Normalerweise ist das nicht notwendig, da es ja einen Weg vom U-Bahn Eingang zur Plattform geben sollte. Aber selbst wenn der Weg oder die Plattform fehlt, sollte eine Anwendung einen Zusammenhang zwischen einer Haltestelle (mindestens durch die Stop-Position markiert) und einem naheliegendem railway=subway_entrance herstellen können.

Edbert (EvanE)

Für den Passagier ist das aber ein möglicher Anfangs- oder Endpunkt der Zugfahrt. Es ist ja die Besonderheit der Zugfahrt, dass sie anders als bei einer Wanderroute nicht an jeder beliebigen Stelle beginnen oder enden kann. Diese zulässigen Punkte gehören daher zur Route. Beim Aussteigen endet dort das “Zug”-Routing und es beginnt das Fußgängerrouting.

Weide

Ich gebe euch allen Recht - in dem Fall, dass die U-Bahn-Platform gemappt ist und per Treppe, Fußgängertunnel o.ä. mit dem Straßenebene (z.B. subway_entrance) verbunden ist. Darüber brauchen wir gar nicht mehr zu diskutieren. Alles richtig.
Ich habe nur den Eindruck, dass der Anteil der U-Bahn-Stationen mit gemappter Platform bei wenigen Prozent liegt. Vielleicht täusche ich mich. Schwer, darüber Statistiken zu erstellen. Aber mir ist nie aufgefallen, dass es das so viel gäbe. Ich hab eben in Berlin und München gestöbert und da nur eine Handvoll von solchen komplett gemappten U-Bahn-Stationen gefunden.
Was ist mit all den anderen Stationen - der großen Mehrzahl?
Nun kann man sagen: “Was nicht gemappt ist, kann ja noch werden.” Aber auch da bin ich skeptisch.
Bei den meisten U-Bahn-Stationen, die ich gemappt habe, habe ich auf der Straße die Eingänge gesehen, ihre Position erfasst und den Namen der Station notiert. Wie soll man - einigermaßen flott - die Position der unterirdischen Bahnsteige erfassen? Sicherlich erfassen viele andere User auch nicht mehr als ich.
Und wenn man lediglich die stop_position und die Eingänge hat, dann funktioniert all das, was ihr über Fußgängerrouting und so geschrieben habt, IMHO nicht mehr. Und dann wäre es eben gut, wenn mich das Routing wenigstens zum passenden U-Bahn-Eingang führt und ich dann von dort weiterschaue.

Man könnte sagen, dass auch Fußgänger irgendwann mal das Hirn einschalten müssen. Auch beim PKW-Routing muss man oft die letzten zig-Meter den Rest des Weges von der Parkposition zum eigentlichen Ziel selber finden. Wenn man also einen Eingang zur U-Bahn gefunden hat ist man doch schon ziemlich nah dran.

Rein in der Theorie gehören die Eingänge der U-Bahn zur Infrastruktur und nicht zu irgendwelchen Zug-Linien. Daher wird es auch als railway=subway_entrance getaggt.

Edbert (EvanE)

Edbert,

  1. habe nicht ich mit dem Thema Fußgängerrouting angefangen, ich habe nur drauf reagiert.
  2. habe ich doch selbst gesagt, dass die letzten Meter zwischen Eingang und Platform dann eben nicht geroutet werden können und müssen. Dass das Routing in dem Fall meines Eingangspostings aber den richtigen Eingang finden können sollte, finde ich nicht so abwegig. Sooo nah liegen die Eingänge oft nicht beieinander, z.T. mit Straße dazwischen.
  3. gehören z.B. die Wartehäuschen einer Bushalte auch zur Infrastruktur und nicht zu irgendwelchen Buslinien. Und trotzdem kommen die Wartehäuschen (p_t=platform + bus=yes) in die Routenrelation rein.

Auf jeden Fall. Ich habe da auch gar keine Bedenken, vom U-Bahn-Eingang zum Bahnsteig eine gerade Linie als Fußweg zu ziehen (mit FIXME=geometry und möglichst auch wheelchair=*).

Weide

Die Plattformen sind die Stellen, an die man in eine konkrete Bus/Tram/Bahn-Linie einsteigen kann. Und nicht jede Linie hält an allen Haltestellen. Von daher gehören Plattformen meines Erachtens schon in die Linien-Relationen.

Edbert (EvanE)

Und Wartehäuschen sind natürlich shelter=yes (und in JOSMs shelter-Preset “Öffentlicher Nahverkehr”, was sowas wie shelter_type=public_transport ergibt).

mfg~ray

Hi,

Ich habe nochmal drüber nachgedacht und Du hast mich überzeugt.
Deine Idee sollte man in ein eventuell entstehendes “Public Traffic Next Generation” einbauen, wenn dort das Problem der Mehrfachangaben zu einem Halt versus mehrere Halte eines Namens gelöst wird.

MfG
Weide

:slight_smile:

Das sagt mir gar nichts. Wird daran schon gearbeitet?

Ich bin andersrum drauf gestoßen, dass die Linienrelation (in die ich die Eingägne ja reinhaben will), schon extrem umfangreich würde. Bei Buslinien ist es ja so, dass pro Haltestelle 1 stop_position und 1 platform reinkommt. Bei meinem Vorschlag wären es ja pro Haltestelle oft 4 Eingänge, z.T. sogar mehr.
Andererseits fällt mir keine Alternative zu dem unter #1 beschriebenen Fall ein. Dass das aber gar nicht sooo selten ist, kann man hier lesen.

Ich hatte es schon einmal erwähnt, aber es ist wahrscheinlich untergegangen.
Wenn überhaupt, dann gehören die Eingänge in eine stop_area Relation. Die setzt eine Gesamt-Haltestelle aus ihren Bestandteilen zusammen, also stop_position und platform. Dort können auch weitere Einrichtungen die zur Gesamthaltestelle gehören, aber nicht direkt einer Plattform zugeordnet sind wie Toiletten, Cafe/Imbiss/Kiosk ergänzt werden. Ich sehe da keinen Hinderungsgrund auch die Eingänge für eine unterirdische Station mit zu erfassen. Ob man den Eingängen eine eigene Rolle wie z.B. entrance oder access spendiert sei erst mal offen gelassen.

In http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Stop_area steht:
A public_transport=stop area is the logical combination of
stop position(s), platform(s), amenity=shelter, amenity=bench
and possibly also toilets, cafes and other elements that make up
a logical entity within a relation.

Eingänge zu den unterirdischen Bestandteilen einer Haltestelle gehören nach meiner Meinung zu dieser Definition, auch wenn sie dort nicht direkt aufgeführt sind.

Inwieweit das eine Routing-Software dann nutzt, ist einerseits eine Frage der Zielsetzung der jeweiligen Software und andererseits eine Frage der Verfügbarkeit der Informationen zu solchen Eingängen. Man kann also nur hingehen und die Informationen zu Haltestellen-Eingängen in die stop_area-Relationen eintragen und wenn das häufig genug der Fall ist, die Entwickler von Routing-Programmen bitten, dies in ihr Fußgänger-Routing mit aufzunehmen. (Ohne vorhanden Daten wird das wohl keiner auf Verdacht machen.)

Von all dem unbenommen ist natürlich die Möglichkeit, die Plattformen einer unterirdischen Haltestelle und die dorthin führenden Wege gezielt zu erfassen. Dann kann jede Routing-Software für Fußgänger dich an die richtige Stelle lotsen. Von daher ist diese Variante natürlich vorzuziehen.

Edbert (EvanE)

Ich arbeite dran :slight_smile:

Bei dem genannten Problem geht es um den Aufbau einer Liste der Halte aus den Daten. Oder kürzer: “Wann muss ich denn gezz aufn Knopp drücken?” Solche Listen sind vielleicht das wichtigste auf einem Smartphone anzeigbare für den sich nicht in der Gegend auskennenden Fahrgast.

Gewöhnlich kann man diese Liste aus den Daten aufbauen, aber es gibt garnicht so wenige Fälle, in denen es nicht funktioniert: Die Abfolge “stop, platform, platform” mit drei gleichen Namen kann z.B. bedeuten, dass es zwei Bahnsteige an dem Halt gibt. Das kommt z.B. in Düsseldorf am Stadion vor. Da werden auf der Hinfahrt die Bahnsteige auf beiden Seiten der U-Bahn benutzt, weil man die Leute zum Spielbeginn sonst nicht schnell genug durchschleusen kann. Es gibt aber auch erstaunlich viele Doppelhalte von Buslinien (besonders beim Linksabbiegen), bei denen es zwei Halte sind, obwohl die Abfolge genauso aussieht. Da ist dann nur beim zweiten der stop nicht erfasst. Hier müsste die Information zur Unterscheidung der Fälle in die Relation, da man es nicht zuverlässig aus den Namen schließen kann. Zuverlässigkeit und eine Angabe zur Vollständigkeit ist hier ganz wichtig, sonst wird sich niemand darauf verlassen wollen. Dann gibt es auch noch die Fälle, bei denen die PT-Reise mitten in einer Fußgängerfläche endet und somit keine Verbindung besteht (häufig bei Fähren).

Zum eigentlichen Thema: In einer idealen OSM-Welt würde ich die Aufgänge immer noch nicht in die Route nehmen und einfach eine unrealistischen Hilfsweg einzeichnen. Aber im Fall von Konflikten (z.B. bei strittigen Multipolygonkonstruktionen als Bahnsteig) sollte die Routbarkeit Vorrang vor allem anderen haben und wenn die Sache dann wochenlang rumliegt, weil man keinen Edit-War anfangen will, dann sollte das Routing trotzdem gehen. Das man dabei eventuell mehrere Nodes angeben muss, ist kein Problem, wenn die Relationen die Zugehörigkeit zu Halten explizit ausdrücken können.

MfG
Weide

Tja, das mit diesen symbolischen Hilfswegen… die im großen Stil eintragen, ich weiß nicht.
Aber das Stichwort mit der idealen OSM-Welt ist wichtig: Wenn U-Bahnsteige und die Wege zwischen ihnen und den Eingängen erfasst sind, dann erledigt sich mein Problem von alleine. Aber ich sehe hjalt nicht, dass das in näherer Zukunft oft gemappt wird.

Ist nicht untergegangen, ich vertrete nur deine Meinung nicht.
Genauer gesagt: dass die in die stop_area rein können, ist ja gar nicht strittig. Schrieb ich in der Eröffnung, dass ich das z.T. so mache.
Wie würdest du denn die Realität, von der ich oben schrieb (ein bestimmter U-Bahn-Eingang lässt mich nur in eine Richtung fahren), in OSM erfassen (abgesehen von einem description-Tag)?? Das ist mir in all deinen Posts nicht klar geworden.

Ok, das ist in dieser Klarheit bei mir nicht angekommen.
Damit hat sich dieser Teil also erledigt.

Das liegt daran, dass ich auf diesen speziellen Aspekt bisher nicht eingegangen bin. Ich kenne aus Bonn und Köln aber auch keine solche Situation. Auch in London oder Paris kenne ich das nicht, dort sind zum Teil mehrere Stationen über unterirdische Verbindungen von einem Eingang aus erreichbar. Meist/oft dienen die U-Bahn Zugänge ja zugleich als Straßenunterführungen für Fußgänger.

Obiges heißt natürlich nicht, dass es die von dir beschriebene Situation nicht irgendwo doch gibt. Ein Beispiel dafür wäre jedoch recht schön.

Für dein Problem (über einen Eingang ist nur eine Fahrt-Richtung erreichbar) gibt es zwei mögliche Lösungen:

  • Eigentlich trivial: Die Verbindung eintragen.
  • Die stop_area Relation in mehrere Relationen aufteilen,
    so daß der entsprechende Eingang nur einer bestimmten
    Plattform und damit Fahrtrichtung zugeordnet ist.

HTH
Edbert (EvanE)

Gestoßen bin ich darauf bei der U-Bahn in Buenos Aires.
Wenn bei dicht unter der Straßenoberflächen gebauten U-Bahnen (“Unterpflasterbahn”) keine Mittel-, sondern Seitenbahnsteige gebaut werden, dann gibt es ja nicht genug Platz für ein Zwischengeschoss zwischen Straße und Bahnsteig. Und dann ist es eben so, wie oben beschrieben: Ein Eingang führt nur zu einem Seitenbahnsteig, d.h. nur zu einer Fahrtrichtung.

Was meinst du damit?

Die stop_area aufteilen? Das kommt mir so nach einem Umweg vor. Es sollen doch zum Beispiel die platforms extra in die Routen-Relation aufgenommen werden, damit ein Routingprogramm nicht auch noch auf die stop_areas zurückgreifen muss.

Wenn ich das richtig verstehe, soll Routing nur mit der Route-Relation möglich sein, also auch ohne stop_area. Wenn man das für meinen o.g. Fall anders macchen würde, wäre das ein Sonderweg.
(Dass ich platform und U-Bahneingang hier vergleiche, gilt nur für die Fälle, dass keine U-Bahn-platforms gemappt sind. Da wäre das dann ganz anders möglich, wie gesagt.)