DE60215901T2

DE60215901T2 - Mehrere Sprachen und Formate unterstützendes Navigationssystem

Info

Publication number: DE60215901T2
Application number: DE60215901T
Authority: DE
Inventors: Jeffrey E. Painter
Original assignee: Navteq North America LLC
Current assignee: Here North America LLC
Priority date: 2001-10-03
Filing date: 2002-10-03
Publication date: 2007-05-31
Anticipated expiration: 2022-10-04
Also published as: EP1300655B1; JP2003222524A; EP1300655A3; DE60215901D1; JP4243469B2; US6989770B1; ATE344918T1; EP1300655A2

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Navigationssystem, und im Besonderen betrifft die vorliegende Erfindung ein Navigationssystem, das einen zentralen Server umfasst, der sprach- und formatunabhängige navigationsbezogene Informationen einem Server oder mehreren Servern bereitstellt, die wiederum die sprach- und formatunabhängigen navigationsbezogenen Informationen verwenden, um spezifische Navigationsanweisungen zu formulieren, die Endanwendern bereitgestellt werden.
Navigationssysteme bieten verschiedene nützliche Funktionen, wie beispielsweise das Berechnen von Strecken zu den gewünschten Zielorten, das Bereitstellen einer Führung entlang der berechneten Strecken, das Anzeigen von Karten und so weiter. Es gibt verschiedene Computerarchitekturen für Navigationssysteme, die navigationsbezogene Leistungsmerkmale bereitstellen. Bei einem Architekturtyp für ein Navigationssystem nutzen Endanwender elektronische Vorrichtungen, um Navigationsinformationen von einem dezentralen Server zu erhalten. Die elektronischen Vorrichtungen von Endanwendern können Universalvorrichtungen, wie beispielsweise Mobiltelefone, persönliche digitale Assistenten (PDAs [Personal Digital Assistants]), Personalcomputer (Desktopcomputer und tragbare Computer), sowie Spezialvorrichtungen, wie beispielsweise speziell entwickelte Navigationssystemeinheiten, umfassen. Die Vorrichtungen von Endanwendern werden verwendet, um Anforderungen für navigationsbezogene Informationen über ein Kommunikationsnetz zu einem dezentralen Server zu senden. Das Kommunikationsnetz kann das Internet oder jegliche andere Arten von Kommunikationsmedien umfassen. Wenn der dezentrale Server eine Anforderung für Navigationsinformationen von einer Endanwendervorrichtung empfängt, nutzt er Navigationsanwendungssoftwareprogramme sowie geografische Daten, die in einer oder in mehreren Datenbanken enthalten sind, um eine Antwort auf die Anforderung zu bestimmen, und sendet anschließend die Antwort über das Kommunikationsmedium zu dem Endanwender. Ein Beispiel dieses Typs von Navigationssystem wird in dem US-Patent mit der Nummer 5.543.789 offenbart.
Dieser Typ einer Navigationssystemarchitektur bietet mehrere Vorteile. Ein Vorteil betrifft das Bereitstellen von aktualisierten geografischen Daten. Es besteht die Notwendigkeit des kontinuierlichen Aktualisierens der geografischen Daten, die von einem Navigationssystem verwendet werden. Wenn beispielsweise neue Straßen gebaut werden, durch den Straßenbau Straßen gesperrt werden, Umleitungen eingerichtet werden, neue Geschäfte eröffnet werden, aufgestellte Geschwindigkeitsbeschränkungen geändert werden, neue Abbiegeverbote an Straßenkreuzungen aufgestellt werden, Straßen umbenannt werden und so weiter. Diese Arten von Änderungen können die Fahrt durch eine geografische Region beeinflussen. Demzufolge sollten die von einem Navigationssystem genutzten geografischen Daten regelmäßig aktualisiert werden, um Änderungen der dargestellten geografischen Besonderheiten genau widerzuspiegeln. Eine Computerarchitektur, bei der Endanwender navigationsbezogene Dienste von einem einzigen zentralen Server erhalten, bietet einen Vorteil hinsichtlich der Aktualisierung geografischer Daten. Bei einer Computerarchitektur, bei der Endanwender navigationsbezogene Dienste von einem zentralen Server erhalten, müssen Aktualisierungen lediglich an der geografischen Datenbank oder den geografischen Datenbanken, die mit dem zentralen Server verbunden ist oder sind, durchgeführt werden.
Obwohl eine Navigationssystemarchitektur, bei der Endanwender Navigationsdienste von einem zentralen Rechner erhalten, Vorteile aufweist, gibt es Aspekte, auf die eingegangen werden muss. Ein Aspekt betrifft das Bereitstellen von navigationsbezogenen Informationen in einer Vielzahl von unterschiedlichen Sprachen. Beispielsweise könnten einige Endanwender wünschen, dass die Navigationsinformationen in Englisch bereitgestellt werden, während andere Endanwender wünschen könnten, dass die Navigationsinformationen in Französisch, Spanisch oder in anderen Sprachen bereitgestellt werden. Das Dokument US-A-5 808 566 beschreibt ein Navigationssystem zum Bereitstellen von Streckeninformationen, wobei ein Endanwender eine Anforderung für eine Streckenführung unter Verwendung einer elektronischen Vorrichtung von Endanwendern formuliert, die elektronische Vorrichtung von Endanwendern die Anforderung über ein Datennetz zu einem Navigationsserver sendet, der Navigationsserver zunächst eine Reihe von Manövern zum Bewegen entlang einer Strecke, die in Reaktion auf die Anforderung berechnet wurde, bestimmt, der Navigationsserver anschließend eine entsprechende Antwortnachricht in einem sprachunabhängigen Format (Token) erzeugt und es zu der elektronischen Vorrichtung von Endanwendern sendet, und die elektroni sche Vorrichtung von Endanwendern die Token der Antwortnachricht in die Sprache des Endanwenders umsetzt. Ein weiterer Aspekt betrifft das Bereitstellen von navigationsbezogenen Informationen für eine Vielzahl von Formaten. Beispielsweise können einige Endanwender Systeme besitzen, die grafische Bilder von Karten unterstützen, welche die navigationsbezogenen Informationen illustrieren, während andere Endanwender Systeme besitzen können, die lediglich Textanweisungen unterstützen. Es wäre zu bevorzugen, dass ein Navigationsserver mehrere unterschiedliche Sprachen und mehrere unterschiedliche Typen von Endanwendersystemen unterstützt. Dies zu bewerkstelligen, kann sich jedoch aufgrund der relativ großen Anzahl von verschiedenen Typen von Endanwendersystemen sowie aufgrund der Anzahl von unterschiedlichen Sprachen als schwierig erweisen. Aus diesem Grund besteht die Notwendigkeit einer Verbesserung, welche die Bereitstellung von navigationsbezogenen Informationen zu verschiedenen Typen von Computerplattformen von Endanwendern und in unterschiedlichen Sprachen vereinfacht.
ZUSAMMENFASSUNG DER ERFINDUNG
Um diese und weitere Ziele zu erreichen, umfasst die vorliegende Erfindung ein System und ein Verfahren, das einen Server für navigationsbezogene Informationen umfasst, der navigationsbezogene Informationen in einem sprach- und formatunabhängigen Format bereitstellt. Der Server für navigationsbezogene Informationen antwortet auf Anforderungen für navigationsbezogene Informationen von einem oder von mehreren Kunden-Interface-Servern. Jeder Kunden-Interface-Server empfängt Anforderungen für navigationsbezogene Informationen von Endanwendern, die Computerplattformen von Endanwendern besitzen. Die Endanwender senden ihre Anforderungen für navigationsbezogene Informationen von Computerplattformen von Endanwendern über ein Datennetz zu Kunden-Interface-Servern. Um auf die Anforderungen der Endanwender zu antworten, fordern die Kunden-Interface-Server sprach- und formatunabhängige navigationsbezogene Informationen von dem Server für navigationsbezogene Informationen an. Der Server für navigationsbezogene Informationen empfängt die Anforderungen von den Kunden-Interface-Servern. Um auf jede Anforderung für navigationsbezogene Informationen zu antworten, nutzt der Server für navigationsbezogene Informationen eine oder mehrere geografische Datenbanken, um sprach- und formatunabhängige Datenstrukturen zu formulieren. Diese sprach- und formatunabhängigen Datenstrukturen wer den zu den Kunden-Interface-Servern gesendet. Die Kunden-Interface-Server empfangen sprach- und formatunabhängige Antworten von dem Server für navigationsbezogene Informationen und formulieren sprach- und formatspezifische Antworten, die zu den Endanwendern gesendet werden.
In einem Ausführungsbeispiel sind die sprach- und formatunabhängigen Datenstrukturen, die von dem Server für navigationsbezogene Informationen bereitgestellt werden, im XML-Format. Die Kunden-Interface-Server verwenden XML-Vorlagen, um sprach- und formatspezifische Antworten zu formulieren, die an die Endanwender gesendet werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm, das die Komponenten eines Ausführungsbeispiels eines Navigationssystems illustriert, das Navigationsdienste für Computervorrichtungen von Endanwendern bereitstellt, die in einer geografischen Region angeordnet sind.
2 ist ein Blockdiagramm, das Komponenten des Providers für navigationsbezogene Informationen und des Kunden-Interface-Providers von 1 zeigt.
3 ist ein Blockdiagramm, das Komponenten der Navigationsanwendungen zeigt, die auf dem Server für navigationsbezogene Informationen der 1 und 2 installiert sind.
4 ist ein Diagramm, das die Komponenten des Streckenberechnungsobjektes von 3 illustriert.
5 ist ein Diagramm, das die Komponenten der Manövererzeugungsanwendung von 3 darstellt.
6 ist ein Diagramm, das die Komponentenelemente von einer der Manöverdatenstrukturen von 5 illustriert.
AUSFÜHRLICHE BESCHREIBUNG DER GEGENWÄRTIG BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
I. ÜBERBLICK ÜBER DAS NAVIGATIONSSYSTEM
1 stellt eine geografische Region 100 dar. Die geografische Region 100 kann sich auf ein Großstadtgebiet oder ein ländliches Gebiet, einen Bundesstaat, ein Land oder Kombinationen davon, oder auf andere Gebiete vergleichbarer Größe beziehen. In der geografischen Region 100 befindet sich ein Straßennetz 104.
Ein Navigationssystem 110 dient Endanwendern (zum Beispiel Fahrzeugführern und Mitfahrern sowie anderen Personen und Unternehmen) in der geografischen Region 100. Das Navigationssystem 110 wird von den Endanwendern verwendet, um navigationsbezogene Dienste zu erhalten. Die navigationsbezogenen Dienste umfassen Informationen bezüglich des Bewegens entlang eines Straßennetzes 104, einschließlich Streckenberechnung und -führung. Die navigationsbezogenen Dienste können darüber hinaus Personen- und Branchensuchdienste (zum Beispiel die elektronischen Branchen- und Telefonbücher), die Kartenanzeige, die Suche nach dem Ort, der von Interesse ist (POI [Point of Interest]), die Auswahl des Zielortes und so weiter, umfassen.
Das Navigationssystem 110 ist eine Kombination aus Hardware, Software und Daten. Das Navigationssystem 110 umfasst dezentrale Komponenten, das heißt, Hardware, Software oder Daten, die sich entfernt von den Endanwendern befinden, und lokale Komponenten, das heißt, Hardware und/oder Software, die sich physisch bei jedem Endanwender befinden.
Die lokalen Komponenten des Navigationssystems 110 umfassen die verschiedenen elektronischen Vorrichtungen und Computerplattformen 130, die von den Endanwendern bedient werden, um navigationsbezogene Dienste mit Hilfe des Navigationssystems 110 anzufordern und zu erhalten. Diese verschiedenen Computerplattformen von Endanwendern (auch als "elektronische Vorrichtungen von Endanwendern" oder "Client-Computerplattformen" oder Ähnliches bezeichnet) können Universalvorrichtungen, wie beispielsweise Mobiltelefone, persönliche digitale Assistenten (PDAs, Vorrichtungen vom Typ PalmPilot^®), Personalcomputer (Desktopcomputer und tragbare Computer), sowie Spezialvorrichtungen, wie beispielsweise speziell entwickelte Navigationssystemeinheiten, die sich in den Fahrzeugen 134 befinden, umfassen.
Die Endanwendervorrichtungen 130 verfügen über die geeignete Hardware und Software, um Daten über ein Datennetz 140 zu senden und zu empfangen. Das Datennetz kann jegliche geeignete Technologie und/oder Protokolle verwenden, die derzeit erhältlich sind, sowie Technologie und/oder Protokolle, die in Zukunft erhältlich sein werden. Beispielsweise kann das Datennetz 140 WAP, TCP/IP, i-mode und so weiter verwenden. Es kann mehr als ein Protokoll in dem Datennetz 140 mit geeigneten Umwandlungen verwendet werden. Das Datennetz 140 kann das Internet umfassen.
Das Datennetz 140 kann einen drahtlosen Abschnitt 142 umfassen. Der drahtlose Abschnitt 142 kann durch jegliche geeignete Form drahtloser Kommunikation implementiert werden, die Mobilfunk, PCS, Satellit, FM, Funk oder Technologien, die in Zukunft entwickelt werden können, umfassen. Der drahtlose Abschnitt 142 kann zwei oder mehrere Sender 144, wie beispielsweise einen Transponderturm, einen Funkturm, einen FM-Turm, Satelliten oder weitere geeignete Einrichtungen, umfassen. Die Sender 144 umfassen eine geeignete Kommunikationsverbindung 146 zu dem Netz 140. Diese Verbindung 146 kann kabelbasiert oder drahtlos sein. Die Sender 144 umfassen geeignete Technologie, die eine Zweiwegekommunikation mit den mobilen Computerplattformen 130 von Endanwendern ermöglicht.
II. DER SERVER FÜR NAVIGATIONSBEZOGENE INFORMATIONEN UND DER KUNDEN-INTERFACE-SERVER
Die dezentralen Komponenten des Navigationssystems 110 umfassen einen Server 200 für navigationsbezogene Informationen sowie einen oder mehrere Kunden-Interface-Server 202(1), 202(2).... 2 ist ein Blockdiagramm, das einige der Komponenten des Servers 200 für navigationsbezogene Informationen und einen der Kunden-Interface-Server 202(1) darstellt. (Der Kunden-Interface-Server 202(1) ist für alle anderen Kunden-Interface-Server, die über ähnliche oder identische Komponenten verfügen, repräsentativ.)
A. Der Kunden-Interface-Server 202(1)
Der Kunden-Interface-Server 202(1) wird von einem Kunden-Interface-Provider 220 verwaltet und betrieben.
Der Kunden-Interface-Server 202 umfasst ein Kommunikationssystem 222. Das Kommunikationssystem 222 ist mit dem Datennetz 140 verbunden. Das Kommunikationssystem 222 verfügt über die geeignete Hardware und Software, um Nachrichten über das Datennetz 140 von elektronischen Vorrichtungen 130 von Endanwendern zu empfangen und Nachrichten an diese zu senden. Das Kommunikationssystem 222 ist darüber hinaus in der Lage, Nachrichten von dem Server 200 für navigationsbezogene Informationen zu empfangen sowie Nachrichten an diesen zu senden. In einem Ausführungsbeispiel ist das Netz, das von dem Kunden-Interface-Server 202(1) verwendet wird, um mit dem Server 200 für navigationsbezogene Informationen zu kommunizieren, das gleiche Datennetz (das heißt, das Netz 140), das verwendet wird, um mit den elektronischen Vorrichtungen 130 von Endanwendern zu kommunizieren.
Auf dem Kunden-Interface-Server 202(1) sind Kunden-Interface-Anwendungen 230 enthalten. Eine der Kunden-Interface-Anwendungen 230 ist eine Abonnentendienste-Anwendung 234. Um einige oder alle der von dem Kunden-Interface-Provider 220 angebotenen Dienste zu nutzen, kann es erforderlich sein, dass Endanwender Abonnenten sind. Die Abonnentendienste-Anwendung 234 stellt Dienste bereit, die diese Funktion unterstützen. Einige der Abonnentendienste umfassen eine Registrierung, Zahlungen, Verlängerungen, eine Bestätigung des Abonnentenstatus, gezielte Werbung und so weiter. Die Abonnentendienste-Anwendung 234 kann eine Abonnentendatenbank 235 nutzen, die verschiedene Arten von Informationen enthält, die die verschiedenen Abonnenten betreffen.
Unter den Kunden-Interface-Anwendungen 230, die auf dem Kunden-Interface-Server 202(1) installiert sind, befinden sich auch Datenkonvertierungsanwendungen 240. Die Datenkonvertierungsanwendungen 240 empfangen die Nachrichten, die navigationsbezogene Dienste anfordern, von den Endanwendervorrichtungen 130, extrahieren sachdienlichen Inhalt bezüglich des Typs navigationsbezogener Informationen, die von dem Endanwender gewünscht sind, und formulieren Anforderungen, die zu dem Server 200 für navigationsbezogene Informationen gesendet werden, für navigationsbezogene Da ten, die benötigt werden, um auf die Anforderungen des Endanwenders zu antworten. Die Datenkonvertierungsanwendungen 240 empfangen ebenfalls Datennachrichten, die navigationsbezogene Daten enthalten, von dem Server 200 für navigationsbezogene Informationen, extrahieren die navigationsbezogenen Informationen aus den von dem Server 200 für navigationsbezogene Informationen empfangenen Nachrichten, formulieren sinnvolle sprach- und formatspezifische Navigationsführungs- oder andere Informationen für die Endanwender, und senden sinnvolle sprach- und formatspezifische Führungs- oder andere Informationen zu den Computerplattformen 130 von Endanwendern. Die Datenkonvertierungsanwendungen 240 weiter unten ausführlicher beschrieben.
B. Server für navigationsbezogene Informationen
Der Server 200 für navigationsbezogene Informationen wird von einem Provider 260 für navigationsbezogene Informationen verwaltet und betrieben.
Der Server 200 für navigationsbezogene Informationen umfasst ein Kommunikationssystem 266. Das Kommunikationssystems 266 ist mit dem Datennetz 140 verbunden. Das mit dem Server 200 für navigationsbezogene Informationen verbundene Kommunikationssystem 266 verfügt über die geeignete Hardware und Software, um Nachrichten von dem Kunden-Interface-Server 202(1) sowie von den anderen Kunden-Interface-Servern 202(2)... über ein Datennetz zu empfangen und Nachrichten zu diesen zu senden, wobei das Datennetz in einem Ausführungsbeispiel das Datennetz 140 ist.
Mit dem Server 200 für navigationsbezogene Informationen sind eine oder mehrere geografische Datenbanken 270 verbunden. Die geografischen Datenbanken 270 sind auf einem Medium gespeichert, das sich bei dem Navigationsdienste-Server 200 befinden kann. Es können unterschiedliche Speichermedien verwendet werden, wie Festplatten, DVD-Platten oder andere derzeit erhältliche Speichermedien sowie Speichermedien, die in Zukunft entwickelt werden können.
Die geografischen Datenbanken 270 enthalten Informationen über Straßen und Straßenkreuzungen in oder in Bezug auf eine oder mehrere geografische Regionen oder Abdeckungsgebiete (wie beispielsweise die geografische Region 100 in 1). Diese Informationen enthalten Daten, die die Positionen der Straßen in der abgedeckten geo grafischen Region spezifizieren und darüber hinaus enthalten sie Daten über Merkmale in Bezug auf die Straßen, wie beispielsweise Fahrtrichtungsbeschränkungen auf den Straßen (zum Beispiel Einbahnstraßen), Abbiegeverbote, Straßen und Hausnummern, Straßennamen, Geschwindigkeitsbeschränkungen und so weiter. Die geografischen Datenbanken 270 können ebenso Informationen über interessante Orte (POI) in der geografischen Region, wie beispielsweise Hotels, Restaurants, Museen, Stadien, Behörden, Automobilhändler, Autoreparaturwerkstätten und so weiter, enthalten. Die geografischen Datenbanken 270 können darüber hinaus Informationen über Orte, wie beispielsweise über Großstädte, Kleinstädte oder andere Gemeinden enthalten. Die geografische Datenbank 270 kann ebenfalls weitere Daten über die geografische Region enthalten.
In einem Ausführungsbeispiel werden die geografischen Datenbanken 270 und die darin enthaltenen Daten von der Navigation Technologies Corporation of Chicago, Illinois, bereitgestellt. Es ist jedoch darauf hingewiesen, dass Datenbanken, die von anderen Unternehmen entwickelt und angeboten werden, ebenfalls für die Verwendung mit einigen der hierin offenbarten Ausführungsbeispiele geeignet sein können.
Die geografischen Datenbanken 270 können eine Vielzahl von verschiedenen Formen und/oder Formaten annehmen. Die geografischen Datenbanken können in einem Format oder in mehreren Formaten organisiert sein, um die Bereitstellung von verschiedenen navigationsbezogenen Informationen und Funktionen zu erleichtern. Verfahren zum Organisieren einer geografischen Datenbank zum Verbessern der Leistung von bestimmten navigationsbezogenen Funktionen werden in den US-Patenten mit den Nummern 5.974.419, 5.968.109 und 5.953.722 beschrieben.
Ein Format, das zum Organisieren der geografischen Datenbanken 270 verwendet werden kann, ist das SDAL^®-Format, das von der Navigation Technologies Corporation bereitgestellt wird. Die vorliegenden Ausführungsbeispiele sind nicht auf ein spezielles Format beschränkt und andere Formate können verwendet werden.
III. DIE NAVIGATIONSANWENDUNGEN
Mit dem Server 200 für navigationsbezogene Informationen sind Navigationsanwendungen 280 verbunden. Die Navigationsanwendungen 280 können aus einzelnen Kompo nentenanwendungen gebildet sein (die auch als Programme, Unterprogramme, Routinen oder Tools bezeichnet werden). Die Navigationsanwendungen 280 arbeiten über definierte Programmierschnittstellen zusammen. Die Navigationsanwendungen 280 nutzen die geografischen Datenbanken 280, die mit dem Server 200 für navigationsbezogene Informationen verbunden sind, um verschiedene Arten von Informationen bereitzustellen.
3 stellt einige navigationsbezogene Anwendungen 280 auf dem Server 200 für navigationsbezogene Informationen 200 dar. Zusätzlich zu den in 3 dargestellten Anwendungen kann der Server 200 für navigationsbezogene Informationen weitere Navigationsanwendungen umfassen.
Die Navigationsanwendungen 280 sind Programme, die spezifische Navigationsfunktionen bereitstellen, die von dem Server 200 für navigationsbezogene Informationen durchzuführen sind. In dem Ausführungsbeispiel von 3 fordern die Navigationsanwendungen 280 Daten von der geografischen Datenbank 270 an und erhalten Daten von dieser und verwenden diese Daten, um die Anforderungen für Navigationsinformationen von den Kunden-Interface-Servern 202(1), 202(2) ... zu erfüllen. Die Navigationsanwendungen 280 können die geografischen Daten einerseits direkt von der geografischen Datenbank beziehen, oder andererseits können die Navigationsanwendungen 280 die Daten über eine Schnittstellenschicht 284 und ein Betriebssystem 286 beziehen.
Wie in 3 dargestellt, umfassen die Navigationsanwendungen 280 eine Managementanwendung 288. Die Managementanwendung 288 ist ein Programm oder eine Routine, die für die Navigationsanwendungen auf dem Server 200 für navigationsbezogene Informationen eine übergeordnete Schnittstelle bereitstellt.
Eine Navigationsanwendung von den Navigationsanwendungen 280 auf dem Server 200 für navigationsbezogene Informationen ist eine Streckenberechnungsanwendung 290. In dem Ausführungsbeispiel von 3 empfängt die Streckenberechnungsanwendung 290 ihre Eingabe von dem Navigationsmanager 288. Die Streckenberechnungsanwendung 290 empfängt die Eingabe in Form von Daten, die wenigstens einen Startort und einen gewünschten Zielort identifizieren. Die Streckenberechungsanwen dung 290 kann ebenfalls zusätzliche Informationen empfangen, die Einfluss auf die Berechnung der Strecke haben. Beispielsweise kann die zusätzliche Eingabe in die Streckenberechnungsanwendung 290 Daten umfassen, die die Anwenderpräferenzen, wie beispielsweise das Vermeiden von gebührenpflichtigen Straßen oder Autobahnen und so weiter, spezifizieren. Die Eingabe kann darüber hinaus Daten beinhalten, die die Uhrzeit bezeichnen, zu der die Fahrt begonnen wird, was sich auf die Streckenberechnung auswirken kann.
Wenn die Daten gegeben sind, die die Positionen eines Startortes und eines Zielortes identifizieren, verwendet die Streckenberechungsanwendung 290 Daten aus den geografischen Datenbanken 270, um eine Strecke zwischen dem Startort und dem Zielort zu berechnen. Die Streckenberechnungsanwendung 290 kann zu diesem Zweck sämtliche verschiedene Mittel und Algorithmen nutzen. Beispielsweise kann die Streckenberechnungsanwendung 290 entweder den A*-Algorithmus oder den Dykstra-Algorithmus nutzen. Alternativ dazu kann die Streckenberechnungsanwendung 290 die Verfahren zum Berechnen von Strecken nutzen, die in dem US-Patent mit der Nummer 6.192.314 offenbart sind. Die in dem US-Patent mit der Nummer 6.192.314 offenbarten Verfahren stellen lediglich einige der Wege zur Berechnung von Strecken dar, und der hierin beanspruchte Gegenstand ist nicht auf ein bestimmtes Verfahren zur Streckenberechnung beschränkt. Es kann jedes geeignete gegenwärtig bekannte oder in Zukunft entwickelte Verfahren angewandt werden.
Ohne Berücksichtigung des angewandten Verfahrens stellt die Streckenberechnungsanwendung 290 eine Ausgabe in Form einer Liste bereit, die eine fortlaufende Reihe von Straßen (oder Segmenten davon) anzeigt, die eine rechtskräftige Lösungsstrecke zwischen einem Startort und einem Zielort bilden. Eine rechtskräftige Lösungsstrecke" ist an die bekannten Verkehrsbeschränkungen, wie beispielsweise Einbahnstraßen, Abbiegeverbote und so weiter, angepasst. Das Verfahren, das von der Streckenberechnungsanwendung 290 verwendet wird, kann konzipiert sein, um die Lösungsstrecke zu optimieren, um ein oder mehrere vorgegebene Kriterien zu erfüllen. Solche Kriterien können die kürzeste Fahrtzeit, die geringste Entfernung, die wenigsten Abbiegungen und so weiter umfassen. Wenn das Verfahren, das von der Streckenberechnungsanwendung 290 verwendet wird, konzipiert ist, eine Lösungsstrecke zu finden, die für ein Kriterium oder mehrere Kriterien optimiert ist, dann erfüllt die Lösungsstrecke ebenso idealerweise dieses eine Kriterium oder diese mehreren Kriterien.
In dem Ausführungsbeispiel von 3 ist die Ausgabe der Streckenberechnungsanwendung 290 in Form eines Streckenberechnungsobjektes 302. 4 ist ein Diagramm, das die Komponenten des Streckenberechnungsobjektes 302 darstellt. Das Streckenberechnungsobjekt 302 enthält eine geordnete Liste 304, die eine Vielzahl von Straßensegmentdateneinheiten (das heißt, seg1, seg2, seg3 ... seg(n)) anzeigt. Die Vielzahl der Dateneinheiten stellt die Straßensegmente dar, die die fortlaufende zu navigierende Strecke zwischen dem Startort und dem Zielort bilden, die von der Streckenberechnungsanwendung 290 berechnet wurde. Da diese Segmente eine fortlaufende Strecke bilden, hat jedes Segment einen gemeinsam Knoten mit seinem Nachfolgersegment in der Liste. Wie in 4 dargestellt, besitzen beispielsweise die Segmente „seg2" und „seg3" einen gemeinsamen Knoten „N3". Das Streckenberechnungsobjekt 302 kann weitere Informationen 306 zusätzlich zu der geordneten Liste von Straßensegmentdateneinheiten enthalten.
In Bezug auf 3 wird das Streckenberechnungsobjekt 302, das von der Streckenberechnungsanwendung 290 erzeugt wird, als eine Eingabe für die Streckenführungsanwendung 310 verwendet. (Die Streckenführungsanwendung 310 ist eine weitere der Navigationsanwendungen 280.) Die Streckenführungsanwendung 310 umfasst eine Manövererzeugungsanwendung 320. Die Manövererzeugungsanwendung 320 verwendet das Streckenberechnungsobjekt 302, das von der Streckenberechnungsanwendung 290 gebildet wird, als seine Eingabe. (Verfahren zum Bereitstellen der Funktionen, die von der Manövererzeugungsanwendung 320 durchgeführt werden, werden in dem US-Patent mit der Nummer 6.199.013 offenbart. Die Manövererzeugungsanwendung 320, die hierin beschrieben wird, ist dem Gegenstand ähnlich, der in diesem Patent offenbart wird.)
Die Manövererzeugungsanwendung 320 führt wenigstens zwei Funktionen aus. Die Manövererzeugungsanwendung 320 verwendet die Informationen in der geordneten Liste 304 der Segmentdateneinheiten in dem Streckenberechnungsobjekt 302, um zu bestimmen, welche Orte entlang der berechneten Stecke dem Endanwender mit Manövrieranweisungen oder Hinweisen erklärt werden sollen. Zusätzlich dazu sammelt die Manövererzeugungsanwendung 320 für jeden der Orte, der als erklärungsbedürftig bestimmt wurde, Informationen, die benötigt werden, um eine Manövrieranweisung oder einen Hinweis für den bestimmten Ort bereitzustellen.
Beim Durchführen dieser Funktionen verwendet die Manövererzeugungsanwendung 320 zwei Objekte. In Bezug auf 5 umfasst die Manövererzeugungsanwendung 320 ein (Manövererzeugungs-) Konfigurationsobjekt 330 sowie ein Manövererzeugungsobjekt 340. Das (Manövererzeugungs-) Konfigurationsobjekt 330 enthält Manöverregeln 332. Diese Manöverregeln 332 werden unter Verwendung der Daten in dem Streckenberechnungsobjekt 302 und aus der geografischen Datenbank 270 angewandt. Diese Regeln bestimmen, wenn ein Ort entlang der berechneten Strecke mit einer Manövrieranweisung erklärt werden soll. Wie vorangehend erwähnt, enthält das Streckenberechnungsobjekt 302 die Liste 304 der Dateneinheiten, die Segmente von Straßen repräsentieren. Da diese Liste Straßensegmente repräsentiert, die eine fortlaufende Strecke bilden, hat jedes Straßensegment, das durch eine Dateneinheit in der Liste 304 repräsentiert wird, einen gemeinsamen Knoten (das heißt, einen „Endpunkt") mit einem Straßensegment, das durch eine nachfolgende Dateneinheit in der Liste repräsentiert ist. Die Manöverregeln 332 werden bei jedem dieser Knoten in der Liste 304 angewandt.
Beim Anwenden der Manöverregeln 332 wird die Fahrtrichtung der berechneten Strecke berücksichtigt. Folglich wird das Segment, bei dem die berechnete Strecke in den Knoten führt, der durch die Manöverregeln 332 getestet wird, als das Zufahrtssegment identifiziert. Das Segment, bei dem die berechnete Strecke aus dem Knoten herausführt, der durch die Manöverregeln 332 getestet wird, wird als das Ausfahrtssegment identifiziert. Zusätzlich werden alle anderen Straßensegmente, die kein Bestandteil der berechneten Strecke sind, jedoch denselben Knoten mit dem Zufahrts- und dem Ausfahrtssegment haben, identifiziert. Die Dateneinheiten, die sämtliche dieser Straßensegmente repräsentieren, werden von der Datenbank 270 bezogen.
Die Manöverregeln werden 332 werden in Form einer Tabelle 333 bereitgestellt. Die Tabelle 333 definiert eine Vielzahl von Manövertypen 334 sowie eine Vielzahl von Manöverbedingungstests 335. Jeder dieser Manövertypen 334 charakterisiert eine bestimmte Art von Fahrbahn-Konfigurationsänderung, die an dem getesteten Knoten von der be rechneten Strecke auftreten kann. Jedem Manövertyp 334 ist ein einzigartiger Code oder eine einzigartige Nummer zugeordnet.
Jeder der Manöverbedingungstests 335 ist so ausgearbeitet, dass er lediglich eine positive oder eine negative Antwort akzeptiert. Jeder in der Tabelle 333 definierte Manövertyp 334 ist mit einer spezifischen Untermenge der Vielzahl von Manöverbedingungstests 335 assoziiert. Jeder Manöverbedingungstest 335 verwendet Daten in den Dateneinheiten, die von der Datenbank 270 erhalten wurden (wie beispielsweise Daten, die mit dem Zufahrtssegment, dem Ausfahrtssegment, den zugänglichen und unzugänglichen Segmenten und so weiter assoziiert sind), um zu bestimmen, ob die Bedingung, die in dem Manöverbedingungstests spezifiziert ist, erfüllt wird. Für jeden Knoten in der berechneten Strecke 304 ist, wenn alle mit einem Manövertyp 334 assoziierten Manöverbedingungstests erfüllt sind, eine Manövrieranweisung für diesen Knotenort erforderlich.
Für jeden der Orte, die von der Manövererzeugungsanwendung 320 als erklärungsbedürftig bestimmt werden, bildet die Manövererzeugungsanwendung 320 eine Manöverdatenstruktur 350 und fügt die Manöverdatenstruktur zu dem Manövererzeugungsobjekt 340 hinzu. Jede Manöverdatenstruktur 350, die von der Manövererzeugungsanwendung 320 gebildet wird, enthält Informationen, die zum Bereitstellen einer Manövrieranweisung für den Endanwender an dem Ort entlang einer Strecke erforderlich sind, an dem bestimmt wurde, dass dem Endanwender eine Erklärung bereitgestellt wird. Einige der Daten, die für die Manöverdatenstruktur erforderlich sind, sind in den Segmentdateneinheiten enthalten oder von diesen abgeleitet, die getestet wurden, um zu bestimmen, ob eine Manövrieranweisung an dem Ort des Knotens erforderlich ist. Es kann erforderlich sein, dass zusätzliche Daten von der Datenbank 270 durch das Manövererzeugungs-Konfigurationsobjekt erhalten oder abgeleitet werden müssen.
6 zeigt die Arten von Daten, die in jeder Manöverstruktur 350 enthalten sind. In einem Ausführungsbeispiel ist die Manöverdatenstruktur 350 als eine C-Datenstruktur gebildet. Unter Verwendung von Daten aus den Segmentdateneinheiten, die den Knoten, der mit dem Manöver assoziiert ist, gemeinsam haben, sowie sämtlichen zusätzlichen Daten, die von der geografischen Datenbank benötigt oder abgeleitet werden, sammelt das Manövererzeugungsobjekt 340 die Daten, die den verschiedenen Elementen der Manöverdatenstruktur 350 entsprechen. Daten werden in dem Umfang gesammelt, wie sie verfügbar sind. Elemente der Datenstruktur können leer gelassen werden, wenn keine Daten verfügbar sind (wenn zum Beispiel eine der Straßen an dem Manöverort unbenannt ist).
In der Datenstruktur 350 ist ein Feld 350(1)(1) enthalten, das die Anzahl der Segmente angibt, die sich an dem Knoten treffen. Die Zufahrts- und Ausfahrtssegmente 350(1)(2), 350(1)(3) in den Knoten werden aufgezeigt. Bei jedem der Segmente (Zufahrt und Ausfahrt) sorgt die Datenstruktur 350 für das Anzeigen des/der Namens/Namen des Segmentes (falls vorhanden) 350(2)(2), eines Zeichens/von Zeichen an dem Segment (falls vorhanden) 350(2)(3), der Rangordnung des Segmentes 350(2)(4), der Klassifizierung des Segmentes relativ zu dem Zufahrtssegment (Ausfahrt, zugänglich, unzugänglich) 350(2)(5), der Datenbankklassifizierung des Segmentes (zum Beispiel beschränkte Zufahrt, Straße, Auffahrt) 350(2)(6) sowie des Winkels des Segmentes relativ zu dem Zufahrtssegment 350(2)(8). Zusätzlich dazu enthält die Datenstruktur 350 auch ein Feld, das zum Anzeigen des Manövertyps (wie oben beschrieben) 350(4)(2), der Entfernung zu dem nächsten Manöver 350(4)(4) und zum Anzeigen dazu verwendet werden kann, ob das Manöver in einem Mehrfachmanöver 350(4)(1) enthalten ist. (Ein Mehrfachmanöver kann durch das Manövererzeugungsobjekt definiert werden, wenn ein Ort, an dem eine Manövrieranweisung als erforderlich bestimmt wurde, so nahe an einem anderen angrenzenden Ort liegt, an dem eine Manövrieranweisung als erforderlich bestimmt wurde, dass es vorzuziehen wäre, dem Endanwender zwei oder mehrere Manövrieranweisungen zur gleichen Zeit zu präsentieren. Die Entfernung, bei der ein Mehrfachmanöver definiert wird, ist konfigurierbar und kann eine Funktion verschiedener Faktoren sein, die Geschwindigkeitsbeschränkungen entlang der Straßensegmente, die Entfernung, die Rangordnung und so weiter umfassen.
Die Datenstruktur kann darüber hinaus Felder zum Bereitstellen von Kontextinformationen 350(3) für die Ausfahrtsstraße enthalten. Diese Art von Informationen kann nützlich sein, wenn andere Informationen in der Manöverstruktur für die vollständige Beschreibung der Ausfahrt nicht ausreichend sind, so beispielsweise wenn das Ausfahrtssegment unbenannt ist. Die Felder für die Kontextinformationen können einen Zielortstring 350(3)(1) enthalten, der die Ausfahrt des Manövers in Fällen beschreibt, in denen der Name des Ausfahrtssegmentes nicht ausreichend ist (beispielsweise wenn es unbenannt ist). Die Kontextinformationen 350(3) können auch ein Feld für einen "Ort" 350(3)(2) enthalten, das den Ort der Ausfahrt relativ zu einer anderen Straße (zum Beispiel vor, nach, geradeaus, hinter, rechts oder links) angibt. Die Kontextinformationen 350(3) können darüber hinaus ein Feld für einen „Abbiegewinkel" 350(3)(3) enthalten, das den Winkel angibt, der eingeschlagen werden muss, um auf die Ausfahrtsstraße zu gelangen. Die Kontextinformationen können des Weiteren ein Feld für eine „Fahrtrichtung" 350(3)(5) enthalten, das während dem Startmanöver verwendet werden kann und die erste einzuschlagende Fahrtrichtung bereitstellt (zum Beispiel Norden, Süden, Osten, Westen, Nordwesten und so weiter). Die Kontextinformationen 350(3) können auch ein Feld „relativ zu" 350(3)(4) enthalten. Das Feld „relativ zu" 350(3)(4) ist zur Verwendung bei einem Startmanöver bestimmt. Das Feld „relativ zu" 350(3)(4) gibt eine erste Straßenkreuzung an, in deren Richtung zu fahren ist. Es kann auch in Fällen verwendet werden, in denen das Ausfahrtssegment unbenannt ist (zum Beispiel „nach der Main Street rechts abbiegen"). Die Kontextinformationen 350(3) können darüber hinaus ein Feld für eine „Anzahl von Ausfahrten" 350(3)(6) enthalten, das für Kreisverkehrmanöver verwendet werden kann. Dieses Feld „Anzahl der Ausfahrten" 350(3)(6) enthält eine Anzahl von Ausfahrten, an denen beim Fahren entlang eines Kreisverkehrs vorbei gefahren werden muss, bevor die gewünschte Ausfahrt erreicht wird.
Zusätzlich zu den vorangehend beschriebenen Elementen kann die Manöverdatenstruktur 350 zusätzliche Elemente 350(5) enthalten.
Die Manöverdatenstruktur enthält des Weiteren Informationen zum Bereitstellen von Hinweisen. Hinweise sind Arten nützlicher Erklärungsinformationen, die nicht notwendigerweise mit einem Manöver assoziiert sind. Hinweise werden bereitgestellt, wenn es eine Änderung in dem Straßennetz gibt, ein bestimmtes Fahrmanöver jedoch nicht erforderlich ist. Beispielsweise kann ein Hinweis bereitgestellt werden, wenn auf eine Brücke hinauf oder von ihr herunter gefahren wird, oder wenn in einen Tunnel hinein oder aus einem Tunnel heraus gefahren wird. Die Manöverdatenstruktur 350 enthält ein Feld, das eine Liste 350(4)(3) mit einem Hinweistyp oder mit mehreren Hinweistypen enthält. Im Folgenden wird erneut Bezug auf 5 genommen, wobei das Manöverkonfigurationsobjekt 330 zusätzlich zu den Manöverregeln 332, die verwendet werden, um zu bestimmen, ob ein Manöver an einem bestimmten Knoten zu erklären ist und um die Datenstrukturen 350 damit zu bilden, auch Hinweisregeln 370 enthält. Die Hinweisregeln 370 werden bei jedem der Knoten in dem Streckenberechnungsobjekt 342 angewandt.
Die Hinweisregeln 370 liegen ebenso wie die Manöverregeln 332 in Form einer Tabelle 372 vor. Die Hinweisregeltabelle 372 enthält eine Reihe von Hinweistypen 376 und eine Reihe von Hinweisbedingungstests 378. Jeder Hinweistyp 376 charakterisiert eine bestimmte Art von Hinweis, der an einem Knoten bereitgestellt werden kann. Jedem Hinweistyp ist ein einzigartiger Code oder eine einzigartige Nummer zugewiesen. Jeder der Hinweisbedingungstests 378 ist so gestaltet, dass er lediglich positive und negative Ergebnisse zulässt. Eine spezifische Unterwenge von Hinweisbedingungstests 378 ist mit jedem unterschiedlichen Hinweistyp 376 assoziiert. Wenn positive Ergebnisse für sämtliche Hinweisbedingungstests bezüglich eines Hinweistyps 376 erhalten werden, dann wird dieser Hinweistyp 376 mit dem Manöver an diesem Ort assoziiert.
Im Gegensatz zu den Regeln für Manöver erfordern die Regeln für Hinweise kein eindeutiges Ergebnis. Folglich können für einen gegebenen Ort entlang einer Strecke ein Hinweistyp, mehrere Hinweistypen oder keine Hinweistypen bereitgestellt werden. Die Nummer oder der Code für jeden Hinweistyp 376 ist in der Datenstruktur 350 enthalten, die für diesen Ort gebildet ist.
Die Anwendung der Hinweisregeln ist unabhängig von der Anwendung der Manöverregeln. Aus diesem Grund kann die Anwendung der Hinweisregeln erfordem, dass ein Hinweis an einem Ort entlang einer Strecke bereitgestellt wird, selbst wenn die Anwendung der Manöverregeln die Bereitstellung einer Manövrieranweisung an demselben Ort nicht erfordert. Wenn die Anwendung der Hinweisregeln erfordert, dass ein Hinweis an einem Ort bereitgestellt wird, jedoch die Anwendung der Manöverregeln die Bereitstellung einer Manövrieranweisung an demselben Ort nicht erfordert, wird eine Manöverdatenstruktur für diesen Ort gebildet, die Daten für die Elemente der Datenstruktur in dem Umfang enthält, wie die Daten verfügbar sind. Eine Manöverdatenstruktur, die für einen derartigen Ort gebildet wird, würde einen Manövertyp "0" haben.
Das Manövererzeugungs-Konfigurationsobjekt 340 verschiebt die Liste 344 der Dateneinheiten in das Streckenberechnungsobjekt 342, so dass jeder Knoten entlang der berechneten Strecke mit den Manöverregeln 332 getestet wird. Eine Manöverdatenstruktur 350, die Informationen für jedes der oben aufgeführten Felder enthält (soweit solche Informationen zur Verfügung stehen), wird für jeden Ort auf der berechneten Strecke gebildet, an dem alle der Manöverbedingungstests für sämtliche Manövertypen oder alle der Hinweisbedingungstests für sämtliche der Hinweistypen erfüllt wurden. Die durch diesen Vorgang gebildeten Manöverdatenstrukturen 350 sind der Reihenfolge nach in dem Manövererzeugungsobjekt 340 enthalten.
Unter erneuter Bezugnahme auf 3 wird das Manövererzeugungsobjekt 340 einer Erstellungsanwendung 400 bereitgestellt. Die Erstellungsanwendung 400 ist auf dem Server 200 für navigationsbezogene Informationen enthalten. Die Erstellungsanwendung 400 nimmt das von der Manövererzeugungsanwendung 320 bereitgestellte Manövererzeugungsobjekt 340, extrahiert die Informationen aus dem Manövererzeugungsobjekt 340, bildet eine sprach- und formatunabhängige Datenstruktur 420, die die Informationen aus dem Manövererzeugungsobjekt 340 enthält und gibt die sprach- und formatunabhängige Datenstruktur 420 aus. In dem Ausführungsbeispiel von 3 ist die Erstellungsanwendung 400 eine XML- (eXtensible Markup Language) Builder-Klasse und die sprach- und formatunabhängige Datenstruktur 420 ist ein XML-String. Die sprach- und formatunabhängige Datenstruktur 420 wird wenigstens auf zwei Wegen verteilt. Diese beiden Wege umfassen das Speichern des erzeugten Strings 420 in einer Datei oder das Senden des erzeugten Strings 420 zu seinem Rufer, das heißt, dem Kunden-Interface-Server 202.
In einem Ausführungsbeispiel wird die Erstellungsanwendung 400 mittels C++ implementiert. In diesem Ausführungsbeispiel enthält die Erstellungsanwendung 400 eine XML-Erzeugungseinrichtung 440. Die XML-Erzeugungseinrichtung 440 nimmt das Manövererzeugungsobjekt 340 und erstellt den String 420. Der String 420 enthält die XML-Darstellung des Manöverobjektes 340, die zu dem Kommunikationssystem 266 zur Übertragung zu dem Kunden-Interface-Provider 220 weiter gegeben wird.
Das folgende Beispiel zeigt die Inhalte der XML-Struktur. Diese Elementnamen würden in der XML-Vorlage, die von dem Kunden-Interface-Provider verwendet wird, enthalten sein. Beispiel
IV. DIE DATENKONVERTIERUNGSANWENDUNG AUF DEM KUNDEN-INTERFACE-SERVER
In Bezug auf 2 wird die sprach- und formatunabhängige Datenstruktur 420 von dem Server 200 für navigationsbezogene Informationen über das Datennetz 140 zu dem Kunden-Interface-Server 202(1) gesendet. Wenn der Kunden-Interface-Server die sprach- und formatunabhängige Datenstruktur 420 empfängt, extrahiert die Datenkonvertierungsanwendung 240 die in der sprach- und formatunabhängigen Datenstruktur 420 enthaltenen Manöverdaten. Die Datenkonvertierungsanwendung 240 entwickelt anschließend unter Verwendung der Inhalte der sprach- und formatunabhängigen Datenstruktur 420 Manövrieranweisungen. Die Manövrieranweisungen werden in einer ausgewählten Sprache des Endanwenders gebildet, der die navigationsbezogenen Informationen angefordert hat. Zusätzlich dazu unterzieht die Datenkonvertierungsanwendung 240, wenn sie die Manövrieranweisungen bildet, die Anweisungen der Formatierung, so dass die Anweisungen auf der anfordernden Computerplattform von Endanwendern bereitgestellt werden.
Wenn die sprach- und formatunabhängige Datenstruktur 420, die die Datenkonvertierungsanwendung 240 von dem Server 200 für navigationsbezogene Informationen empfängt, im XML-Format ist, kann die Datenkonvertierungsanwendung 240 XML-Vorlagen 460 benutzen. Die Vorlagen 460 entsprechen dem XML-Format, das von der Erstellungsanwendung 400 verwendet wird.
In einem Ausführungsbeispiel stellt die Datenkonvertierungsanwendung 240 die Manövrieranweisungen der Computerplattform von Endanwendern im HTML-Format bereit. Die Datenkonvertierungsanwendung 240 enthält eine Vorlage für diesen Zweck. Entsprechend diesem Ausführungsbeispiel verwenden die HTML-Vorlagen, die von der Datenkonvertierungsanwendung 240 benutzt werden, die XML-Daten 420, die von dem Server 200 für navigationsbezogene Informationen bereitgestellt werden und erzeugen eine HTML-Datendatei, die die Manövrieranweisungen im HTML-Format enthält. Die HTML-Datendatei wird anschließend über das Datennetz 140 zu der Computerplattform 130 von Endanwendern gesendet, wo die HTML-Datendatei verwendet werden kann, um dem Endanwender die Manövrieranweisungen mittels einer Anwendung zu präsentieren, die HTML verarbeiten kann, wie beispielsweise ein Internet-Browser.
V. VORTEILE
Die Ausführugnsbeispiele der offenbarten Navigationssysteme weisen mehrere Vorteile auf. Die Navigationssysteme ermöglichen den Endanwendern, die über verschiedene Typen von Computerplattformen verfügen, Navigationsdienste zu beziehen. Die Navigationssysteme ermöglichen darüber hinaus, dass die Endanwender Unterstützung in verschiedenen Sprachen erhalten. Die offenbarten Ausführungsbeispiele erzielen diese Vorteile durch die Trennung der Funktionen zur Bereitstellung von navigationsbezogenen Informationen von den kundenspezifischen Aspekten, wie beispielsweise der spezifischen Sprachunterstützung und der spezifischen Formatunterstützung.
Es ist beabsichtigt, dass die vorangehende ausführliche Beschreibung zu Illustrationszwecken dient und nicht im einschränkenden Sinne zu verstehen ist, und es ist zu beachten, dass die folgenden Patentansprüche den Umfang der Erfindung definieren.

Claims

Navigationssystem (110), das umfasst: elektronische Vorrichtungen (130) von Endanwendern, einen Kunden-Interface-Server (202) und einen Navigationsdienste-Server (200), wobei die elektronischen Vorrichtungen (130) von Endanwendern Anforderungen für Navigationsdienste zu dem Kunden-Interface-Server (202) senden und von dem Kunden-Interface-Server Antworten auf die Anforderungen empfangen, wobei der Kunden-Interface-Server (202) Programmierung enthält, die bei Empfang der Anforderungen von den elektronischen Vorrichtungen (130) von Endanwendern Anforderungsnachrichten über das Internet zu dem Navigationsdienste-Server sendet, wobei die Anforderungsnachrichten Navigationsinformationen, die auf die Anforderungen antworten, anfordern, wobei der Navigationsdienste-Server (200) die Anforderungsnachrichten von dem Kunden-Interface-Server (202) empfängt und in dem Navigationsdienste-Server (200) installierte Anwendungen und eine mit diesem verbundene geografische Datenbank (270) nutzt, sprachunabhängige Antwortnachrichten auf die Anforderungsnachrichten formuliert und die sprachunabhängigen Antwortnachrichten zu dem Kunden-Interface-Server sendet und wobei der Kunden-Interface-Server (202) des Weiteren Programmierung enthält, die bei Empfang der sprachunabhängigen Antwortnachrichten von dem Navigationsdienste-Server (200) die Antworten formuliert und die Antworten zu den elektronischen Vorrichtungen (130) von Endanwendem sendet.
Navigationssystem nach Anspruch 1, wobei die Anforderungen für Navigationsdienste von den elektronischen Vorrichtungen (130) von Endanwendern über das Internet zu dem Kunden-Interface-Server (202) gesendet werden.
Navigationssystem nach Anspruch 1, wobei die sprachunabhängigen Antwortnachrichten im XML-Format sind.
Navigationssystem nach Anspruch 1, wobei der Kunden-Interface-Server (202) XML-Vorlagen benutzt, um die Antworten zu formulieren, die zu den elektronischen Vorrichtungen (130) von Endanwendern gesendet werden.
Navigationssystem nach Anspruch 1, wobei die Antworten, die zu den elektronischen Vorrichtungen (130) von Endanwendern gesendet werden, im HTML-Format sind.
Navigationssystem nach Anspruch 5, wobei der Kunden-Interface-Server (202) eine XML-Vorlage verwendet, um die Antworten, die zu den elektronischen Vorrichtungen (130) von Endanwendern gesendet werden, im HTML-Format zu formulieren.
Verfahren zum Bereitstellen von Streckeninformationen, ein Navigationssystem verwendend, das Verfahren umfasst: Empfangen, auf Seiten eines Kunden-Interface-Servers (202), über ein Datennetz (140), einer Anforderung eines Endanwenders (130) für Streckenführung zu einem Zielort, Senden, von Seiten des Kunden-Interface-Servers (202), über das Datennetz (140), einer Nachricht für Manövrieranweisungen zu einem Server (200) für navigationsbezogene Informationen, Berechnen, auf Seiten des Servers (200) für navigationsbezogene Informationen, nach dem Empfangen der Nachricht von dem Kunden-Interface-Server (202), einer Strecke zu dem Zielort und Bestimmen einer Reihe von Manövern zum Bewegen entlang einer Strecke zu dem Zielort, Bilden, auf Seiten des Servers (200) für navigationsbezogene Informationen, einer sprach- und formatunabhängigen Datenstruktur (350), die die Reihe von Manövern darstellt, Senden, von dem Server (200) für navigationsbezogene Informationen, über das Datennetz (140), der sprach- und formatunabhängigen Datenstruktur (350) zu dem Kunden-Interface-Server (202), Nutzen, auf Seiten des Kunden-Interface-Servers (202), der von dem Server (200) für navigationsbezogene Informationen empfangenen sprach- und formatunabhängigen Datenstruktur (350), um sprach- und formatspezifische Manövrieranweisungen zu bilden, und Bereitstellen, von dem Kunden-Interface-Server (202), über das Datennetz (140), der gebildeten sprach- und formatspezifischen Manövrieranweisungen zu dem Endanwender (130).
Verfahren nach Anspruch 7, wobei die sprach- und formatspezifischen Manövrieranweisungen im HTML-Format sind.
Verfahren nach Anspruch 7, wobei die sprach- und formatunabhängige Datenstruktur (350) im XML-Format ist.
Verfahren nach Anspruch 7, wobei das Datennetz (140) das Internet umfasst.
Verfahren nach Anspruch 7, wobei der Kunden-Interface-Server (202) eine XML-Vorlage verwendet, um die sprach- und formatspezifischen Manövrieranweisungen zu bilden.