DE202013012418U1 - Reiseplanung im öffentlichen Personenverkehr - Google Patents

Reiseplanung im öffentlichen Personenverkehr Download PDF

Info

Publication number
DE202013012418U1
DE202013012418U1 DE202013012418.0U DE202013012418U DE202013012418U1 DE 202013012418 U1 DE202013012418 U1 DE 202013012418U1 DE 202013012418 U DE202013012418 U DE 202013012418U DE 202013012418 U1 DE202013012418 U1 DE 202013012418U1
Authority
DE
Germany
Prior art keywords
station
transit
time
route
stations
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE202013012418.0U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of DE202013012418U1 publication Critical patent/DE202013012418U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/3407Route searching; Route guidance specially adapted for specific applications
    • G01C21/343Calculating itineraries, i.e. routes leading from a starting point to a series of categorical destinations using a global route restraint, round trips, touristic trips
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/20Instruments for performing navigational calculations
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/3407Route searching; Route guidance specially adapted for specific applications
    • G01C21/3423Multimodal routing, i.e. combining two or more modes of transportation, where the modes can be any of, e.g. driving, walking, cycling, public transport
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/42Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for mass transport vehicles, e.g. buses, trains or aircraft
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Navigation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Train Traffic Observation, Control, And Security (AREA)

Abstract

Computerprogrammprodukt für die Reiseplanung mit öffentlichen Verkehrsmitteln bestehend aus einem Computerlesbarem Speichermedium, das den vom Computer ausführbaren Objektcode speichert, der für Folgendes einsatzfähig ist: Bereitstellen von Transitgrafikdaten mit Knotenpunkten, welche den Bahnhöfen für die Fahrzeuge und die Tageszeiten entsprechen, zu denen die Fahrzeuge an den Bahnhöfen anhalten; Definieren von Knotenpunkten in den Transitgrafikdaten, welche die einzelnen Tageszeiten, an denen die Fahrzeuge am ersten der Bahnhöfe gemäß dem Wiederholungsfahrplan, in dem aufeinanderfolgende Fahrzeugfahrten ab dem ersten Bahnhof durch einen allen gemeinsamen Zeitraum (P) getrennt sind, anhalten würden, wobei die simulierten einzelnen Tageszeiten für die entsprechenden Knotenpunkte des Wiederholungsfahrplans aufeinanderfolgend durch einen Zeitraum, der geringer ist als oder gleich dem allen gemeinsamen Zeitraum (P) ist, getrennt sind; Durchführen einer Anfrageberechnung hinsichtlich der Transitgrafikdaten, um einen Reiseplan für eine Strecke zwischen einem avisierten und einem Zielbahnhof zu bestimmen; und wenn die Strecke durch den ersten Bahnhof verläuft und eine Fahrt gemäß einem Wiederholungsfahrplan betrifft, Definieren für die Strecke, dass die Reisezeit einen Wartezeitraum am ersten Bahnhof beinhaltet, der nicht geringer ist als der allen gemeinsame Zeitraum (P).

Description

  • 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]

Claims (13)

  1. Computerprogrammprodukt für die Reiseplanung mit öffentlichen Verkehrsmitteln bestehend aus einem Computerlesbarem Speichermedium, das den vom Computer ausführbaren Objektcode speichert, der für Folgendes einsatzfähig ist: Bereitstellen von Transitgrafikdaten mit Knotenpunkten, welche den Bahnhöfen für die Fahrzeuge und die Tageszeiten entsprechen, zu denen die Fahrzeuge an den Bahnhöfen anhalten; Definieren von Knotenpunkten in den Transitgrafikdaten, welche die einzelnen Tageszeiten, an denen die Fahrzeuge am ersten der Bahnhöfe gemäß dem Wiederholungsfahrplan, in dem aufeinanderfolgende Fahrzeugfahrten ab dem ersten Bahnhof durch einen allen gemeinsamen Zeitraum (P) getrennt sind, anhalten würden, wobei die simulierten einzelnen Tageszeiten für die entsprechenden Knotenpunkte des Wiederholungsfahrplans aufeinanderfolgend durch einen Zeitraum, der geringer ist als oder gleich dem allen gemeinsamen Zeitraum (P) ist, getrennt sind; Durchführen einer Anfrageberechnung hinsichtlich der Transitgrafikdaten, um einen Reiseplan für eine Strecke zwischen einem avisierten und einem Zielbahnhof zu bestimmen; und wenn die Strecke durch den ersten Bahnhof verläuft und eine Fahrt gemäß einem Wiederholungsfahrplan betrifft, Definieren für die Strecke, dass die Reisezeit einen Wartezeitraum am ersten Bahnhof beinhaltet, der nicht geringer ist als der allen gemeinsame Zeitraum (P).
  2. Computerprogrammprodukt nach Anspruch 1, worin: der Wiederholungsfahrplan am ersten Bahnhof ab der Tagesstartzeit (T1) bis zu einer Tagesendzeit (T2) geht und wenn die Ankunftszeit (T) am ersten Bahnhof laut Vorhersage vor der Startzeit (T1) des Wiederholungsfahrplans um mehr als den besagten allen gemeinsamen Zeitraum (P) liegt und der Code einsatzfähig ist, Festlegen der Wartezeit (W) am ersten Bahnhof auf nicht weniger als die Differenz zwischen der Ankunftszeit (T) und der Startzeit (T1).
  3. Computerprogrammprodukt nach Anspruch 2, worin der Code einsatzfähig ist, um die Strecke als undurchführbar zu definieren, wenn die Ankunftszeit (T) am ersten Bahnhof laut Vorhersage nach der Zeit, die der Endzeit (T2) abzüglich des gemeinsamen Zeitraums (P) des Wiederholungsfahrplans entspricht, liegt.
  4. Computerprogrammprodukt nach Anspruch 1, welches die Einsatzfähigkeit beinhaltet, eine Vorausberechnung für eine Vielzahl an in den Transitgrafikdaten dargestellten Bahnhofspaaren durchzuführen, um mindestens ein Transfermuster, das zumindest einer durchführbaren Strecke zwischen zwei entsprechenden Bahnhofspaaren entspricht, anzubieten, wobei mindestens ein Transfermuster für das Bahnhofspaar gespeichert wird und eine Anfrageberechnung auf den gespeicherten Transfermustern durchgeführt wird, um den Reiseplan für eine Strecke zwischen dem avisierten Bahnhof und dem Zielbahnhof zu bestimmen.
  5. System für die Reiseplanung mit öffentlichen Verkehrsmitteln bestehend aus: einem Speicher, der so konfiguriert ist, dass er Transitgrafikdaten mit Bahnhöfen entsprechenden Knotenpunkten für Fahrzeuge und den Tageszeiten, an denen die Fahrzeuge an den Bahnhöfen anhalten, speichert; einer Prozessorkonfiguration, um Knotenpunkte in den Transitgrafikdaten zu erstellen, welche die einzelnen Tageszeiten simulieren, an denen die Fahrzeuge am ersten der Bahnhöfe gemäß dem Wiederholungsfahrplan, in dem aufeinanderfolgende Fahrzeugfahrten ab dem ersten Bahnhof durch einen gemeinsamen Zeitraum (P) getrennt sind, anhalten würden, wobei die simulierten einzelnen Tageszeiten für die entsprechenden Knotenpunkte des Wiederholungsfahrplans aufeinanderfolgend durch einen Zeitraum, der geringer ist als oder gleich dem allen gemeinsamen Zeitraum (P) ist, getrennt sind; Die Prozessorkonfiguration ist darüber hinaus einsatzfähig, um eine Anfrageberechnung in Bezug auf Transitgrafikdaten durchzuführen, für eine Strecke zwischen dem avisierten und dem Zielbahnhof und wenn die Strecke durch den ersten Bahnhof verläuft und eine Reise gemäß einem Wiederholungsfahrplan betrifft, der Strecke zu definieren, sodass ein Wartezeitraum für den ersten Bahnhof enthalten ist, der nicht geringer als der gemeinsame Zeitraum (P) ist.
  6. System nach Anspruch 5 mit einem Frontend-Interface, das mit einem Netzwerk zu verbinden ist, um es Anwendern zu ermöglichen, die Streckenplanung über das Netzwerk vorzunehmen.
  7. System nach Anspruch 5, welches ein Interface beinhaltet, um Fahrzeugfahrplandaten für die Verwendung in der Transitgrafikinformation zu erhalten.
  8. System nach Anspruch 5, welches eine Prozessorkonfiguration beinhaltet, die einsatzfähig ist, die Fahrplandaten für die Bereitstellung an die Transitgrafikinformation zu verarbeiten.
  9. System nach Anspruch 8, welche eine Transitinformationsdatenbank beinhaltet, um die Transitgrafikinformation zu speichern.
  10. System nach Anspruch 8, worin die Prozessorkonfiguration einsatzfähig ist, eine Suche auf der Transitgrafikinformation vorzunehmen, um mindestens ein Transfermuster, das mindestens einer durchführbaren Strecke zwischen entsprechenden Bahnhofspaaren entspricht, zu bieten und mindestens ein Transfermuster für die Bahnhofspaare zu speichern.
  11. System nach Anspruch 10, worin die Prozessorkonfiguration einsatzfähig ist, die Transitgrafikinformation zu verarbeiten, um eine Anfrageberechnung an den gespeicherten Transfermustern durchzuführen, um einen Reiseplan zwischen dem avisierten und dem Zielbahnhof zu bestimmen.
  12. System nach Anspruch 5, worin: der Wiederholungsfahrplan am ersten Bahnhof ab der Tagesstartzeit (T1) bis zu einer Tagesendzeit (T2) geht, und wenn die Ankunftszeit (T) am ersten Bahnhof laut Vorhersage vor der Startzeit (T1) des Wiederholungsfahrplans um mehr als den besagten gemeinsamen Zeitraum (P) liegt, die Prozessorkonfiguration einsatzfähig ist, um die Wartezeit (W) am ersten Bahnhof auf nicht weniger als die Differenz zwischen der Ankunftszeit (T) und der Startzeit (T1) festzulegen.
  13. System nach Anspruch 12, worin die Prozessorkonfiguration einsatzfähig ist, eine Strecke als undurchführbar zurückzuweisen, wenn die Ankunftszeit (T) am ersten Bahnhof als nach der Zeit vorhergesagt wird, die der Tagesendzeit (T2) minus des gemeinsamen Zeitraums (P) des Wiederholungszeitplans entspricht.
DE202013012418.0U 2012-05-09 2013-04-30 Reiseplanung im öffentlichen Personenverkehr Expired - Lifetime DE202013012418U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/467,361 US9097535B2 (en) 2012-05-09 2012-05-09 Public transportation journey planning
US13/467,361 2012-05-09

Publications (1)

Publication Number Publication Date
DE202013012418U1 true DE202013012418U1 (de) 2016-10-20

Family

ID=49549304

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202013012418.0U Expired - Lifetime DE202013012418U1 (de) 2012-05-09 2013-04-30 Reiseplanung im öffentlichen Personenverkehr

Country Status (4)

Country Link
US (1) US9097535B2 (de)
EP (1) EP2847546B1 (de)
DE (1) DE202013012418U1 (de)
WO (1) WO2013169522A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021144699A1 (de) * 2020-01-14 2021-07-22 Dietl, Norbert System zur optimierten liniennetznutzung im öffentlichen personennahverkehr und verfahren hierzu

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9159238B2 (en) * 2008-10-02 2015-10-13 Microsoft Technology Licensing, LLP Location-aware selection of public transportation
US10546307B2 (en) * 2013-09-25 2020-01-28 International Business Machines Corporation Method, apparatuses, and computer program products for automatically detecting levels of user dissatisfaction with transportation routes
US11158010B2 (en) 2015-08-31 2021-10-26 International Business Machines Corporation Incremental search based multi-modal journey planning
CN107403231A (zh) * 2016-05-20 2017-11-28 高德软件有限公司 一种获取用于定位线路规划缺陷的数据的方法及装置
KR101896993B1 (ko) * 2016-06-08 2018-09-11 아주대학교산학협력단 이동체의 경로 결정 방법 및 장치
CN108627165A (zh) * 2017-03-23 2018-10-09 刘海强 实现最优导航的方法
CN107644270B (zh) * 2017-09-19 2021-06-25 广州唯品会研究院有限公司 无人配送的路径规划方法、装置和计算机可读存储介质
CN107886189B (zh) * 2017-10-19 2021-06-15 东南大学 一种基于地铁刷卡数据进行路径旅行时间推断的方法
US11519741B2 (en) * 2017-12-14 2022-12-06 Sony Corporation Information processing device, information processing method, and mobile unit
KR101974109B1 (ko) * 2017-12-21 2019-04-30 그제고스 말레비치 출발지 위치로부터 목적지 위치로의 여정에 대한 루트 또는 루트 소요 시간을 제공하기 위한 방법 및 컴퓨터 시스템
US10349211B1 (en) * 2018-06-30 2019-07-09 AVAST Software s.r.o. Mobile location security system
JP7263119B2 (ja) * 2019-05-22 2023-04-24 村田機械株式会社 走行決定方法、コントローラ、及び当該コントローラを備える走行システム
EP3745329A1 (de) * 2019-05-29 2020-12-02 Naver Corporation Verfahren zur vorverarbeitung eines satzes von durchführbaren transfers zur berechnung von routen in einem multimodalen transportnetzwerk
CN112085340B (zh) * 2020-08-14 2024-04-02 广州思创科技股份有限公司 一种公交调度方法、系统、装置及存储介质
CN112700029B (zh) * 2020-12-03 2024-06-11 北京交通大学 一种基于仿真优化框架的定制公交规划方法
CN112861025B (zh) * 2021-02-05 2024-03-15 北京百度网讯科技有限公司 一种公交线路规划方法、装置、电子设备及存储介质
CN115909722A (zh) * 2022-10-27 2023-04-04 东风悦享科技有限公司 一种应用于智能公交的路阻调度方法及系统
CN115860298A (zh) * 2022-12-05 2023-03-28 四川警察学院 公交中间站停靠线路优化方法、装置、设备及存储介质
CN117191067B (zh) * 2023-11-07 2024-02-06 杭州一喂智能科技有限公司 出行路线规划方法、装置、电子设备和计算机可读介质
CN117334072B (zh) * 2023-12-01 2024-02-23 青岛城运数字科技有限公司 公交车辆到站时刻预测方法和装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110112759A1 (en) 2009-11-11 2011-05-12 Google Inc. Transit routing system for public transportation trip planning

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7957871B1 (en) 2005-09-29 2011-06-07 Hopstop.com, Inc. Methods and apparatuses for navigation in urban environments
US8612071B2 (en) * 2009-10-23 2013-12-17 Integrated Transportation Technologies, L.L.C. Synchronized express and local trains for urban commuter rail systems
US20120239289A1 (en) 2010-09-09 2012-09-20 Google Inc. Transportation Information Systems and Methods Associated With Generating Multiple User Routes

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110112759A1 (en) 2009-11-11 2011-05-12 Google Inc. Transit routing system for public transportation trip planning

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
http://code.google.com/transit/spec/transit_feed_specification.html

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021144699A1 (de) * 2020-01-14 2021-07-22 Dietl, Norbert System zur optimierten liniennetznutzung im öffentlichen personennahverkehr und verfahren hierzu

Also Published As

Publication number Publication date
WO2013169522A2 (en) 2013-11-14
EP2847546A4 (de) 2016-01-27
US20130304378A1 (en) 2013-11-14
US9097535B2 (en) 2015-08-04
WO2013169522A3 (en) 2014-01-03
EP2847546B1 (de) 2019-09-25
EP2847546A2 (de) 2015-03-18

Similar Documents

Publication Publication Date Title
DE202013012418U1 (de) Reiseplanung im öffentlichen Personenverkehr
DE202010018460U1 (de) Transit-Routingsystem zur Fahrtenplanung mit öffentlichen Verkehrsmitteln
DE202020005743U1 (de) Verbessertes Logistikmanagementsystem
DE102016107723A1 (de) Nutzerweg-Störungen beim Ridesharing und Nutzerrouten-Neuplanung
DE102015109660A1 (de) Verfahren und System für On-Demand-Transportdienste
DE102018106364A1 (de) Multimodale transportplanung und -disponierung
DE102016107185A1 (de) Gemeinsame Nutzung von langfristigen Fahrgemeinschaftsgruppen
DE102018129072A1 (de) Systeme und verfahren zum dynamischen verwalten einer shuttleflotte
DE202015009162U1 (de) Erkennung wichtiger Haltestellen für die Gruppierung von Fahrten
DE102015208287A1 (de) Gemeinschaftsfahrzeugsysteme und -verfahren
DE102010042813A1 (de) Verfahren und Vorrichtung zur Tourenplanung
EP2487462B1 (de) Automatische Unterstützung der Routenplanung
DE102014104361A1 (de) Ermitteln von Emissionswerten
WO2017134299A1 (de) Verfahren zum transportieren einer vielzahl von objekten zwischen objektspezifischen orten
DE102012215447A1 (de) Zentralisierte Routenbestimmung
EP3163520A9 (de) Koordination einer leistungserbringung
DE102017212334A1 (de) Transportsystem und verfahren zur zuordnung von frequenzen von transitservices darin
DE102017204783A1 (de) Verfahren zum Fernsteuern von mehreren führerlosen Selbstfahrsystemen sowie Leitstand zum Fernsteuern der Selbstfahrsysteme und System
DE102019126370A1 (de) Mitfahrgelegenheit mit berücksichtigung besonderer bedürfnisse
WO2005088493A1 (de) Verfahren und systeme zur optimierung von beförderungsaufgaben
DE102018009790A1 (de) Verfahren zur dynamischen Routenplanung
WO2021190792A1 (de) Verfahren zum überprüfen einer beförderungsfahrt eines nutzers mit einem autonom fahrenden fahrzeug, sowie elektronisches verwaltungssystem
DE102018214681A1 (de) Verfahren, Vorrichtung und computerlesbares Speichermedium mit Instruktionen zur Routenermittlung für ein automatisch fahrendes Servicemobil
AT522734B1 (de) Verfahren zur Ermittlung eines Bewegungsprofils einer Person
Horn Airports and territory: emergence of a new strategic actor in the air transport system

Legal Events

Date Code Title Description
R207 Utility model specification
R150 Utility model maintained after payment of first maintenance fee after three years
R081 Change of applicant/patentee

Owner name: GOOGLE LLC (N.D.GES.D. STAATES DELAWARE), MOUN, US

Free format text: FORMER OWNER: GOOGLE INC., MOUNTAIN VIEW, CALIF., US

R082 Change of representative

Representative=s name: BETTEN & RESCH PATENT- UND RECHTSANWAELTE PART, DE

R151 Utility model maintained after payment of second maintenance fee after six years
R152 Utility model maintained after payment of third maintenance fee after eight years
R071 Expiry of right