-
FELD
-
Diese Erfindung bezieht sich auf die Reiseplanung im öffentlichen Personenverkehr. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
-
HINTERGRUND
-
Es wurden Reiseplanungssysteme für den öffentlichen Personenverkehr entwickelt, die es Reisenden ermöglichen, ihre Strecke in Systemen des öffentlichen Personenverkehrs unter Berücksichtigung einer ausgewählten Start- oder Ankunftszeit für die Reise zwischen ausgewählten Start- und Endzielen zu planen.
-
Die Reise kann die Benutzung von mehr als einer Transportstrecke beinhalten, beispielsweise verschiedene Zugstrecken, Busstrecken oder Fähren und kann einen Übergang von einem bestimmten Bahnhof oder Haltestelle zu einem anderen Verkehrsmittel auf einer anderen Strecke beinhalten, was auch einen Fußweg bedeuten kann, um einen Übergang zwischen den Strecken zu bewältigen.
-
Bislang wurden veröffentlichte Zug-, Bus- oder andere Transportfahrpläne mit Abfahrt- und Ankunftszeiten für einzelne Bahnhöfe oder Haltestellen (nachfolgend zusammengefasst Bahnhöfe genannt) dazu verwendet, um Daten entsprechend einer Transitgrafik zu generieren. Diese Grafik beinhaltet die Knotenpunkte, die jeweils einen Punkt in Raum-Zeit repräsentieren, zu dem ein Ereignis an einem bestimmten Bahnhof stattfindet, zum Beispiel eine Ankunfts- oder Abfahrtszeit. Bogen, welche die Knotenpunkte verbindenden, repräsentieren Wege, an denen der Reisende vorbeikommen kann, sodass eine Strecke in Bezug auf die praktikablen Bögen zwischen den Knotenpunkten geplant werden kann.
-
Mittels Durchführung einer Abfrage in den Transitgrafikdaten kann daher eine Strecke geplant werden und es können Schritt für Schritt Anweisungen gegeben werden, um ein bestimmtes Ziel mit mehr als einer Art von öffentlichen Verkehrsmitteln zu erreichen. Die Abfrage kann in den Transitgrafikdaten selbst vorgenommen werden oder in vorausberechneten Transfermustern für Strecken zwischen einem bestimmten Anfangs- und Endziel. Die Vorausberechnung wird durchgeführt, um die Datenverarbeitungsmenge, die der abfragende Anwender benötigt, zu reduzieren, wie zum Beispiel in
US 2011/0112759 A1 beschrieben.
-
Jedoch werden nicht alle Fahrplandaten für den öffentlichen Personenverkehr in einer Form veröffentlicht, die einfach in die Transitgrafikdaten integriert werden kann, die, wie oben angegeben, Ereignisse zu definierten Zeiten an den Bahnhöfen als Knotenpunkte bereitstellen, zum Beispiel eine Bahnankunftszeit oder -abfahrtszeit. Im Gegensatz dazu definieren einige öffentlichen Verkehrssysteme ihr Dienstleistungsangebot als eine Tagesanfangszeit, wenn der Service beginnt, und einer Tagesendzeit, wenn er aufhört, sowie einem Wiederholungsfahrplan für aufeinanderfolgende Fahrten eines Fahrzeugs von einem bestimmten Bahnhof, die durch einen allen gemeinsamen Zeitraum getrennt sind (P). Die veröffentlichten Fahrplandaten geben beispielsweise möglicherweise an, dass die Züge von einem bestimmten Bahnhof ab 06.00 Uhr fahren, um 23.00 Uhr enden und nominell alle 10 Minuten bereitstehen, obwohl sich der Zeitraum für aufeinanderfolgende Züge in der Praxis aufgrund von operativen Variablen möglicherweise ab dem nominellen Zeitraum P für aufeinanderfolgende Züge ändern kann.
-
ZUSAMMENFASSUNG
-
In den Ausführungsformen der im Folgenden beschriebenen Erfindung sind diese Wiederholungsfahrplandaten in die Transitgrafikdaten eingearbeitet und eine Streckenplanungsabfrage, in der die Ungewissheit von Wartezeiten auf Fahrzeuge, die in einem Wiederholungsfahrplan betrieben werden, auf geeignete Art und Weise berücksichtigt wird, kann durchgeführt werden.
-
In einer Ausführungsform ist die Definition von Knotenpunkten in den Transitgrafikdaten, die einzelne Tageszeiten simulieren, an denen die Fahrzeuge am ersten der Bahnhöfe gemäß dem Wiederholungsfahrplan, in dem nachfolgende Fahrten vom ersten Bahnhof durch den allen gemeinsamen Zeitraum (P) getrennt sind, anhalten würden, in einem computerimplementierten Verfahren enthalten. Die simulierten einzelnen Tageszeiten für die entsprechenden Knotenpunkte des Wiederholungsfahrplans werden anschließend durch einen Zeitraum, der geringer als oder gleich dem Zeitraum (P) ist, getrennt und führen so eine Berechnungsabfrage hinsichtlich der Transitgrafikdaten durch, um einen Reisefahrplan für eine Strecke zwischen einem avisierten Bahnhof und einem Zielbahnhof durch und wenn die Strecke über den ersten Bahnhof hinausgeht und die Reise gemäß einem Wiederholungsfahrplan beinhaltet, wird für die Strecke bestimmt, dass die Reisezeit eine Wartezeit am ersten Bahnhof von mindestens dem allen gemeinsamen Zeitraum (P) beinhaltet.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Um die Erfindung verständlicher zu machen, wird nun eine Ausführungsform derselben mittels eines veranschaulichenden Beispiels mit Bezug auf die beigefügten Zeichnungen beschrieben, in denen:
-
1 ein schematisches Blockdiagramm eines Streckenplanungssystems ist;
-
2 ein veranschaulichendes Beispiel einer Transitgrafik ist;
-
3 ein schematisches Flussdiagramm ist, das die Erstellung von Transitgrafikdaten und Transfermustern durch ein Vorberechnungsmodul, wie in 1 dargestellt, und auch die Bildung einer Abfragegrafik als Reaktion einer Anwenderabfrage zur Auswahl der besten Strecke veranschaulicht;
-
4 ein Flussdiagramm ist, das die Abfrageleistung veranschaulicht;
-
5 ein schematisches Diagramm der Vorberechnung von Knotenpunkten für veröffentlichte Transportfahrpläne ist, welche den Wiederholungsfahrplan des Zeitraums P verwenden; und
-
6 einen Prozess veranschaulicht, der vom Abfragemodul für einen Bahnhof, an dem ein Wiederholungsfahrplan auftritt, durchgeführt wird.
-
DETAILLIERTE BESCHREIBUNG
-
Überblick
-
1 ist ein Blockdiagramm mit einer Reiselösung mit öffentlichen Verkehrsmitteln, in der ein Anwender ein Client-Gerät 1 verwenden kann, welches durch ein Netzwerk 2 mit einem Transitserver 3, der eine Streckeninformationsdatenbank 4 an einer Transitdatenbankinformation 5 bereitstellt, verbunden ist. Das Netzwerk 2 kann aus einem jeden geeigneten Netzwerk bestehen, wie zum Beispiel das Internet oder ein anderes WLAN, ein drahtloses Kommunikationsnetzwerk oder ein LAN, welches drahtgebunden oder drahtlos sein kann. Das Client-Gerät kann einen Computer, der tragbar sein kann, oder ein mobiles Telekommunikationsgerät mit Internetfunktion umfassen.
-
Der Transitserver 3 ist so konfiguriert, dass er auf Anfragen des Anwender-Clients 1 reagiert, um dem Anwender als Reaktion auf eine Abfrage nach der optimalen Strecke zwischen dem vom Anwender definierten Startpunkt und dem von ihm definierten anvisierten Ziel entsprechende Streckenplanungsinformationen bereitzustellen, beispielsweise eine bestimmte Abfahrts- und Ankunftszeit.
-
Wie in 1 dargestellt, besteht der Transitserver 3 aus mehreren Bearbeitungsmodulen. Es ist leicht nachzuvollziehen, dass sich der Terminus „Modul” auf die Computer-Logik bezieht, die verwendet wurde, um eine spezifizierte Funktionalität bereitzustellen. Daher kann ein Modul in Hardware, Firmware bzw. Software, die einen Allzweck-Prozessor steuert, implementiert werden. In einer Ausführungsform sind die Module Programmcode-Dateien, die auf dem Speichergerät gespeichert sind, in den Speicher geladen wurden und von einem Prozessor ausgeführt wurden oder die von Computerprogrammprodukten bereitgestellt werden, zum Beispiel vom Computer ausführbare Befehle, die in einem konkreten, computerlesbaren Speichermedium, wie zum Beispiel auf einer RAM-Festplatte oder auf optischen oder magnetischen Medien, gespeichert sind.
-
Darüber hinaus ist es nachzuvollziehen, dass die Ausführungsformen des Servers 3 verschiedene oder andere Module als die hier beschriebenen umfassen können, wobei die beschriebenen Funktionalitäten auf unterschiedliche Art und Weise unter den Modulen verteilt sein können.
-
Vorausberechnung – Vorbereitung der Transitgrafik
-
Unter Bezugnahme auf 1 ist der Transitserver 3 so konfiguriert, dass er die Daten entsprechend einer Transitgrafik entwickelt, was im Anschluss noch näher beschrieben wird, und zu diesem Zweck beinhaltet der Server ein Transitinformations-Interface 6, das die von den verschiedenen Transportdienstanbietern, wie Schienenverkehrsanbieter, Busunternehmen, und ähnliche, veröffentlichten Fahrplandaten bei Veröffentlichung empfängt. In einem Beispiel ist jede Agentur, die solche Fahrplandaten bereitstellt, mit dem Transitserver 3 verbunden, um die Fahrplandaten in einem spezifizierten Format, wie zum Beispiel als Google Transit Feed Specification (GTFS), bereitzustellen, das unter http://code.google.com/transit/spec/transit_feed_specification.html beschrieben ist. Die empfangene Transitinformation enthält die Fahrpläne öffentlicher Verkehrsmittel und beschreibt die Kalenderdaten, an denen ein Fahrzeug des öffentlichen Personenverkehrs eine bestimmte Fahrt unternimmt, die Bahnhofsinformation, z. B. die Adresse und Beschreibung der Bahnhöfe, an denen auf der Reise gehalten wird. Andere Attribute der Reise können Reisepreis und die Uhrzeiten, an den an den verschiedenen Bahnhöfen entlang einer bestimmten Strecke gehalten wird, sein.
-
Die empfangenen Transitinformationen aus an den verschiedenen Quellen werden in der Transitinformationsdatenbank 5 gespeichert. In Datenbank 5 können beispielsweise Busfahrplandaten von einem öffentlichen Busverkehr, Zugfahrplandaten für lokalen Pendelzugverkehr und U-Bahnfahrpläne eines U-Bahnsystems gespeichert werden. Andere Fahrplandaten sind für Experten ebenfalls sichtbar.
-
Die in der der Transitinformationsdatenbank 5 gespeicherten Daten werden mittels einer Transitgrafik gespeichert, die durch das Vorausberechnungsmodul 7 vorbereitet wird und die ein Transitgrafikmodul 8 und ein im Folgenden beschriebenes Transfermuster-Berechnungsmodul 9 enthält.
-
Für jede Ankunft bzw. Abfahrt des Fahrzeugs an einem Bahnhof fügt das Transitgrafikmodul 8 Knotenpunkte in eine Transitgrafik ein, in der eine Achse die Entfernung zwischen den Bahnhöfen darstellt und die andere Achse den zeitlichen Verlauf. Typischerweise werden zwei Knotenpunkte eingefügt, die jeweils ein Ankunfts- und ein Abfahrtsereignis zu den entsprechenden Uhrzeiten darstellen. Wenn also ein Fahrzeug nicht an einem Bahnhof ankommt bzw. abfährt, wird für diesen Bahnhof kein Knotenpunkt erstellt, da an diesem Bahnhof weder ein Ankunfts- noch ein Abfahrtsereignis stattfindet. Da die Knotenpunkte von den spezifizierten Fahrplandaten, die auf dem Interface 6 erhalten wurden, generiert werden, ist jeder Knotenpunkt einem Fahrzeug an einem Bahnhof zu einer bestimmten Zeit zugewiesen. Ein Knotenpunkt in der Transitgrafik kann ein Bahnhofsknotenpunkt oder ein Onboard-Knotenpunkt sein. Ein Bahnhofsknotenpunkt stellt ein Fahrzeug am Bahnhof dar, in das der Anwender steigen kann, um eine Reise anzutreten. Im Gegensatz dazu stellt ein Onboard-Knotenpunkt ein öffentliches Transitfahrzeug dar, in dem sich der Anwender derzeit befindet. Die Knotenpunkte in der Transitgrafik sind mit Bögen, welche die Strecke einer Reise beschreiben, miteinander verbunden. In den hier beschriebenen Beispielen gibt es vier Arten von Bögen: Einstiegsbögen, die ein Fahrzeug, in das am Bahnhof eingestiegen wird, beschreiben, Einstiegs- oder Ausstiegsbögen, die ein Fahrzeug beschreiben, das an einem Bahnhof mit der Option eines Fußwegs verlassen wird, wenn die Person zu einem anderen Bahnhof läuft, um zur Beendigung der Reise ein Transitfahrzeug zu besteigen; Wartebögen, die eine Person beschreiben, die an einem Transitbahnhof wartet, und Transitbögen, die den Verbleib an Bord eines Fahrzeugs zwischen zwei Haltestellen auf einer Reise beschreiben.
-
Wie oben beschrieben analysiert das Transitgrafikmodul 8 die über das Interface 6 empfangenen Fahrplandaten, um die an den einzelnen Bahnhöfen stattfindenden Ereignisse zu bestimmen. Auf der Grundlage des Ereignisses setzt das Transitgrafikmodul 8 einen entsprechenden Knotenpunkt (entweder Bahnhof oder an Bord) in der Transitgrafik und verbindet die Knotenpunkte mit Bögen. Die Art des Bogens, der zwei Knotenpunkte verbindet, basiert auf der Tatsache, ob die zu verbindenden Knotenpunkte Bahnhofs- oder Onboard-Knotenpunkte sind. Wenn die Transitinformation beispielsweise beschreibt, dass ein Fahrzeug an Bahnhof A bestiegen wurde und transferlos zu Bahnhof B fährt, enthält das Transitgrafikmodul 8 einen Bahnhofsknotenpunkt, der Bahnhof A zugewiesen ist, und einen Onboard-Knotenpunkt, der Bahnhof B zugewiesen ist, in der Transitgrafik. Daher ist der Bogen, der die Knotenpunkte verbindet, ein Einstiegsbogen. In einem anderen Beispiel gilt, dass wenn ein Onboard-Knotenpunkt mit einem Bahnhofsknotenpunkt verbunden ist, es sich bei dem Bogen, welcher die Knotenpunkte verbindet, um einen Einstiegsbogen handelt.
-
Ein Beispiel eines Teils einer Transitgrafik ist in 2 veranschaulicht. Die Y-Achse der Transitgrafik stellt die Zeit dar und die X-Achse stellt die Bahnhöfe A, B, C ... dar. Es ist nachzuvollziehen, dass die X- und Y-Achsen, wie hier veranschaulicht, als eine praktikable Art und Weise zu verstehen sind, um die Verwendung der Transitgrafikdaten zu erklären, und in der Praxis beinhalten die in der Datenbank 5 gespeicherten Transitgrafikdaten keine X- oder Y-Achse und die Knotenpunkte der Grafiken sind auch nicht so räumlich angeordnet, wie in der FIGG. gezeigt. 2.
-
In dieser Veranschaulichung ist die Y-Achse eine Zeitdarstellung eines einzigen Tages und für jeden Bahnhof S, der auf der X-Achse dargestellt ist, fügt das Transitgrafikmodul 8 eine Reihe von Knotenpunkten zur Transitgrafik hinzu, die dann auf der Y-Achse angeordnet werden. Jeder Knotenpunkt in der Serie, der mit einem Bahnhof verbunden ist, stellt ein Transitereignis da, das zu einer bestimmten, dem Knotenpunkt zugewiesenen Zeit am Bahnhof eintritt.
-
Wie in der Transitgrafik gezeigt, enthalten die Bahnhöfe A, B, C... eine Reihe von Knotenpunkten in unterschiedlichen Zeitintervallen. Mit „S” gekennzeichnete Knotenpunkte sind Bahnhofsknotenpunkte und Knotenpunkte mit der Kennzeichnung „O” sind Onboard-Knotenpunkte, wie zuvor besprochen. Jeder Bahnhofsknotenpunkt, der einem bestimmten Bahnhof zugewiesen ist, ist einem Ereignis, das an dem Bahnhof zu einer bestimmten Zeit stattfindet, zugewiesen. Die Bahnhofsknotenpunkte S für Bahnhof A sind in zeitlicher sequenzieller Abfolge verbunden dargestellt, um zu veranschaulichen, dass eine Person über einen Zeitraum zwischen TA1 und TA2 an Bahnhof A warten kann.
-
Für eine weitere ausführlichere Beschreibung von Transitgrafiken verweisen wir auf
US 2011/0112759 A1 , welches als Referenz in dieses Dokument aufgenommen wurde.
-
Vorausberechnung – Übertragungsmuster
-
Typischerweise können die Transitgrafikdaten, die erstellt und in der Transitinformationsdatenbank
5 gespeichert werden, aus Bögen für eine sehr große Anzahl an Knotenpunkten bestehen, zum Beispiel für Bahnhöfe, die über einen ganzen Kontinent oder eine geographische Region, wie z. B. Nordamerika oder Europa, verteilt sind und obwohl eine Streckenplanungsanfrage mit Bezug auf die Transitgrafikdaten vorgenommen werden kann, kann dies mit einer längeren Bearbeitungszeit verbunden sein. Um dieses Problem zu bewältigen, enthält das in
1 beschriebene Vorausberechnungsmodul
7 das Transfermuster-Berechnungsmodul
9, das für die Definition und Vorausberechnung möglicher Strecken zwischen Bahnhöfen, für welche die Knotenpunkte in einer Transitinformationsdatenbank
5 gespeichert sind, einsatzfähig ist, d. h. vorausberechnet wurde, bevor die Planungsanfrage gestellt wurde. Für eine weitreichendere Erklärung wird auf
US 2011/0112759 verwiesen, dessen Inhalt in diesem Dokument als Referenz eingearbeitet wurde.
-
Die möglichen Strecken werden mittels einer Suche zwischen den Knotenpunkten und entlang der Bögen nach Start- und Zielbahnhöfen für eine bestimmte Reise berechnet, indem die preisgünstigste Route entlang der Bögen, wie in der Transitdatenbank 5 definiert, zwischen den Knotenpunkten gesucht wird. Die Suche kann mit einem geeigneten Suchalgorithmus, wie dem Dijkstra Suchalgorithmus, durchgeführt werden.
-
Wie oben in
US 2011/0112759 erläutert, kann jeder Knotenpunkt mit einem mehrdimensionalen Kostenparameteretikett für Elemente, wie die Reisedauer bei einem Fußweg zwischen zwei Knotenpunkten usw., getaggt sein, sodass ein kostengünstigster Weg zwischen dem Start- und dem Zielknotenpunkt berechnet werden kann. Für einen bestimmten avisierten Knotenpunkt und Zielknotenpunkt werden die optimalen Transfermuster dazwischen über einen bestimmten Zeitraum berechnet, z. B. 1 Tag, 1 Woche o. ä., und die Ergebnis-Transfermuster werden in der in
4 gezeigten Streckeninformationsdatenbank gespeichert.
-
Die Vorausberechnung der Transfermuster wird zumindest für den größten Teil der Start-Ziel-Knotenpunktpaare, die in der Transitinformationsdatenbank 5 gespeichert sind, vorgenommen.
-
Der Vorausberechnungsprozess ist schematisch in 3 veranschaulicht. In Schritt S3.1 berechnet das Transitgrafikmodul 8 des Vorausberechnungsmoduls 7 die Transitgrafikdaten, die in der Transitinformationsdatenbank 5, wie in 1 gezeigt, gespeichert werden.
-
In Schritt S3.2 berechnet das Transfermusterberechnungsmodul 9 die Transfermuster über einen bestimmten Zeitraum zwischen einer Vielzahlvon verschiedenen Start- und Zielknotenpunkten, wie oben beschrieben, und speichert die resultierenden Transfermusterdaten in der Streckeninformationsdatenbank 4.
-
Anfragen
-
Wenn ein Anwender unter Verwendung des Systems eine Reise planen möchte, kann er Client 1 benutzen, um eine Anfrage durch Netzwerk 2 an ein Frontend-Interface 10 zu senden, welches die Anfrage an ein Anfragenlösungsmodul 11 liefert, das die in der Streckeninformationsdatenbank 4 gespeicherten Transfermusterdaten abfragt.
-
Der Anwender kann den Browser 12 verwenden, der auf dem Client 1 läuft, um den avisierten Ort zu definieren, von dem aus die Reise beginnen soll zusammen mit dem Zielbahnhof und einer Starttageszeit für die Reise. Zur Vereinfachung in diesem Beispiel ist der avisierte Ort ein Bahnhof, auf den hier als avisierter Bahnhof Bezug genommen wird, aber es ist leicht nachzuvollziehen, dass der avisierte Standort jeder andere geeignete Standort auf der Landkarte sein kann. Diese Information wird an das Anfragenlösungsmodul 11 kommuniziert, welches dann eine Anfragengrafik aus den in Datenbank 4 gespeicherten Transfermustern aufbaut unter Bezugnahme auf die vom Anwender definierten avisierten Bahnhöfe und Zielbahnhöfe. Dies wird in Schritt S3.3 in 3 veranschaulicht.
-
Die Anfrage läuft dann auf den Daten der Anfragengrafik in Schritt S3.4, um die optimale Strecke zwischen dem avisierten und dem Zielbahnhof auszuwählen.
-
Unter Bezugnahme auf 4 in Schritt S4.1 verwendet der Anwender den Browser 12 von Client 1 (1), um eine Anfrage zu definieren, die einen avisierten Bahnhof, einen Zielbahnhof und eine Startzeit für die Reise beinhaltet. Alternativ kann eine Ankunftszeit definiert werden. Die Anfrage wird an das Anfragenlösungsmodul 11, wie in 1 beschrieben, übertragen, welches eine Anfragengrafik aus den Transfermustern aufbaut, wie in Schritt S4.2 beschrieben.
-
Aus den vorstehenden Ausführungen ist ersichtlich, dass die Anfragengrafik, die für die definierten Start- und Zielbahnhöfe zur definierten Zeit spezifisch ist, eine Anzahl praktikabler Routen die durch die Bögen zwischen den möglichen Knotenpunkten zwischen dem avisierten Knotenpunkt und dem Zielknotenpunkt definiert werden, beinhalten kann.
-
Bei Schritt S4.3 läuft dann eine auf einer definierten Startzeit basierenden Anfrage über das Anfragelösungsmodul 11 unter Verwendung des geeigneten Suchalgorithmus, um eine oder mehr kostengünstige Strecken zu identifizieren, um so eine Strecke und den damit verbundenen Fahrplan auszuwählen, wie in Schritt S4.4 veranschaulicht. Jeder geeignete Suchalgorithmus kann verwendet werden und als anschauliches Beispiel wird die Verwendung des Dijkstra-Algorithmus im Folgenden beschrieben, obwohl andere Algorithmen mit einer ähnlichen Funktionalität dem Experten geläufig sein werden.
-
Die resultierenden Daten werden dann vom Server 3 durch das Frontend-Interface 10 und das Netzwerk 2 an den Client 1 übertragen, um auf Browser 12 dem Anwender präsentiert zu werden. Die Strecke bzw. der Fahrplan wird unter Bezugnahme der auf der ausgewählten Strecke benutzten Bahnhöfe gezeigt, zusammen mit Einzelheiten über Transfers oder erforderliche Transite zwischen verschiedenen Bus- oder Eisenbahnlinien, sowie die damit verbundenen Zeiten.
-
Wiederholungsfahrplan-Informationen
-
Aus dem Vorhergehenden ist ersichtlich, dass die von Modul 8 anhand der Fahrplandaten erstellten Transitgrafikdaten, die vom Transitinformations-Interface 6 empfangen werden, wie in 1 gezeigt, die Platzierung von Onboard-Knotenpunkten O und Bahnhofsknotenpunkten S in der Transitgrafik, wie in 2 gezeigt, beinhaltet. Für konventionelle Eisenbahn- und andere Fahrpläne kann dies als Ankunfts- und Abfahrtszeiten der in den von den Transportdienstleistern veröffentlichten Fahrplänen spezifizierten Fahrzeuge berechnet werden.
-
Jedoch werden nicht alle Fahrplandaten für das öffentliche Verkehrssystem in einer Form veröffentlicht, die ohne Weiteres in die Transitgrafikdaten eingearbeitet werden kann. Einige öffentliche Verkehrssysteme definieren ihre Serviceleistung hinsichtlich der Anfangsuhrzeit, wenn der Service beginnt und einer Tagesendzeit, wenn er aufhört, sowie einem Wiederholungsfahrplan für aufeinanderfolgende Fahrten eines Fahrzeugs von einem bestimmten Bahnhof, die durch den gleichen Zeitraum getrennt sind, z. B. kann ein Bus laut Fahrplan alle 10 Minuten zwischen 06.00 Uhr und 23.00 Uhr an einer Bushaltestelle ankommen. Es gibt jedoch eine Ungewissheit bei Wiederholungsfahrplänen hinsichtlich, wann das Fahrzeug tatsächlich am Bahnhof eintrifft, aufgrund von Verkehrsaufkommen usw. und so kann der allen gemeinsame Zeitraum P für jedes nachfolgende Fahrzeug etwas variieren.
-
Unter Bezugnahme auf 1 enthält das Vorausberechnungsmodul 7 ein Wiederholungsfahrplan-Bearbeitungsmodul 13, das die vom Transitinformations-Interface 6 empfangenen Wiederholungsfahrplan-Informationen bearbeitet, wie zuvor beschrieben. Das Wiederholungsfahrplan-Bearbeitungsmodul 13 führt einen in 5 schematisch veranschaulichten Prozess durch, um zu ermöglichen, dass die Daten des Wiederholungsfahrplans in den Transitgrafikdaten, die in der Transitinformationsdatenbank 5 gespeichert werden, einbezogen werden können.
-
Der Prozess beginnt mit Schritt S 5.1, in dem die Fahrplandaten analysiert werden, um zu bestimmen, ob ein Wiederholungsfahrplan für einen bestimmten Bahnhof Sn in Kraft ist, wie in Schritt S5.2 dargelegt. Andernfalls wird der nächste Bahnhof Sn + 1, wie in Schritt S5.3 aufgeführt, bearbeitet.
-
Wenn für den Bahnhof Sn ein Wiederholungsfahrplan in Kraft ist, werden die vom Transitinformations-Interface 6 empfangenen Fahrplandaten überprüft, um eine Startzeit T1 und eine Endzeit T2 und einen allen gemeinsamen Zeitraum P für den Fahrplan zu erhalten. Die veröffentlichte Fahrplandaten können beispielsweise spezifizieren, dass ein Fahrzeugservice, wie zum Beispiel eine Zugwartung, an einem bestimmten Bahnhof zur Startzeit T1 = 06.00 Uhr beginnt und zur Endzeit T2 = 23.00 Uhr aufhört und dass die Fahrzeuge für den Personenverkehr alle P = 10 Minuten bereitgestellt werden.
-
In Schritt S5.5 werden dann ungefähre Bahnhofsknotenpunkte erstellt entsprechend der Abfahrt eines jeden Fahrzeugs von dem betreffenden Bahnhof während des Zeitraums zwischen der Startzeit T1 und der Endzeit T2 des Wiederholungsfahrplandienstes. Es ist leicht nachzuvollziehen, dass diese Knotenpunkte aufgrund der Eigenschaften der Wiederholungsfahrplan-Informationen keine exakte Definition der verschiedenen Abfahrtszeiten der Fahrzeuge von den betreffenden Bahnhöfen bereitstellen. Diese Unsicherheit wird jedoch, wie im Folgenden veranschaulicht, berücksichtigt und im Streckenplanungssystem überwunden. Genauer gesagt werden die Bahnhofsknotenpunkte zu den Zeiten T1, T2 und P und zu nachfolgenden Intervallen ≤ P erstellt. Die resultierenden Bahnhofsknotenpunkte werden dann unter Bezugnahme auf den betroffenen Bahnhof in der Transitgrafikdatenbank gespeichert. Das Wiederholungfahrplan-Bearbeitungsmodul 13 kann zudem Onboard-Knotenpunkte für die Bahnhöfe berechnen, die auch in der Transitgrafikdatenbank gespeichert werden, obwohl dies in der Erklärung für eine bessere Verdeutlichung weggelassen wurde.
-
Es wird verständlich sein, dass die künstlichen Knotenpunkte für den Wiederholungsfahrplan, die durch den in 5 veranschaulichten Prozess erstellt wurden, danach in die vom Transitgrafikmodul 8 berechneten Transfermuster eingearbeitet werden, sodass die Streckeninformationsdatenbank 4 Transfermuster enthält, welche die für den Wiederholungsfahrplan erstellten Knotenpunkte beinhaltet.
-
Diese künstlichen Wiederholungsfahrplan-Knotenpunkte werden auch in den Anfragegrafiken enthalten sein, die zum Zeitpunkt der Anfrage, wie unter Bezugnahme auf 4 beschrieben, erstellt werden.
-
Anfragezeit für Wiederholungsfahrplan
-
Bei Diensten, die gemäß einem Wiederholungsfahrplan ausgeführt werden, gibt es, wenn der Reisende an einem bestimmten Bahnhof ankommt, eine Ungewissheit, wie lange der Reisende auf die Ankunft des nächsten Fahrzeugs warten muss. Es ist leicht nachzuvollziehen, dass der beschriebene Prozess unter Bezugnahme auf 5 künstliche Bahnhofsknotenpunkte erstellt, die möglicherweise nicht die tatsächlichen Zeiten widerspiegeln, zu denen Fahrzeuge an bestimmten Bahnhöfen ankommen und von dort abfahren, was zu einer Ungewissheit hinsichtlich der erforderlichen Wartezeit führt. Im Anfrageprozess, wie in 6 gezeigt, ist eine Wartezeit W gezwungenermaßen nicht geringer als P, um sicherzustellen, dass der schlimmste anzunehmende Fall in der Anfrage ausgeführt wird und zwar, dass der Reisende das letzte Fahrzeug verpasst hat und die volle Wiederholungszeit P warten muss.
-
Wenn daher eine Reise einen Wiederholungsfahrplan ab einem Bahnhof A mit einer Anfangszeit T betrifft, ist die logische Reaktion des Planungssystems:
- (1) Wenn T + P < T1, Abfahrt von A um T1, weil die Wartezeit W = T1 – T größer ist als P.
- (2) Wenn T1 ≤ T + P ≤ T2, Abfahrt von A um T + P, d. h. die Wartezeit P wird auf gleich P gesetzt.
- (3) Wenn T2 < T + P, gibt es keine mögliche Verbindung.
-
Unter Bezugnahme auf 6 wird der beschriebene Prozess zur Anfragezeit unter Bezugnahme auf 4 ausgeführt und außerdem wird, wenn der Dijkstra Algorithmus auf Pfade stößt und durchsucht, einschließlich der Knotenpunkte, die der Ankunftszeit im Bahnhof Sn entsprechen, wo ein Wiederholungsfahrplan involviert ist, eine zusätzliche Methodologie durchgeführt gemäß dem Prozess in 6. Der Prozess beginnt mit Schritt S6.1 und bei Schritt S6.2, wenn der nächste Bogen der Strecke, der im Dijkstra Algorithmus berücksichtigt wird, ein Fahrzeug betrifft, das gemäß einem Wiederholungsfahrplan betrieben wird, werden zusätzliche Maßnahmen durchgeführt, um die Ungewissheit der Wartezeit zu kompensieren, um zu erzwingen, dass die Wartezeit W nicht geringer als der Zeitraum P zwischen aufeinanderfolgenden Fahrzeugen ist.
-
Genauer gesagt, wenn der relevante Bogen für Bahnhof Sn keinen Wiederholungsfahrplan betrifft, wird der Dijkstra-Algorithmus, wie beschrieben, unter Bezugnahme auf 4 fortgesetzt, um ein Streckenplanungsergebnis bei Schritt S6.4, welcher der in Schritt S4.4 gewählten Streckenfahrplanauswahl entspricht, zu erzielen.
-
Wenn der Bogen jedoch einen Wiederholungsfahrplan betrifft, werden die oben beschriebenen Bedingungen (1), (2) und (3) getestet.
-
Daher ist es bei Schritt S 6.5 so, dass die Wartezeit auf einen Zug der Differenz zwischen dem Beginn des Widerholungsfahrplans und der tatsächlichen Ankunftszeit entspricht, wenn der Reisende vor Beginn des Wiederholungsfahrplans zu einer Zeit T1 am Bahnhof ankäme. Diese Wartezeit W wird in die Dijkstra-Algorithmusberechnung, die in Schritt S6.3 vorgenommen wurde, aufgenommen.
-
Wenn jedoch die Ankunftszeit T des Reisenden zwischen der Start- und Endzeit T1, T2 liegt, wird die Wartezeit W mit P gleichgesetzt, sodass der schlimmste anzunehmende Fall, dass der Reisende die volle Wiederholungszeit P warten muss bevor das nächste Fahrzeug kommt, aufgeführt wird. Wieder wird der Wert W dem Suchprozess, der mithilfe des Dijkstra-Algorithmus in Schritt S6.3 durchgeführt wurde, bereitgestellt, um ein geeignetes Modell der Wartezeit im Streckenplanungsprozess sicherzustellen. In Schritt 6.7 besteht, wenn die Ankunftszeit T geringer als der Zeitraum P vor der Endzeit des Wiederholungsfahrplans T2 ist, das Risiko, dass das Fahrzeug zum Transport nicht zur Verfügung steht, und so wird in Schritt 6.8, die Streckenoption für die Berücksichtigung bei der Dijkstra-Algorithmussuche zurückgewiesen und somit von den Streckenplanungsoptionen in der Antwort auf die Anfrage ausgeschlossen.
-
In einer Modifizierung spezifiziert die anwenderdefinierte Anfrage eine Ankunftsstatt einer Startzeit für die Reise. Der oben beschriebene Prozess kann auch für eine solche Anfrage verwendet werden, da die Bedingungen (1), (2) und (3) genauso gut funktionieren, wenn man rückwärts von einer vom Anwender definierten Ankunftszeit in einer Anfrage auf den erstellten Anfragegrafiken, wie in diesem Dokument beschrieben, arbeitet.
-
Viele Modifizierungen und Varianten der Ausführungsformen der hier beschriebenen Erfindung sind innerhalb des Umfangs der folgenden Ansprüche möglich. Außerdem ist die spezielle Benennung der Komponenten, die Großschreibung der Begriffe, Attribute, Datenstrukturen oder von jeglichem anderen Programmierungsaspekt oder strukturellem Aspekt nicht zwingend oder signifikant und die Mechanismen, welche die Erfindung oder seine Funktionen implementieren, können unterschiedliche Namen, Formate oder Protokollierungen haben. Außerdem kann das System mittels einer Kombination aus Hardware und Software, wie beschrieben, oder gänzlich in Hardware-Elementen implementiert sein. Auch ist die hier beschriebene Funktionalitätsaufteilung unter den verschiedenen hier beschriebenen Systemkomponenten nur exemplarisch und nicht obligatorisch; Funktionen, die von einer einzigen Systemkomponente durchgeführt werden, können tatsächlich von mehreren Komponenten durchgeführt werden und von mehreren Komponenten ausgeführte Funktionen können von einer einzelnen Komponenten durchgeführt werden.
-
Einige Teile der obigen Beschreibung präsentieren die Funktionen der gegenwärtigen Erfindung in Form von Algorithmen und symbolischen Darstellungen der Transaktionen mit Informationen. Diese algorithmischen Beschreibungen und Darstellungen sind von Datenverarbeitungsexperten verwendete Mittel, um das Wesentliche ihrer Arbeit anderen Fachleuten auf dem Gebiet zu vermitteln. Es versteht sich, dass diese Operationen trotz ihrer funktionellen und logischen Beschreibung von Computerprogrammen implementiert werden. Darüber hinaus sollte die Bezugnahme auf diese Operationsanordnungen als Module nicht so verstanden werden, dass sie eine strukturelle Beschränkung implizieren und Bezugnahmen auf funktionelle Namen dienen der Veranschaulichung und gehen nicht zu Lasten der Allgemeingültigkeit.
-
Sofern nicht ausdrücklich anders angegeben als die obige Beschreibung zeigt, wird in der gesamten Beschreibung darum gebeten zu verstehen, dass sich Diskussionen mit der Verwendung von Begriffen, wie „bearbeiten” oder „berechnen” oder „kalkulieren” oder „bestimmen” oder „zeigen” o. ä., auf die Tätigkeit und Prozesse eines Computersystems oder einem ähnlichen elektronischen Rechner beziehen, der Daten, die als physische (elektronische) Mengen im Speicher oder Registern oder einem ähnlichen Informationsspeicher, Übertragungs- oder Anzeigegerät des Computersystems dargestellt werden, manipuliert und umwandelt.
-
Bestimmte Aspekte der vorliegenden Erfindung beinhalten Prozessschritte und Anweisungen, die hierin in Form eines Algorithmus beschrieben sind. Es sollte ersichtlich sein, dass die Prozessschritte, die Anweisungen, der gegenwärtigen Erfindung, wie beschrieben und beansprucht, von einer Computer-Hardware, die mit einer Programmsteuerung läuft, ausgeführt werden und nicht mentale Schritte sind, die von einem Menschen ausgeführt werden. Gleichermaßen werden sämtliche beschriebenen und angegebenen Daten in einem computerlesbaren Speichermedium gespeichert, das von einem Computersystem betrieben wird, und sie sind nicht einfach dargestellte, abstrakte Ideen.
-
Die vorliegende Erfindung bezieht sich auch auf ein Gerät, das die hierin genannten Operationen ausführt. Dieses Gerät kann für den benötigten Zweck speziell gebaut oder es kann in einem Allzweck-Computer enthalten sein und selektiv aktiviert oder durch ein auf einem computerlesbaren Medium gespeicherten Computerprogramm rekonfiguriert werden. Dieses Computerprogramm wird in einem computerlesbaren Speichermedium, wie, jedoch nicht beschränkt auf, jegliche Art von Diskette einschließlich Floppy Disks, optische Disketten, CD-ROMs, Magneto-Optical Disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetische oder optische Karten, anwendungsspezifische integrierte Schaltkreise (ASICs) oder jede Art von Medien, die für das Speichern elektronischer Befehle geeignet ist und jeweils an ein Computersystembus gekoppelt werden können, gespeichert. Darüber hinaus können die Computer, auf die in der Spezifikation Bezug genommen wird, einen einzelnen Prozessor enthalten oder es können Architekturen mit multiplen Prozessor-Designs für eine erhöhte Computerleistungsfähigkeit sein.
-
Die hier dargestellten Algorithmen und Aktionen können von Computern oder anderen Geräten jeden Typs oder jeder Marke ausgeführt werden. Verschiedene Allzwecksysteme können auch mit Programmen gemäß den hierin enthaltenen Lehren verwendet werden oder es kann sich als praktikabler erweisen, ein spezialisierteres Gerät für die Durchführung der beschriebenen Verfahrensschritte zu bauen. Die erforderliche Struktur für eine Vielzahl dieser Systeme wird, neben den äquivalenten Varianten, für Fachleute auf dem Gebiet offensichtlich sein. Des Weiteren ist die gegenwärtige Erfindung nicht mit Bezug auf eine bestimmte Programmiersprache beschrieben. Es wird Wert daraufgelegt, dass eine Vielzahl von Programmiersprachen verwendet werden kann, um die Lehren der gegenwärtigen Erfindung, wie hier beschrieben, zu implementieren und jegliche Bezugnahme auf spezifische Sprachen werden als anschauliches Beispiel angegeben.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 2011/0112759 A1 [0005, 0028]
- US 2011/0112759 [0029, 0031]
-
Zitierte Nicht-Patentliteratur
-
- http://code.google.com/transit/spec/transit_feed_specification.html [0020]
