Für Neu- und Umbauten sind üblicherweise 18m Bordlänge vorgesehen, Ausnahme 12m bei reinen Quartierbus-Haltestellen. Vgl. z.B. Nahverkehrsplan_der_Stadt_Frankfurt_am_Main_2025__Anlagenband__S.1-133_.pdf (traffiq.de) S.78. Leider geben die Bedingungen vor Ort das nicht in jedem Fall her (Einfahrten, Einbauten, Bäume, Probleme mit der Schleppkurve). Nach Abwägung kann es deshalb zu Abweichungen kommen.
In der Vergangenheit wurden Haltestellen nicht in diesem Umfang für Gelenkbusse geplant, so dass viele Haltestellen nicht die erforderliche Bordlänge aufweisen, insbesondere nicht für den Einsatz einer 4. Tür.
Beiträge von traffiQ
-
-
Zurück zum Thema: Mich würde mal die Begründung der TraffIQ interessieren warum in Frankfurt keine viertürigen gefordert werden. Würde durchaus Sinn machen. Vielleicht geht man bei der TraffIQ davon aus, dass Passagiere in Gelenkbussen bzw auf den Linien auf denen diese eingesetzt werden, länger reisen und deshalb mehr Sitzplätze zur Verfügung stehen sollen.
Viele Haltestellen sind nicht lang genug, um an einer 4. Tür einen problemlosen oder gar barrierefreien Ein- und Ausstieg zu ermöglichen.
-
Ab dem morgigen Betriebstag sind wieder lokale Daten auf Google Maps vorhanden. Wir gehen daher von einem technischen Problem aus, versuchen aber noch, Genaueres rauszukriegen.
-
GTFS bietet grundsätzlich die Möglichkeit, über Parameter in der Datei "transfers.txt" Mindestumsteigezeiten zu definieren. Evtl. ist diese optionale Datei aber nicht immer befüllt und es wird dann eine von Google bestimmte Umsteigezeit genommen. Grundsätzlich stellt sich hier ja auch die Frage, wer bei Haltestellen, die von mehreren Datenlieferanten bedient werden, die Mindestumsteigezeit definiert bzw. welche Google nehmen soll. Eine Hierarchie dürfte es naturgemäß nicht geben. So etwas wie Aufgabenträger, Netz- oder Infrastrukturbetreiber kennt Google z.B. nicht.
Dies ist einer von etlichen Nachteilen, die kleinteilige Strukturen mit sich bringen.Der deutschlandweite Datensatz z.B., hat dann nur eine "transfers.txt" und zumindest eindeutige Ergebnisse. (Auch wenn es in den vorhandenen Systemen natürlich auch immer wieder zu unbefriedigenden Auskünften kommt, sei es, weil eine Mindestumsteigezeit nicht oder zu lang/kurz definiert wurde oder weil auch unterschiedliche Systeme unterschiedliche Umsteigezeiten berücksichtigen (durchaus auch DB vs. RMV)).
-
Danke für die Aufklärung! Wöchentliche Aktualisierungen deuten aber darauf hin, dass es keine Echtzeitdaten gibt, ist das richtig? (Der Suchbegriff „API“ bei rmv.de bringt mir keine nutzbaren Ergebnisse grade.)
Das ist richtig. Noch.
Echtzeitdaten sind ziemlich komplex und machen auch intern einige Probleme bei der Datenkonsistenz.
GTFS und Echtzeit ... man muss sich zunächst klar machen, dass GTFS eigentlich "nur" aus etlichen strukturierten txt-Dateien besteht. Entstanden in einem Land, das quasi noch keine ÖPNV-Auskünfte kannte, während hier in Deutschland und Europa diese längst etabliert waren und sind.
Und darauf noch Echtzeitdaten aufzusatteln ... Google erwartet z.B. eine 30-sekündige Aktualisierungsrate der auf dem Server abgelegten Dateien. Die deutschlandweite Solldaten-Datei ist alleine schon ca. 3 GB groß, da müssen also andere Lösungen gefunden werden.
Und an diesen wird gearbeitet, nicht zuletzt um auch die aktuelle und künftige Gesetzeslage erfüllen zu können. Wer mag, kann ja mal die aktuelle Fassung des PBefG lesen und über die §§ 3a und 3b stolpern. und die dazugehörige Mobilitätsdatenverordnung. Für die Branche eine große Herausforderung. Aber sie ist dran. Und Open Data wird Usus werden.
-
Alles anzeigenDas hat dann der RMV geklärt (für sich). Aber hat wer Google gefragt, ob die damit zufrieden/einverstanden sind?
Naja, hier steht doch die Antwort:
Google wird seine eigene Schnittstellenbeschreibung/eigenes Datenformat haben und will, dass die Beteiligten die Daten in dieser Form zur Verfügung stellen. Wenn der RMV in der üblichen Manier ("Friss der stirb") agiert, kann ich mir gut vorstellen, dass so etwas dabei herauskommt.
Ich kann das verstehen, dass Google (und andere weltweit agierenden Konzerne) kein Interesse haben, für jeden Einzelfall etwas neues zu implementieren. Wie viele Verkehrsverbünde gibt es allein in Deutschland? Man stelle sich vor, das wäre auf der ganzen Welt so. Wer soll das bezahlen? Google will schließlich Geld verdienen durch die Daten...Die Frage ist daher nicht, wieso Google nicht die Daten vom RMV im RMV-eigenen, offenbar proprietären, Format nutzt, sondern wieso der RMV nicht in der Lage ist, die Daten in einer für Google direkt passenden Form zur Verfügung zu stellen? Wenn doch praktisch alle anderen Verkehrsverbünde und die Deutsche Bahn das auch schaffen, sollte das doch auch hier möglich sein, oder nicht? Das ist sicherlich kein technisches Problem - der RMV beharrt wahrscheinlich mal wieder auf seinem Standpunkt (ich denke an etwas wie: "Wir haben bereits eine Schnittstelle und die ist besser als eure!") - und ist daher aus Prinzip nicht bereit, das zu machen, was Google möchte.
Es ist nicht gut im Elfenbeinturm zu sitzen und sich anschließend zu wundern, wieso man isoliert ist...
Das auf dem Open-Data-Portal angebotene GTFS-Format ist das Google-Format! (GTFS: ehemals "Google Transit Feed Specification", mittlerweile "General Transit Feed Specification"). Und NeTEX wäre der EU-weite Standard, da würde es sich vielleicht auch für Google anbieten, sich anzupassen.
-
Der RMV stellt seit längerem seine Soll- und Ist-Daten über eine API zur Fahrplanauskunft transparent und kostenlos zur Verfügung:
Das ist bereits die von Condor angesprochene offene Schnittstelle (die Google aber nicht nutzen möchte):
Aus Kundensicht wäre es natürlich wünschenswert, wenn es eine offizielle, für jeden zugängliche Schnittstelle geben würde, die zudem auch noch Echtzeitinformationen liefert.
baeuchles Vermutungen sind daher unzutreffend (außer, dass es mit der DB tatsächlich eine andere Form der Zusammenarbeit gibt). Die Datenübernahmen als auch die Rechtslage sind abgesstimmt und geklärt (vgl. die Nutzungsbedingungen sowie die API-Beschreibung auf der RMV-Seite)
„offensichtlich offen“? Nein. Der DB Navigator bekommt die Daten aufgrund von gesonderten Absprachen. Zugfinder nimmt sich die Daten von irgendwo (und sagt nicht mal, was die Quellen sind), HereMaps sagt ebenfalls genau nichts über die verwendeten Daten (und holy shit, die tun so, als hätten die die selbst erhoben). Was ich annehme, ist, dass sie das jeweilige Webinterface (etwa vom RMV) nehmen, das HTML analysieren und daraus die Daten extrahieren. (So macht das auch die Öffis-App). Das ist weder ein sinnvolles Interface (ich kann gut verstehen, dass Google was anderes will), noch eines mit komplett geklärter Rechtslage (ist es legal, diese Daten zu nehmen und (dann auch noch ohne Quellenangabe) kommerziell weiterzugeben?
Zudem sind seit einiger Zeit auch alle RMV-Solldaten im Rahmen des deutschlandweiten Fahrplandatensatzes als Open-Data veröffentlicht, sowohl im GTFS- als auch im neueren und umfassenderen NeTEX-Format:
Warum dieser umfangreiche, wöchentlich aktualisierte, Datensatz von Google (und anderen) nicht bereits genutzt wird, um (fast) das ganze Bundesgebiet beauskunften zu können, wissen wir leider nicht.
-
Wir arbeiten gerade zusammen mit der VGF an einer konsistenteren Fahrgastinformation bei Baumaßnahmen und testen auch das ein oder andere im Realbetrieb. Aufgrund der vielfältigen (IT-) Anwendungen und der Vielzahl an Darstellungen ist das leider ein nicht ganz leichtes Unterfangen. Aber wir bleiben dran! Und sind für Rückmeldungen, was funktioniert und vor allem was nicht funktioniert, dankbar.
-
Dann hab ich wohl genau an der falschen Stelle nachgeschaut.
Das hatte ich ja auch bereits vermutet. Womit die Frage offen bleibt, warum traffiQ anderes kommuniziert.
Danke für die Hinweise. Wir korrigieren schnellstmöglich. Unsere Redaktion hat die VGF-Bekanntmachung leider missverstanden.
-
Knut ist so konzessioniert, dass die Nutzung der Niddabrücke kein Problem ist.
Und: Das Problem in der App konnte schonmal dahingehend gelöst werden, dass der korrekte (niedrigere) Preis angezeigt wird und die Fahrerinnen und Fahrer auch die Niddabrücke befahren. Die angezeigte Fahrtroute zwischen Harheim und Berkersheim Bf entspricht allerdings noch nicht ganz der realen Straßenführung.
-
Das Problem mit der Niddabrücke ist bekannt und leider nicht so einfach zu lösen. Das Routing erfolgt mit Google Maps und dieses kennt leider keine für Busse/On-Demand-Shuttles freigegebene Straßen. Wir sind mit dem Softwarehersteller aber am Arbeiten.
-
Und kommt man da auch online dran?
Es soll Leute geben, die den ÖPNV in mehreren Stadtteilen nutzen, wegen Wohnen und Arbeiten oder sonstigem. Die freuen sich sicher über die Details aller relevanten Ecken.
Der allgemeiner Flyer ist hier zum Download:
RMV Frankfurt - Metrobusse in Frankfurt
Wir klären, ob auch die vier Stadtteil-Broschüren angeboten werden können.
-
Es gibt vier "Stadtteilversionen", mit etwas individuelleren Informationen für jeweils mehrere Stadtteile. Und eine allgemeine Ausgabe für das restliche Stadtgebiet.
-
"Nied Brücke" ist eine reine Bushaltestelle. Die Tram hält dort nicht.
Danke. Wird - wie ein paar andere Fehlerchen auch - noch in der online-Fassung korrigiert.
-
Alles anzeigen
traffiQ Ihr schaut doch auch über den Tellerrand. Finde ich sehr gut
Falls ihr das nich nicht kennt, dazu passend das aktuelle ganz neue Handbuch für die Richtlinien der Fahrgastinformation des Verkehrsverbundes Berlin-Brandenburg.Eventuell gibt es dort die ein oder andere Inspiration.
PS: Leider veröffentlicht die BVG ihr eigenes Regelwerk als größtes VBB-Unternehmen nicht.
In den letzten 5 Jahren ist das Regelwerk um 123 Seiten gewachsen.Das VBB-Handbuch ist uns bekannt und in vielen Beziehungen sehr vorbildlich. Letztlich ist es allerdings Verbundaufgabe ...
-
Von einem BHNS ist man damit aber immer noch weit entfernt und von daher rechtfertigt ein 10-Minuten-Takt für mich keine Bennenung als Premiumpropdukt (wie es Traffiq definiert). Geld in die Infrastruktur oder in den Fuhrpark hat man wohl eher wenig investiert?
Das Fahrplan-Angebot der Metrobusse entspricht dem Straßenbahnniveau, geht teilweise sogar darüber hinaus. Daher sollte der Metrobus analog der Straßenbahnen auch im Netzplan dargestellt werden. Infrastruktur lässt sich nicht so schnell umsetzen, Metrobushaltestellen- und strecken sind auf der Prioritätenliste aber nach oben gerutscht.
-
Weiß jemand zufällig wann der GLP für 2021 veröffentlicht wird?
Wir warten noch auf die verkleinerte Webversion, um ihn im Internet zur Verfügung zu stellen. In der Verkehrsinsel müsste er schon in gedruckter Form zur Verfügung stehen, der Aushang an den Stationen hat auch bereits begonnen. Eine leichte Überarbeitung der Darstellung gibt es übrigens auch hier, als kleiner Test für eine notwendige grundlegende Überarbeitung.
-
Ach ja, damit die Diskussion zum Wochenende nicht einschläft:
RMV Frankfurt: Netzplan Nachtlinien (PDF, 1 MB)
Diese Aufgabe war letztlich fast noch schwieriger. Ziel war es, Wochentags- und Wochenendverkehr in einem Plan zu vereinen, um die "Nähe" zwischen Schiene und nahezu paralleler Nachtbus-Linie zu verdeutlichen. Gar nicht so trivial. Wir hoffen, uns ist auch hier ein verständlicher Plan gelungen.
Kleinere (und hofffentlich keine größeren) Unstimmigkeiten sind bestimmt noch enthalten, an der ein oder anderen Stelle (z.B. n96, X17, X19) haben wir auch auf eine Darstellung explizit verzichtet. -
Brr ich glaube, ich brauche noch ein bisschen, bis ich mich an diese Farben gewöhnt habe. Für mich sieht das so aus, als wäre es mal bunt gewesen und dann ist jemand im Zeichenprogramm auf die „Einfärben“-Funktion gekommen.
Was mir allerdings richtig gut gefällt sind die Formen. Der Kreis zwischen Schweizer Platz, Südbahnhof und weiter entlang der S-Bahn zur Konstablerwache, und die recht gleichmäßigen, fast parallelen Bögen von M32 und M34 (letzterer fortgesetzt durch die SL12) finde ich wirklich gut gelungen. Lob dafür!
Das mit den Farben ist nicht ganz falsch. In der Tat war der Plan zunächst "bunt". Letztlich ein wenig "zu bunt". Nach einigen Experimenten mit "Linienbündeln" á la Hannover, die bei der U-Bahn vielleicht funktioniert hätten, nicht aber bei der Tram, haben wir uns für die nun verwendete Lösung entscheiden. In der Hoffnung, hier einen guten Kompromiss zwischen Übersichtlichkeit, Lesbarkeit und ruhiger Darstellung gefunden zu haben. Und im Bewusstsein hier einen ungewohnten Weg eingeschlagen zu haben. Wir sind gespannt, wie er in der Öffentlichkeit ankommen wird.
Und danke für das Lob zu den Formen: die Metrobusbögen gefallen uns auch ausgesprochen gut
-
Stichwort Regionalzüge:
Wir verstehen den Wunsch nach einer Darstellung der Regionalzüge. Das Problem ist allerdings, dass dann aus unserer Sicht auch alle Strecken aufgenommen werden müssten, um nicht beliebig zu sein. Also nicht nur z.B. die "K-Bahn" sondern auch die Dreieichbahn bis Hauptbahnhof und Süd, die Strecken über Mainkur und Offenbach, die ganzen Parallel-Strecken zur S-Bahn usw. Als wir diese bei der Vorbereitung testhalber grob eingezeichnet haben und dazu noch die M-und X-Busse ... der Plan ist ohnehin schon komplex (und wird mit weiteren M-Bussen und neuem Tramkonzept noch komplexer), so dass wir auf die nächste Ebene der Regionalzüge wiederum verzichtet bzw. lediglich die Bahnhöfe mit Piktogramm gekennzeichnet haben.
Grundsätzlich sind im RMV und in fast allen anderen Verbünden Netzpläne hierarchisch aufgebaut. "Oben" entfallen Verkehrsmittel wie Straßenbahn und Bus, "unten" entfallen höherwertige Verkehrsmittel (wie in Frankfurt der Zug) oder werden generalisiert dargestellt (hier die S-Bahn). Wir denken, dass wir hier deutschlandweit in guter Gesellschaft sind. Man wird nicht viele Netzpläne finden, die von (Metro-) Bus bis Zug alles abbilden (und dabei noch einigermaßen lesbar bleiben).