OpenStreetMap Forum

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

Ich mach es so gut es geht, ohne mit den ganzen Bussen zu fahren... und auch vervollständigen.. reparieren usw. fehlende ergänzen. Mach etliche Fehler/Hinweise.. sollte was nicht stimmen kann man es ja korrigieren... aber der Anfang ist schon gemacht und der macht am meisten Arbeit Ob jetzt der Bus die eine oder eventuell andere Straße nimmt ist eigentlich fast egal... Hauptsache er hällt an der nächsten Haltestelle

---

OSM-Testkarte, DE-Notes Map, DE:Emergency Map, Maypole Map

huby1691

Member

Registered: 2009-08-27

Posts: 10

Re: ÖPNV Bus stop_position

Wenn ich den Fahrweg der Buslinie nicht kenne, würde ich ihn auch nicht taggen.

und es bei einer Masterrelation mit allen Haltestellen (halbwegs geordnet) belassen.

Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?

Ist im Sinne von OSM . Hab da mal gehört... alles was sich vor Ort überprüfen lässt kann man OSM hinzufügen. Da der Fahrplan vor Ort öffentlich aushängt und von jedermann überprüft werden kann.... passt also...

---

OSM-Testkarte, DE-Notes Map, DE:Emergency Map, Maypole Map

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen ... die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de

hsimpson

Member

Registered: 2015-07-21

Posts: 675

Re: ÖPNV Bus stop_position

Was mir fehlt sind die use-cases. Was soll mit den Daten machbar sein, und was nicht? Und dann sollte man noch kurz darüber nachdenken, ob die use-cases auch nützlich sind ... zumindest wenn die Bereitstellung der dazu notwendigen Daten kompliziert ist.

Also ich hätte folgende Use-Cases:

-Erstellung von Netzplänen: Gibt es etwa bei der Rheinbahn

-Generieren von Services wie dem DB-Zugradar, bei denen die exakte Route bekannt sein muss.

-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.

-Abfahrtsmonitore wie Öffi könnten bei korrekten Daten die stop_areas auf einer Interaktiven Karte zeigen, ein Klick auf eine stop_area führt zu einem Abfahrtsmonitor, und wenn man dann auf eine Abfahrt klickt wird mittels der online hinterlegten Echtzeit-Halteposition die position der entsprechenden stop_position auf einer Karte angezeit.

Wie du siehst ist vieles denkbar und dank PTv2 auch machbar, man muss nur die Daten korrekt erfassen. Dass der entsprechende Aufwand sogar wirtschaftlich sein kann zeigen Unternehmen wie Menz, die immer mehr Kunden betreuen.

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Grüße

---

Fragen zu PTv2? Vlt mal in diese Übersicht schauen?

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Ich glaube noch nicht mal das  Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.

Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.

Da liegt die Zukunft. Bisher arbeiten die Verkehrsunternehmen in der Regel mit statischen Umsteigematritzen. Das macht das Routing sehr unfexibel und erlaubt auch nicht, dem Kunden exakte Umsteigewege anzuzeigen. Das Interesse ist groß.

Last edited by Trockennasenaffe (2017-04-28 08:12:13)

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Da liegt die Zukunft.

Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.

Je nach Qualität der einzelnen Nodes in der Nodedatenbank des Verkehrsunternehmens ist die Qualität unterschiedlich. Wir könnten evtl. durch unsere linienförmigen und flächenförmigen Steige bei Bahnen bessere Ergebnisse erzielen, da ein einzelner Node bei einem Bahnsteig mit mehreren Abgängen schlechte Abstände liefert...

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

Da liegt die Zukunft.

Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.

Das ist mir schon klar. Ich meine, dass bisher z.B.  kein Bahnsteig zu Bahnsteig Routing gemacht wird, das geht momentan nur mit statischen Matritzen mit statischen Umsteigezeiten. Würde man auch hier die OSM daten nutzen um  zu ermitteln welche Umsteigebeziegungen möglich sind, wäre das sehr viel flexibler.

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen ... die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de

Ich haben ihn mir durchgelesen und finde ihn recht interessant, verstehe aber glaube ich nicht alles. Ich werde aber mal Feedback geben aber da immer nur einzelne Aspekte herausgreifen, da mir das sonst zu viel auf einmal wird. In diesem Fall PIOs:

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig? Das halte ich für einen recht pragmatischen, nützlichen und intelligenten Ansatz. Hab da noch Fragen:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Was für real existierende Probleme lösen die PIOs noch?

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig?

Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin -- da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen ... aber das geht bei Fußgängern vermutlich nicht.

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.

Was für real existierende Probleme lösen die PIOs noch?

Konflikte mit dem Mapping physischer Objekte. Ich kenne einige gute Mapper, die keinen Nerv mehr haben auch nur eine Bushaltestelle anzulegen.

PIOs sind nie physisch. Es ist immer klar, dass man für einen Bahnsteig railway=platform und für einen physisch vorhandenen Bussteig highway=platform oder highway=pedestrian oder was-weiss-ich nehmen muss. Man kann das nie durch ptv3_object=pio ersetzen. Dadurch kann man auch mehrere PIOs auf einem Bahnsteig haben. In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5. In Duisburg Hbf gäbe es z.B. einen PIO für die relativ zum Bahnsteig sehr kurzen Doppelstockzüge. Damit käme man für das Umsteigen vom Zug in die U-Bahn auf realistische 300m ... vom Bahnsteig zur U-Bahn sind es dagegen nur 30m. (Die Zahlen sind grobe Schätzungen. Die genauen Zuglängen und Haltepositionen hab ich nicht.)

hsimpson

Member

Registered: 2015-07-21

Posts: 675

Re: ÖPNV Bus stop_position

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Ich glaube noch nicht mal das  Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.

Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.

So ein Reviev dürfte zu viel Aufwand bei einer zu hohen Fehlerwarscheinlichkeit darstellen.

Fahrzeugümläufe etc. wären mit OSM problemlos errechenbar, wenn die Infrastruktur komplett erfasst ist. Die derzeitigen Programme, die so etwas berechnen, basieren auf deutlich rudimentärerern Daten, die nur die Entfernungen, Höchstgeschwindigkeiten, Signalpositionen, Haltepositionen und Steigungen beinhalten. Mehr braucht man dafür auch Infrastrukturseitig nicht und bis auf die Steigungsdaten sind unsere Daten in einigen Regionen schon sehr nahe an dem, was tatsächlich gebraucht wird. Dazu kommen natürlich dann noch die Fahrzeugeigenschaften wie der Beschleunigungswert und die Bremshundertstel. Aber das hat ja mit OSM nichts zu tun.

Aus den Daten wird dann erst mal die reine Fahrzeit berechnet und daraus kann man dann die notwendige Wendezeit ableiten. In einem späteren Schritt wird dann meist erst die Schichtplanung erstellt.

Aber ich bin da ganz deiner Meinung, dass wir uns besser auf die Fahrgastinformation fokussieren sollten, zumal die Reiseauskünfte in den wenigsten Fällen direkt vom Betreiber ausgegeben werden. Das ist eigentlich nur noch im eigenwirtschaftlichen Verkehr der Fall. Im Regionalverkehr kommen die Infos meist von den Verbünden, für die es auch ein nicht unerheblicher Aufwand sein kann die notwendigen Informationen zusammen zu tragen und dann alle auf ein Format zu bringen. Da kann OSM schon eine sehr gute Stütze sein.

Nicht umsonst sind die Verbünde mit die ersten kommerziellen Akteure gewesen, die nicht nur für das erstellen eines normalen OSM-Routers sehr tief in die OSM-Materie eingestiegen sind. Die meisten anderen kommerziellen Anwendungen von OSM beschränken sich auf das verwenden vom Mapnik als Hintergrundbild, manchmal werden noch kleinere Sachen gemacht wie die Auslesung der highway=motorway ways, um damit eine Echtzeit-Verkehrskarte zu erstellen, wie etwa beim WDR.

Grüße

---

Fragen zu PTv2? Vlt mal in diese Übersicht schauen?

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig?

Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin -- da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.

Für das Problem "Wie komme ich zum Verkehrsmittel" ist das ausreichend. Das Problem "Wie viel Zeit brauche ich zum Umsteigen?" bzw. "Wann muss ich da sein?" lässt sich damit aber ggf. nicht ohne externes Zusatzwissen lösen oder? Oder müsste dass dann schon in den Reisezeiten und Abfahrts- und Ankunftszeiten mit drin sein?

Ich frage mich auch wie das ist, wenn sich die Wege nach dem Wartebereich noch aufteilen können wie beim Flughafen. Was wäre dann der PIO? Was ist mit Systemen wie der TGV in Frankreich, bei denen es gar keine festen Bahnsteigzuordnungen gibt, sondern diese dynamisch disponiert werden? Aber vielleicht ist das sogar einfacher, das ist mir gerade nicht ganz klar.

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen ... aber das geht bei Fußgängern vermutlich nicht.

Das würde wohl gehen. Ich denke da an Systeme wie die sog. "Spanische Lösung" z.B. rechts einsteigen links aussteigen. Ist bei vielen Metrosystemen weltweit recht verbreitet und sollte daher funktionieren.

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.

OK, da werde ich mir noch gedanken machen. Das ist wohl auch für die linien relevant, da werde ich vielleicht später noch etwas zu sagen.

In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5.

Wären dass dann Nodes, Ways oder Flächen? Die würden dann immer zusätzlich zu vorhandenem physischer Objekten angelegt? Wenn ein PIO "4a" heißt, wie erfolgt dann die Zuordnung zu Mainz Hbf?

Trockennasenaffe

Member

Registered: 2012-02-16

Posts: 401

Re: ÖPNV Bus stop_position

So ein Reviev dürfte zu viel Aufwand bei einer zu hohen Fehlerwarscheinlichkeit darstellen.

Wenn man die Daten ohnehin schon hat ist das natürlich erst mal ein großer Zusatzaufwand. Letztendlich müssen die Daten aber ohnehin einmal richtig erfasst und auf Fehler überprüft werden. Danach nur noch die Änderungen. Beim erfassen macht man sich noch zu nutze, dass die Community da viel kostenlose Vorarbeit geleistet hat. Gibt sogar Feuerwehreinsatzkarten auf OSM Basis: https://www.youtube.com/watch?v=1__IjaP1EY8. Da werden solche Verfahren beschrieben.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Für das Problem "Wie komme ich zum Verkehrsmittel" ist das ausreichend. Das Problem "Wie viel Zeit brauche ich zum Umsteigen?" bzw. "Wann muss ich da sein?" lässt sich damit aber ggf. nicht ohne externes Zusatzwissen lösen oder? Oder müsste dass dann schon in den Reisezeiten und Abfahrts- und Ankunftszeiten mit drin sein?

Ich denke, dass es bei solchen Gatesystemen immer Vorschriften gibt, wann man spätestens vor Abfahrt auftauchen muss. Ist man erstmal durch wird man auch mitgenommen und die Weglänge spielt keine Rolle.

Ich fürchte, dass man diese Vorlaufzeiten nicht mal sicher im Fahrplan findet. Ich meine mich zu erinnern, dass man bei den Fahrten mit der Fähre ab Göteborg je nach Wochentag und Saisonablauf verschiedene Zeiten hatte und erst ein oder zwei Tage vorher per Internet oder Telefon was genaues dazu erfahren hat.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Was ist mit Systemen wie der TGV in Frankreich, bei denen es gar keine festen Bahnsteigzuordnungen gibt, sondern diese dynamisch disponiert werden?

Die verschiedenen möglichen Bahnsteige werden mit der "alt-pio"-Rolle angegeben. Die alternativen Gleise im Bahnhof werden dabei ignoriert.

Das gilt aber nur, wenn es eine lokal auf den Bahnhof beschränkte Variation ist. Wenn die Züge ab Gleis 4 z.B. immer schon in A-Dorf statt in B-Dorf enden, dann ist es eine echte Variante und damit eine eigene Relation.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Das würde wohl gehen. Ich denke da an Systeme wie die sog. "Spanische Lösung" z.B. rechts einsteigen links aussteigen. Ist bei vielen Metrosystemen weltweit recht verbreitet und sollte daher funktionieren.

Ich hab das mal von Japan gehört. Da war auch die Rede von versetzten Türen, so dass die ein- und aussteigenden Massen sich gegenseitig garnicht behindern.

Ich denke auch, dass es rein sollte. Eigentlich müsste es ja "pi" und "po" statt "pio-in" und "pio-out" heißen, aber ich glaube dann flippt die Mehrheit aus :-)

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Wären dass dann Nodes, Ways oder Flächen?

Ja :-)

Ich würde in dem Fall Linien nehmen.

Die würden dann immer zusätzlich zu vorhandenem physischer Objekten angelegt?

Auf jeden Fall ist das ptv3_object=pio an sich nichts physisches. Normalerweise bekommt ein mit anderen Tags beschriebenes physisches Objekt zusätzlich ein ptv3_object=pio. Wo es sinnvoll ist, legt man statt dessen neue Datensätze mit ptv3_object=pio an. Es kann auch mal vorkommen, dass da physisch absolut nichts ist und es trotzdem eine Bushaltestelle ist; dann hat man eben nur einen Datensatz mit ptv3_object=pio.

Wenn ein PIO "4a" heißt, wie erfolgt dann die Zuordnung zu Mainz Hbf?

Das wäre "ptv3_name=Mainz Hbf" und "ptv3_number=4a".

("ptv3_name" darf anders als "name" Abkürzungen enthalten und gibt die Beschriftung der Schilder wörtlich und ohne Steignummern wieder. Dann hat auch der Kollege aus Japan eine Chance, rechtzeitig auszusteigen.)

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen.

Da Pio nicht gerade eine intuitiv verständlich ist, könnten wir statt "pio", "pio-in" und "pio-out" auch einfach die Rollen "inout", "in" und "out" verwenden.

Die spanische Lösung (beidseitige Bahnsteige) gibt es übrigens auch im Münchner S-Bahn-Tunnel.

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Last edited by slhh (2017-04-28 23:29:41)

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

Wir sollten den Spezialfall flughafenartiger Gates von dem Pio Konzept separieren, zumal es auch wenn solche Gates vorhanden sind, oft zusätzlich eine nachgeschalteten fahrzeugnahen Wartepunkt gibt und ggf. auch der Ausstieg ggf. nicht über das Gate erfolgt.

Wir können das Gate entweder statisch per spezieller Relation den fahrwegnahen Pios zuordnen oder es zusätzlich in die Linienrelation aufnehmen. In letzterem Fall sollte es durch z.B. eine "gate"-Rolle und/oder entsprechende Tags am Gate-Objekt von sonstigen Pios unterschieden werden.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

Wenn wir die Gates separiert haben, können wir das Konzept für die Pios auf die fahrwegnahe Verwendung optimieren.

Ich schlage daher vor, als Pio die virtuelle Fläche zwischen Fahrweg und Bahnsteigkante zu definieren. Damit bringen wir den Pio in Kontakt mit dem Fahrweg, was zusätzliche Möglichkeiten für eine möglichst einfache definition des Fahrwegs bietet.

Wir müssen diese Fläche nicht unbedingt als geschlossenen Weg zeichnen. Eine U-förmige Linie, die die mit dem Fahrweg deckungsgleichen Kanten weglässt, wäre auch zur Definition dieser Fläche geeignet. GGf. kann man auch noch den Startpunkt weglassen und erhält eine L-förmige Linie, die nur im Endpunkt Kontakt zum Fahrweg hat. Bei einer Bushaltestelle (Länge vernachlässigbar) kann der Pio zu einer Zweipunktlinie zwischen Platform und Stop-Position entarten. Platform und Stop-Position-Tags an den Nodes können dann ggf. entfallen.

Für den Fall, dass der Pio keinen Kontakt (gemeinsamer Node) zu einer Platform hat, können wir folgendes definieren:
Diejenigen Nodes/Kanten, die den Fahrweg nicht berühren, werden als Platformkante interpretiert.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

Da Pio nicht gerade eine intuitiv verständlich ist, könnten wir statt "pio", "pio-in" und "pio-out" auch einfach die Rollen "inout", "in" und "out" verwenden.

Könnte ich mir vorstellen. Hmm, aber dann ist intuitiv nicht so klar, dass hier Ein- und Aussteigestellen keine Rolle spielen und ausschließlich PIOs als Member in Frage kommen.

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Das verstehe ich nicht. Die Rolle bezieht sich auf Halte einer Tour (Route). Andere Linien haben damit doch nichts zu tun.

... Pios auf die fahrwegnahe Verwendung optimieren ... als Pio die virtuelle Fläche zwischen Fahrweg und Bahnsteigkante zu definieren... dass der Pio keinen Kontakt (gemeinsamer Node) zu einer Platform hat...

Das ist ein ganz anderes Konzept. Ich will die physischen Objekte völlig von den PIOs trennen -- auch wenn sie fast immer mit ihnen zusammenfallen. In den Regeln für das Mappen physisch vorhandener Objekte wie Bahnsteigen soll kein einziges Wort über PTv3 fallen und es soll keine Kompatibilitätseinschränkungen geben. PTv3 setzt darauf nur auf. Die Fährleute sollen die Häfen mappen wie immer sie wollen und die Bahnleute sollen die Bahnanlagen mappen wie immer sie wollen. Wenn da etwas als PIO brauchbares schon gemappt ist, dann kommt ein Tag ptv3_object=pio hinzu und wenn da nichts brauchbares ist, dann wird ein getrenntes Objekt mit ptv3_object=pio angelegt.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

Also ich hatte hier lange nicht mehr mitgelesen und eben auch nur mal überfliegen können. So ganz warm werde ich mit dem PIO-Kram allerdings noch nicht. Ich habe immernoch den Eindruck, dass hier zu viel Komplexität reingebracht wird, die gar nicht nötig ist, von eventuellen zusätzlichen dicht gedrängten Objekten, mit denen man sich im Editor herumschlagen muss, mal abgesehen.

Mir wird immernoch nicht klar, welchen Vorteil ein PIO gegenüber der Kombinaltion aus Stop-Position und Plattform haben soll. Mit letzterem ist doch fast alles gesagt. Es fehlt ggf. nur eine Richtung (rein oder raus oder einfach nur Linien-Fahrtrichtung). Dazu braucht man aber keine zusätzlichen PIOs, das ist alles schon vorhanden.

Ich verstehe auch die vermeintlichen Schwierigkeiten nicht, die Leute an die richtigen Stellen zu schicken. Hatte ich ja vorher schon mal geschrieben. Wenn die Physik sauber eingetragen ist, hat man alles, was man braucht.

Und eins noch: Wir sprechen hier von PTv2 und PTv3. Eigentlich löst eine v3 ja eine v2 ab. Das heißt nicht, dass es nicht auch beide gleichzeitig geben kann, aber es heißt, dass man auch allein mit der v3 alles erledigen kann. Nun habe ich aber irgendwie das Gefühl, dass PTv3 hier manchmal als Aufsatz zu/auf PTv2 gehandelt wird. Wenn das aber so wäre, dann darf man es nicht PTv3 nennen, sondern muss einen komplett anderen Namen verwenden. Sonst versteht man das überhaupt nicht mehr.

Achso, und das mit dem Routing ... ich habe jetzt nicht versucht herauszufinden, wo das herkommt, aber irgendwie halte ich das für unsinnig. Ein Router hat bei Verkehrlinien nichts verloren, weil die Linienführung ausschließlich von den ÖPNV-Unternehmen festgelegt wird und nicht von irgendwelchen Routern. Eine berechnete Route führt also bestenfalls zu Verwirrung, wenn sie nicht zufällig die Realität abbildet. Auch hier sehe ich nicht, wo das Problem mit PTv2 ist: Man fügt alle Wege und Haltestellen in der richtigen Reihenfolge zusammen, und gut ist. Und wenn es 30 Varianten gibt, dann gibt es eben 30 Relationen. Wo ist das Problem? Und wenn sich was ändert, dann ändert man es eben. Oder halt nicht, dann stimmt es eben nicht mehr. Aber dieses Problem lösen auch PIOs oder Router nicht. Spezielle Rufbusse und dergleichen fahren natürlich u.U. nach Navi oderso. Das sind aber Spezialfälle, die eher in Richtung Taxi gehen, und für diese muss man dann auch keine speziellen Visualisierung oder Kalkulationen haben, oder?

Wie gesagt, ich habe den Eindruck, dass hier einige Dinge in eine Richtung laufen, die netto keinen Mehrwert bieten. Dieser Eindruck mag falsch sein, aber es gab ja auch von anderen Seiten schon den Einwand, dass Nutzen und Nutzbarkeit auf einem einfache Level gewahrt werden sollten.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Das verstehe ich nicht. Die Rolle bezieht sich auf Halte einer Tour (Route). Andere Linien haben damit doch nichts zu tun.

Nehmen wir als Beispiel eine Station mit zwei Gleisen und drei Bahnsteigen, so dass es an jedem Gleis beidseitige Bahnsteige gibt. Zu den beiden Außenbahnsteigen führen nur Zugangstreppen und am gemeinsamen Mittelbahnsteig gibt es nur Abgangstrepppen.
Es verkehren zwei Linien von A nach B und C nach D auf dem gleichen Gleis und die Gegenrichtungen auf dem zweiten Gleis.

Zunächst scheinen an den Außenbahnsteigen "in"-Pios und am Mittelbahnsteig "out"-Pios sinnvoll. Dies wird aber problematisch bei Umsteigern:

Fall 1: Jemand will umsteigen, um von A nach C zu fahren. Normal wäre, dass er zum gemeinsamen Mittelbahnsteig hin aussteigt und von dort am gegenüberliegenden Gleis wieder einsteigt. Das bedeutet aber, dass wir am Mittelbahnsteig keinen reinen "out"-Pio plazieren dürfen, sonst führt der Fussgängerrouter die Umsteiger über zwei Treppen zum Außenbahnsteig. Andererseits wäre ein "inout"-Pio auch unerwünscht, da dann ggf. reine Einsteiger zu diesem geführt werden.

Fall 2: Jemand will umsteigen, um von A nach C zu fahren. Dies kann wie Fall 1 gehandhabt werden, nur das am gleichen Gleis wieder eingestiegen wird. Physikalisch möglich ist jedoch auch zum AUssenbahnsteig hin auszusteigen (was der Router bei einem reinen "in"-Pio nicht akzeptieren würde) und von dort in den Zug der anderen Linie wieder einzusteigen. Welche Variante zu wählen ist, hängt von den Aussteigeanweisungen ab.

Fall 3. Wenn man die Zugangs- und Abgangsfunktion zwischen Außen- und Mittelbahnsteig tauscht, wird es wahrscheinlicher, dass es gesonderte Aussteigeanweisungen für Umsteiger gibt und somit für Umsteiger eingeschränkte "in+change"-Pios benötigt werden. Ansonsten wäre ein bahnsteiggleicher Umstieg für die Fahrt von A nach C und B nach D unmöglich.

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

Nehmen wir als Beispiel eine Station mit zwei Gleisen und drei Bahnsteigen, so dass es an jedem Gleis beidseitige Bahnsteige gibt. Zu den beiden Außenbahnsteigen führen nur Zugangstreppen und am gemeinsamen Mittelbahnsteig gibt es nur Abgangstrepppen.

Ja des gibt es... sollte auch berücksichtigt werden. Die Fahrgast wird auch darauf hingewiesen.. "Bitte an der nächsten Haltestelle rechts aussteigen." z.B.

Es heißt "Bitte" also.. es muss dann der Router gewichten, wenn der Umweg nicht sehr groß ist diesen zu wählen im Beispiel den rechten Ausstieg zu wählen..

---

OSM-Testkarte, DE-Notes Map, DE:Emergency Map, Maypole Map