Haltestellen mit Echtzeit Fahrplanauskunft

nach dem wir nun schon in einem anderen Thread darüber diskutiert haben, ist es an der Zeit hier jetzt einen eigenen zu eröffnen.

Also mal ehrlich. Ich möchte weder Transiki vorwegnehmen oder sonst irgendwie nicht aktualisierbare Fahrplandaten in Datenbanken schütten.

Mir schwebt eher vor eine Haltestelle hervor zu heben. Je nach Verkehrsmittel mit einem anders farbigen H-Symbol. Das Popup ist dann mit einer Internetadresse verknüpft. Dahinter versteckt sich dann wieder ein Skript (diese sind schon fertig) welches dann andere Webseiten gefiltert darstellt. Da wäre http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?ld=212.94&rt=1&input=Dresden%20Hbf%238010085&boardType=dep&time=actual&productsFilter=11111&start=yes oder http://www.vvo-online.de/de/fahrplan/abfahrtsmonitor/direkt.do/33000028

Interessant für mich ist eine Anwendung ähnlich wie diese: http://www.vvo-online.de/de/tourismus/stadtplan/index.aspx
Zoomt man hier weiter rein, werden die Haltestellen angezeigt und die nächsten Abfahrten an der Haltestelle. Leider ist für jede Haltestelle nur ein Punkt, so dass man nicht herausfindet wo jetzt welcher Zug, Bus oder Straßenbahn abfährt.
Um dem Verkehrsverbund zu zeigen, wie dies besser geht hatte ich mir gedacht einfach mal eine solche Karte zu erstellen. Leider klappt das alles noch nicht ganz wie gewünscht.

Als Vorarbeit ist es sicherlich noch erforderlich eine lokale OSM Datenbank aufzusetzen, da es erforderlich ist, zu jeder Haltestelle ersteinmal herauszufinden, welche Linie mit welcher/n Richtung/en dort verkehrt.

Ich hoffe das war jetzt soweit verständlich.

Hmm nun ein paar ähnliche Anwendungen gibt es ja schon.
http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services#Public_Transport
Ich würde mich an deiner Stelle mit den Transiki Leuten zusammentun um da etwas draus zu machen, dass auch genutzt wird.

Es ist sicher nicht die Aufgabe von OpenStreetMap auch noch die Fahrplandaten aller Transportunternehmungen aufzunehmen, dafür ist OSM nicht gemacht. Aber es steht dir frei an einen Projekt mitzuarbeiten, das dafür gedacht ist. Siehe dazu http://wiki.openstreetmap.org/wiki/WissensWert. Bis zum 30.Nov. kannst du sogar noch dafür abstimmen, damit es Fördergelder von Wikimedia erhält.

Wyo

Hallo !i!

ich habe bereits ausführlich über das für und wieder diskutiert. Ich persönlich habe auch versucht zur transiki Mailinglist zu schreiben, aber ich werde mir nicht einen weiteren Mailaccount bei Google zu legen nur um auf der Liste schreiben zu können.
Außerdem halte ich dieses Projekt für zum Scheitern verurteilt, sollte es so aufgebaut werden wie OSM. Der Unterschied zwischen Geodaten und Fahrplandaten ist nämlich die Häufigkeit und der Aufwand mit welchem sie geändert werden können. Ich kann mir nicht vorstellen, das jemand ein Interesse hat, jedes Jahr neue Fahrpläne für den Fernverkehr einzupflegen. Ich sehe den Aufwand bei anderen Projekten. Dort ist man seit einem halben Jahr dabei Fahrplandaten des im Dezember endenden Fahrplanjahres einzupflegen. Der Nutzen für Fahrgäste wäre hier mehr als nur fraglich!
Einziger Weg aus meiner Sicht können hier Schnittstellen sein, damit diese Daten automatisiert übernommen werden können. Aber schon bei Verkehrsverbünden werden Daten kleinerer Unternehmen nur für Änderungen von mehr als 3 Tagen in die Fahrplandatenbank eingepflegt. Bei der DB ist die Aktualisierung für Fremdunternehmen noch seltener.
Außerdem gibt es in Deutschland bereits das Projekt Delfi (http://www.delfi.de/) Dies ist ein Forschungsprojekt, welches zur Aufgabe hat oder hatte verteilte Fahrplanauskünfte zu rechnen. Dieser Ansatz wurde gewählt, da man davon ausgehen kann das einzelne lokale Services wesentlich aktueller sind, als eine integrierte Datenbank.
Außerdem hat der VDV bereits die Schnittstellen für Deutschland definiert. Für Europaweite Auskünfte gibt es den Quasistandard Hafas der Firma Hacon. Besonders fortschrittlich ist außerdem die tschechische Republik. Hier gibt es die landesweite Auskunft aus einer Hand. Allerdings ist diese beim Verkehrsministerium angesiedelt.

So aber nun zu deinen Kartenbeispielen. Die zweite Karte zeigt Minsk. Sogar in Sibieren findet man hier ÖPNV, aber wenn man auf den relevanten Bereich in Dresden zoomt, ist es eine Mapnikkarte.
Die ÖPNV karte wird derzeit leider nicht aktualisiert. Im Prinzip ist sie dem gewünschten Ergebnis schon sehr nahe. Nur werden auch hier keine Echtzeitinformationen und oder Links zu den Fahrplananbietern angezeigt. Dafür sieht man aber schon welche Linie an dieser Haltestelle hält. Leider erkennt man nicht die Richtung und außerdem wird es schnell unübersichtlich, wenn man mehrere Linienvarianten einer Linie an der gleichen Haltestelle hat.

Du siehst der gesuchte Zweck ist bei keiner Karte erfüllt. Kann er aber auch nicht, weil es hierfür weder einen deutschland- geschweige denn einen Weltweiten Standard gibt. Aber bei OSM ist es immer so, dass man eine Karte braucht um den Nutzen zu erkennen. Also muss hier eine Karte her, welche genau das tut!

Ja stimmt, ich wollte nur anregen, dass es allen vielleicht mehr bringt, wenn du dich in ein bestehendes Projekt einbringst und das verbesserst, anstatt extra neu anzufangen.
Wie wäre es denn, wenn du die ÖPNVKarte aufgreifst?

Hallo !i!

diese Idee hatte ich auch schon. Deswegen habe ich auch Kontakt zu Melchior aufgenommen und er war so freundlich mir die Serverfiles zu schicken. Nur habe ich leider keine Ahnung was ich damit anfangen soll, bzw. wie ich am besten anfange damit einen Server zu füttern.
Noch besser gefällt mir im Prinzip der Openstreetbrowser. Denn hier ist das Konzept, dass man sich alles anzeigen lassen kann. Die Grundkarte ist relativ nakt, aber über Menüs lassen sich alle Features anzeigen und sogar anklicken.
So werden zu Straßen die Hausnummern aufgelistet und bei Einkaufsmöglichkeiten die einzelnen Geschäfte oder Kneipen. Am liebsten hätte ich eine All in one Lösung, die nur das gerade gewünschte zeigt. Allerdings kann ich mit diesem Anspruch keine lauffähige Karte erstellen. Ich habe sogar Mühe den Mapnik zum laufen zu bekommen. Daher war ich froh über eine virtuelle Maschine, bei dem alles bereits eingerichtet war.
Dazu wollte ich einfach einen neuen Layer einbauen und dann …
Aber das ist sehr sehr aufwendig. Nachdem ich also die Öffnungszeiten Karte entdeckt habe dachte ich das es mit Openlayers schneller realisierbar sei, aber die Ansprüche sind eben doch sehr hoch. Jedenfalls wenn man nicht für jeden neuen Zweck neu anfangen möchte.
Andere Ideen die wir hier in Dresden hatten ist eine Karte, mit der man sich nicht nur alles aus der Datenbank anzeigen lassen kann, sondern auch gleich noch Zugriff auf Openstreetbugs und die anderen Qualitätssicherungstools hat.
Diese Funktion sollte eigentlich Openstreetmap.org oder .de liefern. Es gibt eine unendliche Sammlung von Karten und Tools. Aber für Außenstehende ist das weder nachvollziehbar noch erreichbar. Bei Google habe ich eine Anwendung maps.google.xxx von dort erreiche ich alels was mit der Karte zu tun hat. Geländeansichten, Sattelitenbilder, die Karte, Routenplaner, Streetview.

Den selbigen Gedanken hatte Markus nachdem er Melchior Moos kontaktierte.

Da die ÖPNVKarte momentan nicht weiter gepflegt wird hat sich Markus die Mühe gemacht und eine neue gemacht. Die ist seit Mittwoch online. Bitte nicht gleich los meckern, er hat nur beschränkte Hardware und alles ist noch nicht gerendert. Momentan werden jede Nacht die Zoomstufen 12-15 neu gerendert. Beim Rest schafft sein Rechner nur 7% der Fläche Deutschlands in einer Nacht zu rendern. Für konstruktive Kritik ist er aber dankbar.
Testet auch mal den + Knopf rechts oben.

Markus, hoffentlich geht jetzt dein Server nicht in die Knie.

http://openptmap.de/

st

Ich finde die für ein so frühes Stadium schon recht gut :slight_smile:

@viw Genau das ist ja der Punkt, es steckt unglaublich viel Arbeit und auch KnowHow in so einer Karte, da wäre es einfach schade, wenn sich 3 Leute unabhängig von einander dran setzen und so an der Arbeitslast scheitern :frowning:

Also diese Karte ist ausgezeichnet. Es fehlen allerdings noch Buslinien. Ich habe die Befürchtung, dass nicht alle Tags gerendert werden. nach dem ÖPNV Schema gibt es auch Relationen public_transport=line bzw. linevariant
Streng nach dem Shema müssten alle linevariant ohne angabe von ref auskommen, da diese in der übergordneten Relation mit line zu finden ist. Aber es stellt wohl ein großes Problem für das rendering dar, wenn nicht die Relationen direkt die Informationen enthalten. So war es zum Beispiel in der ÖPNV Karte nötig alle Relationen von linevariant zusätzlich entweder mit route oder line und dann einer ref zu versehen. der Openstreetbrowser hat ebenfalls Probleme damit.
Openstreetmap.org rendert auch keine Zugangsstellen, welche public_transport=platform getagt sind. Hier müssen immer noch highway=bs_stop, railway=tram_stop oder railway=platform dazu. Letzteres stellt Openstreetmap.org auf korrekt für Flächen und Multipolygone dar. Hieran scheitert Openstreetmap.de immer noch. Nachteil dieser Flächen: Straßen und Fußwege werden darüber gelegt. Egal in welchem Layer und ob bridged=yes.
Daher habe ich in Dresden angefangen Bahnsteige als Multipolygone zu erstellen. Dies ist auch recht sinnvoll für die Bezeichnung, da sich Mittelbahnsteige immer zwei Gleise teilen und es keine Unterscheidung wie in Tschechien zwischen Bahnsteig und Gleis gibt. (Ist aus Kundensicht auch unübersichtlicher Bahnsteig A mit Gleis 1 und 2.) Das Multipolygon hat den Vorteil, dass die Grenzen aus verschiedenen linienförmigen Objekten bestehen können. So sind die Bahnsteigkaten bei mir railway=platform mit name=, da Openstreetmap.org eine ref= nicht rendert und die sonstigen Grenzen sind und getagte Wege. Allenfalls an Treppenaufgängen sind diese Linien mit foot=yes getagt. Ob das dem Navi hilft weiß ich aber nicht. Das Multipolygon hat dann wieder railway=platform.
So stellt Openstreetmap.org zwei Bahnsteige auch über der Straße dar und malt Zwischenräume grau aus. Openstreetmap.de stellt nur die Bahnsteigkanten dar. http://www.openstreetmap.org/?lat=51.066025&lon=13.740772&zoom=18&layers=M

Openstreetbrowser steht unter GPL als git zur Verfügung. Man müsste nur eben etwas mit dem Quellcode anfangen. Seit 2009 hat sich dort aber nichts mehr entwickelt. Auch die ÖPNV-Karte scheint gerade nicht weiter entwickelt zu werden, so dass es eigentlich kaum alternativen gibt.
Für mein dafürhalten ist es besser wenn eine Website wie openstreetmap.de einen Grundlayer zur verfügung stellt und weitere Projekte dann entweder auf diesem Server Objekte hervorheben können.
Im Prinzip macht Netzwolf mit den Öffnungszeiten nichts anderes. Hier werden einfach Objekte mit Markern hervorgehoben. Schöner wäre das vielleicht als Layer schon vom Server berechnet als Kacheln. Das Popup schickt dann nur noch eine Meldung mit seiner ID zurück und der Server generiert daraus die Antwort.
So stelle ich mir im übrigen auch die Echtzeitauskunft vor. Das Objekt meldet die ID an den Server, darauf wird in der Datenbank abgefragt welche Linien und Richtungen dort verkehren und es wird aus den genannten Seiten dann die Antwort extrahiert, so lange kein Dienst in der Lage ist bereits gefilterte Antworten zu liefern. Dies wird insbesondere Bei Ausrückefahrten schwierig, aber es ist hoffentlich zu 90% lösbar. Bei den Gleisangaben bei der DB gibt es keine Schwierigkeiten.
Wie gesagt die Skripte zu herausfiltern der Informationen hätte ich. Ob das dann legal ist, muss man mit den Datenliferanten klären, wenn wenigestens ein Beispielbahnhof mit allem ÖPNV fertig ist. Ansonsten kann man den Ansatz auch gleich fallen lassen.

Sorry, ich bin wohl manchmal etwas schwer von Begriff :frowning:

Möglicherweise schwebt Dir etwas in der Art vor http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?

Gruß Wolf

Das Oxomoa-Schema unterstützt ja bereits Relationen für Linienvariaenten und die gesamte Linie (evtl. bestehend aus mehreren Linienvarianten), da braucht man also nur noch den Fahrplan zu intergrieren.
Das Problem ist eher, das der type=* der Relationen unterscheidlich gehandhabt wird, um die alten Haltestellen mit integrieren zu können. Ein anderes Problem ist, das die orginale Definition der stop_area_group so nicht zu benutrzen ist, da sie zu sehr mit Blick auf die reinen Datenbank-ErsatzGIS-Fahrplanauskunftskrücken wie HAFAS erstellt wurde, welche die Umsteigebeziehungen und Zeiten mangels fehlender Verortung der Haltestellen als Zeiten mit in der Datenbank speichern müssen. Außerdem rechtfertigt ein anderer Haltestellenname nicht mehr den Einsatz der stop_area_group-Relation, weil die Haltestelle ist ja, wie der Name sagt, eine ganz andere, das sie räumlich nur 50m neben Haltestelle x liegt und man da deshalb gut umsteigen kann, , bekommt ja jeder Router leicht aus den Geokoordinaten heraus. Transiki wollte wohl auch wieder Umsteigezeiten erfassen…

Die “Erfinder” der Relationen werden sich sicher erst recht über meine Subrelationen von anderen Relationen, freuen, wobei die Subrelationen nicht immer Objekte enthalten. Leider lassen sich aber auf andere Weise Baumstrukturen in OSM nicht (gut) darstellen. Aber das macht ja die Linienrelation auch schon…

Für die interen Darstellung (wo auch immer, weil in der OSM-DB müssen die Daten wegen der Wartung, ja leicht menschenverifizierbar sein), ist dein Vorschlag natürlich völlig in Ordnung. Die Fahrpläne sollte man auch leicht auf diesabled stellen können bzw. sollte man den Gültigkeitszeitraum angeben können (ist aber leider nicht immer möglich), denn die Wahrscheinlichkeit das Ferienfahrplan Osterferien sich nicht sehr von Ferienfahrplan Sommerferien für die gleiche Linienvariante unterscheidet ist aus meiner Sicht recht hoch.

Aus meiner Sicht sollte OSM nicht unbedingt ein Ersatz für die versäßliche Fahrplanauskunft der Anbieter sein, sondern eine besser-als nichts-Fahrplanauskunft. Mir reicht da pro Linienvariante schon die erste und letzte Fahrt und die mittlere Taktzeit mit Standardabweichung, um zu wissen, ob ich da überhaupt noch weg komme. Da ist auch egal, ob bei gleichem Takt, die Zeiten geringfügig verschoben wurden, weil mal gerade ein Fahrplanupdate die Zeiten um 8 Minuten verschoben hat. Ich kann damit immer noch halbwegs verläßlich meien Weiterfahrt planen, wenn ich unterwegs im Busch bin und keinen Internetzugang habe.

Aus meiner Sicht ist es nicht sinnvoll, die Fahrplandaten von den Linienvarianten zu trennen. Wenn man das vor hat, braucht man sowieso wieder eine eindeutige Haltestellen-ID pro Einzelhaltestelle um den passenden Fahrplan in der exterenen datenbank zu finden. Leider sind ja da die vorhandenen Systeme wie IBNR etc. auch nicht durchgängig anwendbar, bzw. konkurrieren mehrere Nummerierungssysteme, sofern sie die Haltestelle überhaupt abdecken.

Nahmd,

Yepp. Und ich habe bereits alle Buslinien von und nach Siegburg und Hennef nach Schema erfasst.

Einige Buslinien (insbesondere der 576 und der 577) haben eine überraschend große Anzahl von Routenalternativen. Ich habe mir da mal die Mühe gemacht, die Buslinien je Richtung in eine minimale Anzahl von “Segmente” zu teilen, so dass jede Haltestelle und jedes Wegstück exakt einem Segment zugeordnet ist, jedes Segment von einer Alternative vollständig oder gar nicht durchlaufen wird, und jede Routenalternative durch eine eindeutige Folge von Segmenten dargestellt wird.

An dieser Stelle habe ich das Schema erweitert:

  • die Rollenangabe für die Wege um die Segmentnummer (mit “:” abgetrennt)
  • die Rollenangabe für die Haltestellen um Segmentnummer und einen Minutenoffset gegenüber dem Beginn des Segments
  • für jede Routenalternative ein Attribut an der Relation, das die Segmente dieser Alternative auflistet

Damit ist die Linie mit allen Alternativen eindeutig beschrieben.

Eine Beispielrelation sieht dann so aus: http://www.openstreetmap.org/browse/relation/403521

Ich habe den Unfug dann noch weiter getrieben und zu jeder Alternative gespeichert, an welchen Tagen zu welchen Uhrzeiten ein Bus auf der Linie startet, und mit welchem Minutenoffset er den Beginn jedes Segments erreicht. Ich weiß selbst, dass diese Information jeweils nur bis zum nächsten Fahrplanwechsel gültig bleibt, sich also nicht auf Dauer pflegen lässt. Dazu bitte keine Diskussion.

Ich habs nur gemacht, um einmal das rein aus den Daten der Relation zu erzeugen: http://www.netzwolf.info/kartografie/osm/bus_und_bahn/fahrplan?relid=403521

Ich habe übrigens auch in Siegburg und Hennef die Busse an den richtigen Busstopps halten lassen. Die Service-Wege an den Busbahnhöfen in beiden Städten sehen sehr spaßig aus :slight_smile:

Ich habe die Fahrplandaten in die Linienvarianten integriert. Das Format ist grauslich, da alles mit der berühmten “heißen Nadel” gestrickt.

Leider sind die Relationsmember mit erweiterten Rollenangabe von der ÖPNV-Karte nicht angezeigt worden, da die Rollen nicht zu den “kanonischen” gehören, und meine Bitte, die Rollennamen einfach am ersten “:” zu splitten und nur den ersten Teil auszuwerten ( name.split(‘:’)[0] in JavaScript, (split(‘:’,$name)[0] in perl, also nicht wirklich aufwendig) wurde nicht erfüllt. Deshalb habe ich meine Arbeit abgebrochen, und deshalb gibt es auch keine Doku zu Projekt und Format.

Gruß Wolf

Also ich finde die Karte total Klasse, aber jetzt beginnt der Ärger. http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=17&lat=50.81244&lon=7.16524&layers=B00T
Die Haltestelle Ursulaplatz hat Haltestellen in zwei Richtungen. Aber die Anzeige ist für beide Richtungen mit den selben Abfahrten. Der Stand so wie du ihn hast zeigt mir jetzt schon alle Haltestellenmasten an, aber noch nicht die Abfahrten für den konkretten Mast. Dafür müsste man jetzt rausfiltern welche Richtungen an welchem Mast halten. Aber im Prinzip entspricht das genau in die Richtung meiner Vorstellungen.
Ich nehme an du machst das ganz über die IBNR und die Website der DB.

Nahmd,

Ja. Diese Version benutzt ausschließlich die IBNR, um die Informationen zu beschaffen.

Ich habe die Buslinien von und zu den Busbahnhöfen Siegburg und Hennef in Relationen erfasst mit allen Haltestellen inklusive der IBNR, und bei den zuletzt erfassten auch mit den Masten (habe ich früher nicht notiert). DAS ist die eigentliche Arbeit.

Das ist bereits in den Relationen erfasst. Nur werte ich die für diese Karte nicht aus.

Ja. Leider sind nur sehr wenig Haltestellen mit IBNR erfasst.
Wobei: das könnte mal jemand mit einem Robot erledigen. Denn das IBNR-Verzwichnis gibts (zumindest für DE) zum Download.

Gruß Wolf

Hallo Wolf,

ich weiß nicht ob IBNR ausreicht. Wenn ich mir zum Beispiel den Bf Neustadt ansehe, dann sind dort 8 Masten für den ÖPNV 10 Gleise (zwei vorübergehen ungenutzt) und weitere zwei Masten einer weiteren Haltestelle. Die haben natürlich alle die gleiche IBNR. Auch kann der VVO mit der IBNR nicht viel anfangen. Dort ist aber die Echtzeitinformation abzurufen. Die Fahrplandaten bekomme ich auch bei der DB. Wobei hier dann auch wieder gerechnet werden muss. Abfahrzeit + Verspätung. Wenn man die genaue Verspätung haben möchte wird es etwas komplizierter. Denn dann muss man für jeden einzelnen Zug die Details aufrufen. erst hier verrät die DB seit neustem wieder die minutengenaue Verspätung. Aber diese Details kann man ja noch aus dem Weg räumen. Denn das wichtigste für jede HST ein Popup mit einem eigenen Inhalt ist ja bereits gemacht. Jetzt braucht es noch die Datenbank welche die restlichen Daten beisteuert.
Achso und im Moment sind es bei dir auch nur die Bushaltestellen. Noch keine Bahnsteige wo die Züge zum jeweiligen Gleis angezeigt werden.

Es sind ja leider nicht nur die Masten, sondern auch noch die unterschiedlichen Haltepunkte zu erfassen, zumindest bei den (Eisen-/Stadt-)Bahnen. Zuerst wären da die Kurzügen die halten ja meist an einem Haltepunkt in Fahrtrichtung vor dem üblichen Haltepunkt. Selbst wenn man die Zusammenfaßt, hat sich die Bahn noch solche tollen Sachen wie geteilte Züge, die zuerst gemeinsam und ab Bahnhof x dann pro Halbzug in verschiweden Richtungen fahren, ausgedacht. Zudem ist beim Bus mit Haltetasche auch nicht ganz klar, wo man den Haltepunkt denn nun genau hinsetzen soll. Auf jeden Fall brauchen wir die Haltepunkte auch noch, selbst wenn man schon standardmäßig jedes H-Schild (platform) erfaßt hat. Man muß als Mapper ja schließlich auch immer etwas vor haben… :wink:

Also ich habe noch keine Ahnung wo der gewöhnliche Haltepunkt getagt werden soll. Es gibt da sehr viele Möglichkeiten. Nach der Grafik im Wiki müsste man bei Bussen die Mitte der der Bustasche nehmen.
Allerdings ist es für das routing Möglicherweise sinnvoller bei Bussen die erste Tür zu wählen. Hier sind in Dresden zum Beispiel die taktielen Steine für Sehbehinderte. Rollstuhlfahrer und Kinderwagen müssen aber in die zweite Tür. Auch das ist nicht wirklich die Mitte des Busses. Bei Straßenbahnen und Zügen sieht es noch schlimmer aus.
Also ich würde ehrlich gesagt nicht die H-Tafeln als Stopposition wählen sondern die Mitte des Bahnsteiges. Bei der S-Bahn in Berlin ist es immer das Ziel so zu halten, dass der Weg zum Ausgang möglichst kurz ist. Das ist meistens in der Mitte des Bahnsteiges. Bei uns in Dresden gibt es auch gelegentlich H-Tafeln, aber die haben mit dem Halt des Zuges nur wenig gemeinsam. Oft fehlen sie ganz.
Die Zugangsstelle tagge bei Bus und Straßenbahn tagge ich immer dort wo das Haltestellenschild steht. Da werden dann auch die Infos über Papierkorb und Unterstand hinzgefügt, obwohl die räumlich verschieden sein können.
Die Anzeige würde ich so wählen das am Haltestellenschild bzw. in der Bahnsteigmitte das Popup aufgeht mit der Anzeige der jeweiligen Abfahrten. Wo genau die Spitze ist, wird sich in den meisten Fällen dann schon ergeben. Auch eine Flügelung des Zuges würde ich eher in die Hand des Reisenden und der Auskunft auf dem Bahnsteig legen. Die Dinge sind eben flexibel und nicht zweifelsfrei nachvollziehbar.
Zum Schluss soll noch ersichtlich sein an welcher Stelle jeder einzelne Kurswagen zum stehen kommt. Ich denke dafür müssten wir die Wagenstandsanzeiger kopieren. Das ist doch eher illusorisch.

Ich wäre da auch für die Spitze des Gefährtes als Haltepunkt in Analogie zu den H-Tafeln, die zumindest ja z.B. bei der Berliner S-Bahn den Haltepunkt vorschreiben. Soweit ich weis habe ich das auch bei den Bushaltestellen überwiegend so gelöst. Zum Teil habe ich auch schon die “platform” als Weg eingezeichnet. Bei Bustaschen ist sie ja eindeutig vorgegebn und bei Fußweghaltestellen nimmt man die übliche Gefährtlänge.

So wird das aber im Moment soweit ich weis noch von den Eisenbahnern gemappt.

Ja, bzw. eben als Weg eintragen, wenn das ein Betsandteil eines Fußweges ist, dann hat bei mir das highway=bus_stop pech gehabt, das man da noch aus Kompatibilitätgründen hinzufügen könnte. Zusatzfeatures wie bin=, bench= etc. klebe ich auch an die platform.

Nein, cih wollte nicht den Wagenstandanzeigen kopieren, aber wie will man vernüftig die Routen berechnen und darstellen, wenn man es mit zwei Halbzügen zu tun hat und nur einen Punkt in die Bahnsteigmitte setzt? Wie sich die behindertengerechten Eingänge und welcher Wagentyp befindet ist aus meiner Sicht im Moment auch übers Ziel hinaus geschossen.

Die Idee ist gut, für mich nicht sehr eingängig, insbesondere der Fahrplan. Ich hoffe mal ich hab es richtig verstanden. Die Idee die Strecke in die minimale Segmentzahl zu splitten komplett nachvollziehbar, das sehe dann für das erweitere Oxomoa-Scheme in etwa so aus:

Relation 1 (pro Segment):
type=public_transport
public_transport=segment
stop_offset=1,3,10-5,14 (Abfahrtszeiten-Aufenthaltszeit in Minuten relativ zum Segmentanfang)
Mitglieder: alle angefahrenen public_transport=stop_position (+ evtl. die zugehörige public_transport=platform)

Relation 2 (pro Linenvariante):
type=public_transport
public_transport=variant
departure_times=* (sinnvolles Format für die Abfahrtszeiten)
exceptions=* (Format für die ganzen Datenumsausnamen (wie “fährt nicht am x”) für dieses Linenvariante)
Mitglieder: alle angefahrenen Segment-Relationen

Relation 3: (Gesamtlinie):
Mitgleider: alle betreffenden public_transport=variant-Relationen

public_transport=variant und public_transport=linie gibt es schon, da braucht man nur noch eine Erweiterung für die Segmente

Siehe mein Erweiterungsversuch für das Oxomoa-Schemma oben, den hab ich gerade mal so aus dem Stehgreif zusammengezimmert. Da braucht die ÖPNV-Karte auch nichts zu separieren und das Ganze ist hoffentlich wenigen fehlerträchtig als die “:”-Schtreibweise von dir.