EP2208024A1 - Verfahren zum betrieb eines navigationssystems - Google Patents
Verfahren zum betrieb eines navigationssystemsInfo
- Publication number
- EP2208024A1 EP2208024A1 EP08847125A EP08847125A EP2208024A1 EP 2208024 A1 EP2208024 A1 EP 2208024A1 EP 08847125 A EP08847125 A EP 08847125A EP 08847125 A EP08847125 A EP 08847125A EP 2208024 A1 EP2208024 A1 EP 2208024A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- route
- output
- configuration file
- stored
- interpretation module
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000004364 calculation method Methods 0.000 claims abstract description 26
- 230000008569 process Effects 0.000 claims abstract description 3
- 238000012545 processing Methods 0.000 claims description 3
- 238000011156 evaluation Methods 0.000 claims 2
- 230000004044 response Effects 0.000 claims 1
- 230000002123 temporal effect Effects 0.000 claims 1
- 230000000007 visual effect Effects 0.000 claims 1
- 230000006399 behavior Effects 0.000 description 5
- 230000001419 dependent effect Effects 0.000 description 4
- 230000010354 integration Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000013024 troubleshooting Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
- G01C21/34—Route searching; Route guidance
- G01C21/36—Input/output arrangements for on-board computers
- G01C21/3626—Details of the output of route guidance instructions
- G01C21/3641—Personalized guidance, e.g. limited guidance on previously travelled routes
Definitions
- the invention relates to a method for operating a navigation system according to the preamble of claim 1.
- Known navigation systems which are used, for example, as mobile navigation devices for motor vehicles, serve at their core according to the calculation of movement routes from a starting point to a destination point. Based on the calculated route, the known navigation systems then include a route guidance component in which maneuvering instructions are calculated for the user.
- the maneuvering instructions serve to give the user instructions to follow from the current position of the route. After calculation of the maneuvering instruction, this is issued optically and / or acoustically.
- the maneuvering instruction can thus be displayed, for example, on a display or output with a loudspeaker for the user in a specific language.
- Known navigation systems are usually present as machine-readable software source code and are executed on suitable devices, for example microcomputers with a central processor unit. All presettings and configurations, which are necessary in particular for the calculation and output of the maneuvering instructions, are integrated into the machine-readable source code. This integration of the default data for the calculation or output of the maneuvering instructions into the machine-readable source code leads to considerable disadvantages.
- the source code in each case depends on the software platform used in each case, so that when changing the software platform used in each case the entire source code must be reprogrammed.
- the source code differs fundamentally, if it has been developed for example for Windows, Java or the Symbian platform. If errors in the software module for calculating and outputting the maneuvering instruction are detected or further developments are implemented, therefore, due to the integration into the software source code, different source codes for versions for the different software platforms must be revised and updated.
- maneuver instruction routines integrated with the software source code can take a significant amount of programming.
- the source code for the definition of the calculation or output of the maneuvering instructions can comprise several tens of thousands of lines, which must be completely exchanged during an update. If the update is carried out by data transfer, for example via the Internet, correspondingly large amounts of data, for example several hundred kilobytes or a few megabytes, must be transmitted.
- Furthermore disadvantageous in the integration of the boundary conditions for the calculation or output of the maneuvering Instructions are that custom changes are hardly possible.
- the method according to the invention is based on the fact that a configuration file is stored in the navigation system, which preferably contains all the configuration presetting data which are required for the calculation and / or output of the maneuvering instruction. Before and / or during the calculation or output of a maneuvering instruction, these default settings must be loaded and interpreted.
- an interpretation module is present in the navigation system, which reads out and interprets the stored preset data from the configuration file. So no machine-readable source code must be generated, as it can be processed directly by a microprocessor, for example. As a result, this means that the presetting data required for the calculation and / or output of the maneuvering is no longer integrated into the machine-readable source code of the navigation system, but is stored as data in a separate configuration file. Only before or during the calculation or output of the maneuvering instruction are these presetting data read out and interpreted by the interpretation module.
- the preset data stored in the configuration file can be analyzed much easier, so that the troubleshooting and further development of the software is simplified.
- the storage of the default data in the inventive The configuration file must be independent of the software platform used. This means that when using the software on another software platform, only the interpretation module needs to be replaced, whereas the default data can remain unchanged.
- Another advantage is that the default data can be compressed much more by the separate storage in the configuration file. This significantly reduces the required data transfer when updating the preset data.
- the interpretation module When the interpretation module reads out the default data from the configuration file, it stores it in a memory in a memory-optimized format and, during the calculation and / or output of the maneuver instruction, for the preset data stored in the memory, with particular regard to rapid processing of time-critical processes accesses and interprets them.
- the interpretation of the preset data stored in the memory thus always takes place on demand, which saves computing power.
- the form in which the configuring default data for the calculation and / or output of the maneuvering instruction are stored in the configuration file is fundamentally arbitrary. Particularly advantageous is the storage in alphanumeric text form, as this text form can be read and interpreted by people directly. This is particularly advantageous when troubleshooting and developing navigation software.
- one configuration file is sufficient for the simple execution of the navigation system when calculating or outputting the maneuvering instruction.
- a plurality of configuration files are stored in the navigation system, each containing different preset data.
- the navigation system can then either automatically or user-defined select one of the configuration files and have it read out and interpreted by the interpretation module. As a result, it is thus possible to influence the behavior of the navigation system in the calculation or output of the maneuvering instructions in a simple manner by changing the configuration file used in each case.
- Another possibility for using parallel stored configuration files is that the different configuration files are each assigned to different usage areas. As a result, it can be achieved that the maneuvering instructions in different areas of use, for example in different states, are each different and thus adapted to the country-specific conditions.
- configuration files for different usage times can also be stored in the navigation system. For example, it is conceivable that the behavior in the calculation or output of the Maneuvering instructions to adapt to the requirement profile of day and night. Depending on the respective usage time, the navigation system can then automatically load the respectively assigned preset data from the different configuration files and have it interpreted in the interpretation module.
- the configuration file is read at least once during startup of the navigation system, and the preset data stored therein are read out and interpreted by the interpretation module.
- the default settings generated by interpretation are then stored.
- the configuration file is read out again during the runtime of the navigation system and henceforth used in the interpretation module as a new sequence control.
- the default data newly generated by interpretation then replace the previously used default data, for example by overwriting the corresponding memory areas.
- an update of the navigation software containing changes in the behavior of the maneuvering instructions can thus be performed without restarting the entire navigation system.
- the reloading of different alternatives of configuration files for example for different user groups or different user profiles or different usage areas or different usage times, can thus be performed in each case without restarting the navigation system.
- the stored default data can be quite substantial. In order to simplify the handling and maintenance of this data, it is therefore advantageous if the default data is distributed over several configuration files.
- the distribution of the default data to several configuration part files also has advantages in the Look for software updates, as changes can only relate to individual configuration sub-files, so that only the respective configuration sub-files must be replaced.
- Which type of preset data is stored in the configuration files is basically arbitrary. According to a preferred variant of the method, it is provided that the entire decision logic for determining the time sequence of the output of a maneuver instruction sequence is controlled by the preset data. As a result, the entire behavior of the navigation system in the calculation or output of the maneuver instruction is controlled by the default data from the configuration file.
- the decision logic for processing the calculation or output of the maneuver instruction sequence can be done by tabular flowcharts. These flowcharts preferably contain tabular text information that maps a flowchart in a deterministic manner. These flowcharts stored in tabular form can also be easily interpreted and graphically displayed by suitable software modules for error analysis.
- To determine a maneuvering instruction basically three steps can be performed. The first step is a flowchart for
- a rough classification of an intersection or a road course evaluated contains the rules and decisions to be taken and the attributes to compare.
- a decision table is then evaluated which indicates which language-dependent announcements are to be output acoustically under which conditions. Of course, this decision table is language-dependent, so that a separate decision table has to be created for each existing language.
- a distance table is evaluated, which depends on the rough classification and the vehicle type or on the currently permitted speed or depending on the vehicle speed. of the current speed indicates the distance to which the announcement is spoken.
- the configuration file should comprise, in addition to a tabularly stored flowchart, a decision-making scheme stored in tabular form and / or a distance-saving scheme stored in tabular form.
- Fig. 1 is a graph showing a flow chart for rough classification of a road course
- Fig. 2 is a tabular flowchart corresponding to the flowchart of Fig. 1;
- FIG. 3 shows a table-like storable decision scheme for selecting maneuver instruction sequences
- Fig. 4 is a table storable distance scheme.
- Fig. 1 shows a flowcharts diagram 01 ("FlowChart") as required to compute a maneuvering instruction
- FlowChart a flowcharts diagram 01
- the rough classification gives the result "IgnoreJunction”.
- no maneuver instruction is generated for the road segment being analyzed. It is e.g. common in a transition from one road element to a subsequent road element along the route, when there is no way to drive on another road, not to issue a maneuver instruction.
- the checks according to the flow diagram 02 correspond to analysis modules in the route guidance unit, which take into account the currently examined route segments and potentially other surrounding other segments and deliver a defined result which corresponds to a specific truth value. Depending on the respective truth value, the flowchart can be continued. Thus, for each check in the flowchart, a postcondition is defined, which check is to be performed if the check is successful (yes) or not successful (no). In addition, it is also possible that only one Nachbedingung is specified. For example, if this postcondition is "Destination," the route guidance is at the end, and there is no successor.
- a coarse classification "destination” can be achieved by running in the FlowChart over the nodes K1, K2, K3, K4, K7, K8, K9 and K1, according to the graphical representation of the flowchart 01 (FIG. FIG. 1), the decision logic is stored in tabular form in flowchart 02.
- decision tables 03 may be provided for different language versions. It is also conceivable that the decisions about the type of announcement are held separately from the text to be issued in the respective language.
- the announcement which by the decision table 03 can also contain parts to be replaced (tags). These are, for example, the current street name, the street name, which is reached after the announcement, the route number, such as "on the A l", signpost information, for example, "towards the city center”, distance information, such as the distance to the announcement, and directions, such as the direction that must be taken in the announcement.
- the decision table 03 shown in FIG. 3 reflects only by way of example the possible content of a decision table.
- the tags which are in brackets, are still to be completed.
- the rough classification PriorityManoeuver shows in which distance the priority road is left. If the vehicle is more than a pre-configurable distance, e.g. 700 meters from the action point, the announcement will be used under "far” and will be spoken when reaching the 700 meters mark. The "distance” tag will be filled with the determined distance and the "direction” tag will be filled in, for example with “turn right”. This would result in the announcement "turn right at 700 meters and leave the main road”.
- a distance table 04 is shown by way of example.
- the distance in which an announcement is to be spoken is defined for all rough classifications.
- Each rough classification has different distances. For example, there may be distances "very far”, “far”, “near” and “very close”. If the rough classification indicates that you are on a fast road, so the distances for this are correspondingly greater selectable than in a rough classification of a local street.
- the decision table 04 is analyzed and the maneuver output is made when the positioning unit of the navigation device indicates that the distance configured in the distance table exists from the current position to the identified maneuver.
- the method according to the invention allows the extension of known navigation systems by the following options:
- Selectable route guidance strategy When configuring his navigation system, the user can be offered the selection according to which motives maneuvering instructions are to be created. So the number of messages per maneuver can be reduced.
- the implementation of this option is very simple by using the method according to the invention by holding a separate configuration file for each of the given options, which must be used accordingly by the route guidance unit. It is also conceivable to change the strategy during a current route guidance by analyzing the part of the route that has not yet traveled through the newly configured route guidance unit. 2. Updating ability: Also, by the method according to the invention updating or patching the present routing strategy can be easily performed. For this purpose, only the configuration files must be replaced, which is conceivable, for example, by a download via the navigation device. Prerequisite is the connection to a server, eg over the Internet or wirelessly via WLAN or UMTS.
- the inventive method facilitates the use of different languages. The addition of additional languages is easily possible with the inventive method and requires no replacement of the complete navigation software. Only a list of the currently available language of the navigation software must be known so that a new language can be offered accordingly.
Landscapes
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Automation & Control Theory (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Navigation (AREA)
- Traffic Control Systems (AREA)
Abstract
Die Erfindung betrifft ein Verfahren zum Betrieb eines Navigationssystems mit folgenden Verfahrensschritten: a) Berechnung einer Route von einem Startpunkt zu einem Zielpunkt, wobei die Route aus einer Folge von Streckensegmenten und Knotenpunkten zwischen den Streckensegmenten besteht, die mit einem Routenberechnungsverfahren aus einer Datenbank, in der ein geographisches Gebiet durch Streckensegmente und Knotenpunkte beschrieben ist, selektiert wird, b) Berechnung zumindest einer Manöveranweisung, die Anweisungen für den Benutzer enthält, um ausgehend vom aktuellen Standpunkt der Route zu folgen, c) optische und/oder akustische Ausgabe der Manöveranweisung an einer Ausgabeeinrichtung, wobei vor und/oder während der Berechnung und/oder Ausgabe der Manöveranweisung eine Konfigurationsdatei durch ein Interpretationsmodul ausgelesen und interpretiert wird und wobei in der Konfigurationsdatei konfigurierende Voreinstellungsdaten für die Berechnung und/oder Ausgabe der Manöveranweisung gespeichert sind.
Description
Verfahren zum Betrieb eines Navigationssystems
Die Erfindung betrifft ein Verfahren zum Betrieb eines Navigationssystems nach dem Oberbegriff des Anspruchs 1.
Bekannte Navigationssysteme, die beispielsweise als mobile Navigationsgeräte für Kraftfahrzeuge Verwendung finden, dienen ihrem Kern nach der Berechnung von Bewegungsrouten von einem Startpunkt zu einem Zielpunkt. Ausgehend von der berechneten Route beinhalten die bekannten Navigationssysteme dann eine Routenführungskomponente, in der Manöveranweisungen für den Benutzer berechnet werden. Die Manöveranweisungen dienen dabei dazu, dem Benutzer Handlungsanweisungen zu geben, um vom aktuellen Standpunkt der Route zu folgen. Nach Berechnung der Manöveranweisung wird diese optisch und/oder akustisch ausgegeben. Die Manöveranweisung kann also beispielsweise an einem Display angezeigt oder mit einem Lautsprecher für den Benutzer in einer bestimmten Sprache ausgegeben werden.
Bekannte Navigationssysteme sind üblicherweise als maschinenlesbarer Softwarequellcode vorhanden und werden auf geeigneten Geräten, beispielsweise Mikrocomputern mit Zentralprozessoreinheit, ausgeführt.
Alle Voreinstellungen und Konfigurationen, die insbesondere auch zur Berechnung und Ausgabe der Manöveranweisungen erforderlich sind, sind dabei in den maschinenlesbaren Quellcode integriert. Diese Integration der Voreinstellungsdaten für die Berechnung bzw. Ausgabe der Manöveranweisungen in den maschinenlesbaren Quellcode führt zu erheblichen Nachteilen. So ist der Quellcode jeweils abhängig von der jeweils benutzten Software-Plattform, so dass bei Änderung der verwendeten Software-Plattform jeweils auch der gesamte Quellcode umprogrammiert werden muss. So unterscheidet sich der Quellcode grundsätz- lieh, wenn dieser beispielsweise für Windows, Java oder die Symbian- Plattform entwickelt wurde. Werden Fehler im Softwaremodul zur Berechnung und Ausgabe der Manöveranweisung festgestellt bzw. Weiterentwicklungen implementiert, müssen deshalb aufgrund der Integration in den Softwarequellcode verschiedene Quellcodes für Versionen für die unterschiedlichen Software-Plattformen überarbeitet und geupdatet werden.
Außerdem ist die Fehleranalyse und Fehlersuche durch die Integration in den maschinenlesbaren Softwarequellcode erheblich erschwert, da dieser Quellcode nicht unmittelbar von den Softwareentwicklern gelesen wer- den kann.
Ein weiterer Nachteil der Verwendung von in den Softwarequellcode integrierten Manöveranweisungsroutinen ist, dass diese ausprogrammiert einen erheblichen Umfang einnehmen können. Der Quellcode für die Definition der Berechnung bzw. Ausgabe der Manöveranweisungen kann mehrere zehntausend Zeilen umfassen, die bei einem Update komplett ausgetauscht werden müssen. Wird das Update per Datentransfer, beispielsweise per Internet, durchgeführt, müssen entsprechend große Datenmengen, von beispielsweise mehreren 100 Kilobyte oder einigen Megabyte, übertragen werden. Weiterhin nachteilig bei der Integration der Randbedingungen für die Berechnung bzw. Ausgabe der Manöveran-
Weisungen ist es, dass benutzerdefinierte Änderungen kaum möglich sind.
Ausgehend von diesem Stand der Technik ist es deshalb Aufgabe der vorliegenden Erfindung, ein neues Verfahren zum Betrieb eines Naviga- tionssystems vorzuschlagen, das die genannten Nachteile vermeidet.
Vorteilhafte Ausführungsformen der Erfindung sind Gegenstand der Unteransprüche.
Das erfindungsgemäße Verfahren beruht darauf, dass in dem Navigationssystem eine Konfigurationsdatei gespeichert ist, die vorzugsweise alle konfigurierenden Voreinstellungsdaten, die für die Berechnung und/oder Ausgabe der Manöveranweisung erforderlich sind, enthält. Vor und/oder auch während der Berechnung bzw. Ausgabe einer Manöveranweisung müssen diese Voreinstellungsdaten geladen und interpretiert werden. Erfindungsgemäß ist in dem Navigationssystem dazu ein Inter- pretationsmodul vorhanden, das die gespeicherten Voreinstellungsdaten aus der Konfigurationsdatei ausliest und interpretiert. So muss kein maschinenlesbarer Quellcode erzeugt werden, wie er beispielsweise von einem Mikroprozessor direkt verarbeitet werden kann. Dies bedeutet im Ergebnis also, dass die für die Berechnung und/oder Ausgabe der Manö- veranweisung erforderlichen Voreinstellungsdaten nicht mehr in den maschinenlesbaren Quellcode des Navigationssystems integriert sind, sondern als Daten in einer separaten Konfigurationsdatei gespeichert werden. Erst vor bzw. während der Berechnung bzw. Ausgabe der Manöveranweisung werden diese Voreinstellungsdaten durch das Interpretati- onsmodul ausgelesen und interpretiert.
Aus dem erfindungsgemäßen Verfahren ergibt sich eine Vielzahl von Vorteilen. Die in der Konfigurationsdatei gespeicherten Voreinstellungsdaten können erheblich leichter analysiert werden, so dass die Fehlersuche bzw. die Weiterentwicklung der Software vereinfacht wird. Außer- dem ist die Speicherung der Voreinstellungsdaten in der erfindungsge-
mäßen Konfigurationsdatei unabhängig von der verwendeten Software- Plattform. Dies bedeutet, dass bei Verwendung der Software auf einer anderen Software-Plattform lediglich das Interpretationsmodul ausgewechselt werden muss, wohingegen die Voreinstellungsdaten unverändert bleiben können.
Ein weiterer Vorteil liegt darin, dass die Voreinstellungsdaten durch die separate Speicherung in der Konfigurationsdatei erheblich stärker komprimiert werden können. Dadurch wird der erforderliche Datentransfer beim Update der Voreinstellungsdaten signifikant verringert.
Besonders vorteilhaft im Hinblick auf eine schnelle Abarbeitung zeitkritischer Prozesse ist es, wenn das Interpretationsmodul die Voreinstellungsdaten aus der Konfigurationsdatei ausliest, diese in einem zugriffsoptimierten Format in einem Speicher abspeichert und während der Berechnung und/oder Ausgabe der Manöveranweisung auf die im Spei- eher abgelegten Voreinstellungsdaten zugreift und diese interpretiert. Die Interpretation der im Speicher abgelegten Voreinstellungsdaten erfolgt also immer auf Bedarf hin, was Rechenleistung einspart.
Eine Optimierung im Hinblick auf den erforderlichen Speicherplatz ergibt sich dagegen, wenn das Interpretationsmodul die Voreinstellungs- daten während der Berechnung und/oder Ausgabe der Manöveranweisung ausliest und unmittelbar interpretiert. Eine Zwischenspeicherung zusätzlicher Daten entfällt dann.
In welcher Form die konfigurierenden Voreinstellungsdaten für die Berechnung und/oder Ausgabe der Manöveranweisung in der Konfigura- tionsdatei gespeichert sind, ist grundsätzlich beliebig. Besonders vorteilhaft ist die Speicherung in alphanumerischer Textform, da diese Textform von Menschen unmittelbar gelesen und interpretiert werden kann. Dies ist insbesondere bei der Fehlersuche und Weiterentwicklung von Navigationssoftware von Vorteil.
Für die einfache Ausführung des Navigationssystems bei der Berechnung bzw. Ausgabe der Manöveranweisung ist selbstverständlich eine Konfigurationsdatei ausreichend. Nach einer bevorzugten Verfahrensvariante sind jedoch mehrere Konfigurationsdateien im Navigationssystem ge- speichert, die jeweils verschiedene Voreinstellungsdaten enthalten.
Abhängig von bestimmten Randbedingungen kann das Navigationssystem dann entweder automatisch oder benutzerdefiniert eine der Konfigurationsdateien auswählen und vom Interpretationsmodul auslesen und interpretieren lassen. Im Ergebnis ist es also dadurch möglich, das Verhalten des Navigationssystems bei Berechnung bzw. Ausgabe der Manöveranweisungen in einfacher Weise durch Änderung der jeweils verwendeten Konfigurationsdatei zu beeinflussen.
So ist es beispielsweise denkbar, dass für unterschiedliche Nutzergruppen oder unterschiedliche Benutzerprofile jeweils verschiedene Konfigu- rationsdateien für die Ausführung der Manöveranweisungen gespeichert sind. Wird nun automatisch oder benutzerdefiniert das Vorhandensein einer bestimmten Nutzergruppe bzw. eines bestimmten Benutzerprofils festgestellt, so kann durch Auslesen und Interpretieren der jeweils zugeordneten Konfigurationsdatei das Verhalten des Navigationssystems bei der Berechnung bzw. Ausgabe der Manöveranweisung in einfacher Weise darauf angepasst werden.
Eine weitere Möglichkeit zur Verwendung von parallel zueinander gespeicherten Konfigurationsdateien besteht darin, dass die unterschiedlichen Konfigurationsdateien jeweils unterschiedlichen Nutzungsgebieten zugeordnet sind. Im Ergebnis kann dadurch erreicht werden, dass die Manöveranweisungen in unterschiedlichen Nutzungsgebieten, beispielsweise in unterschiedlichen Staaten, jeweils unterschiedlich und damit auf die landesspezifischen Gegebenheiten angepasst sind.
Weiter können auch mehrere Konfigurationsdateien für unterschiedliche Nutzungszeiten im Navigationssystem gespeichert sein. So ist es beispielsweise denkbar, das Verhalten bei der Berechnung bzw. Ausgabe der
Manöveranweisungen auf das Anforderungsprofil von Tag und Nacht anzupassen. Abhängig von der jeweiligen Nutzungszeit kann das Navigationssystem dann automatisch die jeweils zugeordneten Voreinstellungsdaten aus den unterschiedlichen Konfigurationsdateien laden und im Interpretationsmodul interpretieren lassen.
Im Normalfall wird die Konfigurationsdatei beim Hochfahren des Navigationssystems zumindest einmal ausgelesen, und die darin gespeicherten Voreinstellungsdaten werden durch das Interpretationsmodul ausgelesen und interpretiert. Die durch Interpretation erzeugten Voreinstellungsda- ten werden dann abgespeichert. Daneben ist es aber nach einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens auch denkbar, dass die Konfigurationsdatei während der Laufzeit des Navigationssystems erneut ausgelesen und fortan im Interpretationsmodul als neue Ablaufsteuerung verwendet wird. Die durch Interpretation neu erzeugten Voreinstellungsdaten ersetzen dann die zuvor verwendeten Voreinstellungsdaten, beispielsweise durch Überschreiben der entsprechenden Speicherbereiche. Im Ergebnis kann somit ein Update der Navigationssoftware, die Änderungen im Hinblick auf das Verhalten der Manöveranweisungen enthält, ohne Neustart des gesamten Navigationssystems ausgeführt werden. Auch das Neuladen verschiedener Alternativen von Konfigurationsdateien, beispielsweise für unterschiedliche Benutzergruppen bzw. unterschiedliche Benutzerprofile oder unterschiedliche Nutzungsgebiete bzw. unterschiedliche Nutzungszeiten, kann somit jeweils ohne Neustart des Navigationssystems durchgeführt werden.
Abhängig von der Komplexität der Software für die Berechnung bzw. Ausgabe der Manöveranweisung können die gespeicherten Voreinstellungsdaten einen durchaus erheblichen Umfang ausmachen. Um die Handhabung und Pflege dieser Daten zu vereinfachen, ist es deshalb vorteilhaft, wenn die Voreinstellungsdaten auf mehrere Konfigurations- teildateien verteilt sind. Die Verteilung der Voreinstellungsdaten auf mehrere Konfigurationsteildateien hat auch wiederum Vorteile im Hin-
blick auf Software-Updates, da Änderungen sich jeweils nur auf einzelne Konfigurationsteildateien beziehen können, so dass dann nur die jeweils betroffenen Konfigurationsteildateien ausgetauscht werden müssen.
Welche Art von Voreinstellungsdaten in den Konfigurationsdateien gespeichert ist, ist grundsätzlich beliebig. Nach einer bevorzugten Verfahrensvariante ist dabei vorgesehen, dass die gesamte Entscheidungslogik zur Bestimmung des zeitlichen Ablaufs der Ausgabe einer Manöveranweisungssequenz durch die Voreinstellungsdaten gesteuert wird. Im Ergebnis wird also das gesamte Verhalten des Navigationssys- tems bei der Berechnung bzw. Ausgabe der Manöveranweisung durch die Voreinstellungsdaten aus der Konfigurationsdatei gesteuert.
Die Entscheidungslogik zur Abarbeitung der Berechnung bzw. Ausgabe der Manöveranweisungssequenz kann dabei durch tabellarisch gespeicherte Ablaufschemen erfolgen. Diese Ablaufschemen beinhalten vor- zugsweise tabellarisch gespeicherte Textinformationen, die ein Ablaufschema determiniert abbilden. Diese tabellarisch gespeicherten Ablaufschemen können zur Fehleranalyse auch einfach durch geeignete Softwaremodule interpretiert und graphisch angezeigt werden. Zur Bestimmung einer Manöveranweisung können grundsätzlich drei Schritte durchgeführt werden. Im ersten Schritt wird ein Ablaufschema zum
Berechnen einer Grobklassifizierung einer Kreuzung bzw. eines Straßenverlaufs ausgewertet. Das Ablaufschema enthält dabei die Regeln und Entscheidungen, die zu treffen sind, und die Attribute, die zu vergleichen sind. In einem zweiten Schritt wird dann eine Entscheidungstabelle ausgewertet, die angibt, welche sprachabhängigen Ansagen unter welchen Bedingungen akustisch auszugeben sind. Diese Entscheidungstabelle ist dabei selbstverständlich sprachabhängig, so dass für jede vorhandene Sprache eine eigene Entscheidungstabelle angelegt werden muss. In einem dritten Schritt wird eine Entfernungstabelle ausgewertet, welche in Abhängigkeit der Grobklassifizierung und des Fahrzeugtyps bzw. in Abhängigkeit von der aktuell erlaubten Geschwindigkeit oder in Abhän-
gigkeit von der aktuellen Geschwindigkeit die Entfernung angibt, zu welcher die Ansage gesprochen wird.
Um diese dreistufige Bestimmung einer Manöveranweisung zu ermöglichen, sollte die Konfigurationsdatei neben einem tabellarisch gespeicher- ten Ablaufschema ein tabellarisch gespeichertes Entscheidungsschema und/oder ein tabellarisch gespeichertes Entfernungsschema umfassen.
Es zeigen:
Fig. 1 ein graphisch dargestelltes Ablaufschema zur Grobklassifizierung eines Straßenverlaufs;
Fig. 2 ein tabellarisch gespeichertes Ablaufschema, das dem Ablaufschema gemäß Fig. 1 entspricht;
Fig. 3 ein tabellarisch speicherbares Entscheidungsschema zur Auswahl von Manöveranweisungssequenzen;
Fig. 4 ein tabellarisch speicherbares Entfernungsschema.
Fig. 1 zeigt ein graphisch dargestelltes Ablaufschema 01 („FlowChart"), wie es zur Berechnung einer Manöveranweisung erforderlich ist. In den meisten Fällen ergibt die Grobklassifizierung das Ergebnis „IgnoreJunc- tion". Es wird also für das gerade analysierte Straßensegment dann keine Manöveranweisung generiert. Es ist z.B. üblich, bei einem Übergang von einem Straßenelement zu einem nachfolgenden Straßenelement entlang der Route dann, wenn es keine Möglichkeit gibt, eine andere Straße zu befahren, keine Manöveranweisung auszugeben.
In allen anderen Fällen wird eine Grobklassifizierung durchgeführt, wobei die Entscheidungslogik durch das in Fig. 1 graphisch dargestellte Ablaufschema 01 definiert ist. Um diese Entscheidungslogik in einfacher Weise alphanumerisch als Konfigurationsdatei abspeichern zu können, wird das Ablaufschema 01 in ein tabellarisch abspeicherbares Ablaufschema 02 umgewandelt, das in Fig. 2 dargestellt ist.
Erfindungsgemäß wird das in Fig. 2 dargestellte tabellarische Ablaufschema 02 als alphanumerische Textdatei im Navigationssystem gespeichert und beim Systemstart bzw. nach einem Update durch ein Interpretationsmodul ausgelesen und interpretiert.
Die Prüfungen gemäß dem Ablaufdiagramm 02 entsprechen Analysemodulen in der Routenführungseinheit, die die aktuell untersuchten Routensegmente sowie potentiell in der Umgebung liegende andere Segmente berücksichtigen und ein definiertes Ergebnis, das einem bestimmten Wahrheitswert entspricht, liefern. Abhängig von dem jeweiligen Wahr- heitswert kann mit dem Ablaufschema fortgefahren werden. So wird für jede Prüfung im Ablaufdiagramm als Nachbedingung definiert, welche Prüfung durchzuführen ist, wenn die Prüfung erfolgreich (ja) bzw. nicht erfolgreich (nein) ist. Zudem ist es auch möglich, dass lediglich eine Nachbedingung angegeben wird. Ist diese Nachbedingung beispielsweise „Destination", ist die Routenführung am Ende, und es gibt keinen Nachfolger.
Zum Beispiel kann eine Grobklassifizierung „Destination" (d.h. Ziel ist erreicht) erzielt werden, indem man im FlowChart über die Knoten Kl , K2, K3 , K4, K7, K8, K9 und Kl O läuft. Entsprechend der graphischen Aufbereitung des Ablaufschemas 01 (Fig. 1 ) wird die Entscheidungslogik tabellarisch im Ablaufschema 02 gespeichert.
Auf Basis der Grobklassifikation wird im Anschluss definiert, welcher Manöverhinweis akustisch ausgegeben wird. Die Zuordnung zwischen Grobklassifikation und Ansage wird dabei in einer separaten Entschei- dungstabelle 03 vorgenommen, die in Fig. 3 dargestellt ist.
Je nach Konfiguration des Navigationssystems können für unterschiedliche Sprachversionen unterschiedliche Entscheidungstabellen 03 vorgesehen sein. Auch ist es denkbar, dass die Entscheidungen über die Art der Ansage separat vom in der jeweiligen Sprache auszugebenden Text vorgehalten werden. Die Ansage, welche durch die Entscheidungstabelle
03 gefunden wird, kann zudem zu ersetzende Satzteile (Tags) beinhalten. Dies sind beispielsweise der aktuelle Straßenname, der Straßenname, welcher nach der Ansage erreicht wird, die Routennummer, wie z.B. „auf die A l ", Signpost-Informationen, die z.B. „in Richtung Stadtmitte" lauten, Entfernungsangaben, wie die Entfernung zur Ansage, und Richtungsangaben, wie die Richtung, die bei der Ansage eingeschlagen werden muss. Die in Fig. 3 dargestellte Entscheidungstabelle 03 spiegelt nur exemplarisch den möglichen Inhalt einer Entscheidungstabelle wider. Auch ist es möglich, dass für eine Grobklassifizierung keine gültige Zeile gefunden wird, da keine der Bedingungen erfüllt ist. In diesem Falle wird vorzugsweise keine Ansage generiert. Siehe hierzu das Beispiel zur Grobklassifizierung „PriorityManoeuver". Wenn der Fahrer auf der Vorfahrtstraße bleibt und geradeaus fährt, spricht keine der zwei Zeilen an. Es wird in diesem Falle also keine Ansage generiert.
Wird jedoch eine Ansage generiert, so sind die Tags, welche in spitzen Klammern stehen, noch auszufüllen. Im Beispiel zeigt die Grobklassifizierung PriorityManoeuver, in welcher Distanz die Vorfahrtsstraße verlassen wird. Ist das Fahrzeug mehr als eine vorkonfigurierbare Distanz, z.B. 700 Meter vom Aktionspunkt entfernt, so wird die Ansage unter „weit" verwendet und bei Erreichen der 700 Meter Marke gesprochen. Der Tag „Distanz" wird mit der ermittelten Distanz gefüllt und der Tag „Richtung" z.B. mit „rechts abbiegen" ausgefüllt. Daraus würde sich die Ansage „in 700 Metern rechts abbiegen und die Vorfahrtsstraße verlassen" ergeben.
In Fig. 4 ist eine Entfernungstabelle 04 beispielhaft dargestellt. In der Entfernungstabelle 04 wird für alle Grobklassifizierungen die Entfernung definiert, in welcher eine Ansage zu sprechen ist. Jede Grobklassifizierung besitzt dabei unterschiedliche Distanzen. Zum Beispiel kann es die Distanzen „ sehr weit", „weit", „nah" und „sehr nah" geben. Ergibt die Grobklassifizierung, dass man sich auf einer schnellen Straße befindet,
so sind die Distanzen hierfür entsprechend größer wählbar als bei einer Grobklassifizierung einer innerörtlichen Straße.
Die Entscheidungstabelle 04 wird analysiert und die Manöverausgabe dann vorgenommen, wenn die Positionierungseinheit des Navigationsge- räts anzeigt, dass von der aktuellen Position bis zu dem identifizierten Manöver die in der Entfernungstabelle konfigurierte Distanz vorhanden ist.
Dabei ist es grundsätzlich beliebig, ob die Analyse der Route vollständig nach der Routenberechnung durchgeführt wird und somit alle Ergebnisse der Routenführungseinheit im Speicher vorgehalten werden und in
Abhängigkeit der durch die Positionierungseinheit festgestellten Position abgerufen werden können, oder ob während der Fahrt entlang der Route die Analyse in der Routenführungseinheit durchgeführt wird und entsprechend ad hoc bzw. gepuffert die Anweisungen ausgegeben werden.
Das erfindungsgemäße Verfahren erlaubt die Erweiterung bekannter Navigationssysteme um folgende Optionen:
1. Wählbare Routenführungsstrategie: Dem Benutzer kann bei der Konfiguration seines Navigationssystems die Auswahl angeboten werden, nach welchen Motiven Manöveranweisungen erstellt wer- den sollen. So kann die Anzahl der Meldungen pro Manöver reduziert werden. Die Umsetzung dieser Option ist durch Verwendung des erfindungsgemäßen Verfahrens sehr einfach, indem für jede der vorgegebenen Optionen eine separate Konfigurationsdatei vorgehalten wird, die entsprechend von der Routenführungseinheit verwendet werden muss. Auch ein Wechsel der Strategie während einer laufenden Routenführung ist dabei denkbar, indem der noch nicht abgefahrene Teil der Route durch die neu konfigurierte Routenführungseinheit analysiert wird.
2. Updatefähigkeit: Auch ist durch das erfindungsgemäße Verfahren ein Aktualisieren bzw. Patchen der vorliegenden Routenführungsstrategie einfach durchführbar. Dazu müssen lediglich die Konfigurationsdateien ausgetauscht werden, was beispielsweise durch einen Download über das Navigationsgerät denkbar ist. Voraussetzung ist die Anbindung an einen Server, z.B. über das Internet oder drahtlos per WLAN bzw. UMTS .
3. Sprachunterstützung: Das erfindungsgemäße Verfahren erleichtert die Verwendung unterschiedlicher Sprachen. Auch die Ergänzung um weitere Sprachen ist mit dem erfindungsgemäßen Verfahren einfach möglich und erfordert keinen Austausch der kompletten Navigationssoftware. Lediglich eine Liste der momentan vorhandenen Sprache muss der Navigationssoftware bekannt sein, damit eine neue Sprache entsprechend angeboten werden kann.
Claims
1. Verfahren zum Betrieb eines Navigationssystems mit folgenden Verfahrensschritten: a) Berechnung einer Route von einem Startpunkt zu einem Zielpunkt, wobei die Route aus einer Folge von Streckensegmenten und Knotenpunkten zwischen den Streckensegmenten besteht, die mit einem Routenberechnungsverfahren aus einer Datenbank, in der ein geographisches Gebiet durch Streckensegmente und Knotenpunkte beschrie- ben ist, selektiert wird, b) Berechnung zumindest einer Manöveranweisung, die Anweisungen für den Benutzer enthält, um ausgehend vom aktuellen Standpunkt der Route zu folgen, c) optische und/oder akustische Ausgabe der Manöveranweisung an einer Ausgabeeinrichtung, dadurch gekennzeichnet, dass vor und/oder während der Berechnung und/oder Ausgabe der Manöveranweisung eine Konfigurationsdatei durch ein Interpretationsmodul ausgelesen und interpretiert wird, wobei in der Konfigura- tionsdatei konfigurierende Voreinstellungsdaten für die Berechnung und/oder Ausgabe der Manöveranweisung gespeichert sind.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass das Interpretationsmodul die Voreinstellungsdaten aus der Kon- figurationsdatei ausliest, danach die Voreinstellungsdaten in einem zugriffsoptimierten Format in einem Speicher abgespeichert werden, wobei das Interpretationsmodul während der Berechnung und/oder Ausgabe der Manöveranweisung auf die im Speicher abgelegten Voreinstellungsdaten zugreift und diese interpretiert.
3. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass das Interpretationsmodul während der Berechnung und/oder Ausgabe der Manöveranweisung die Voreinstellungsdaten ausliest und unmittelbar interpretiert.
4. Verfahren nach einem der Ansprüche 1 bis 3 , dadurch gekennzeichnet, dass die konfigurierenden Voreinstellungsdaten für die Berechnung und/oder Ausgabe der Manöveranweisung in der Konfigurationsdatei in alphanumerischer Textform gespeichert sind.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zumindest zwei verschiedene Konfigurationsdateien gespeichert sind, die automatisch oder benutzerdefiniert ausgewählt und vom In- terpretationsmodul ausgelesen werden.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass abhängig von der eingestellten Nutzergruppe oder abhängig vom eingestellten Benutzerprofil unterschiedliche Konfigurationsdateien vom Interpretationsmodul ausgelesen werden.
7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass abhängig vom Nutzungsgebiet unterschiedliche Konfigurationsdateien vom Interpretationsmodul ausgelesen werden.
8. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass abhängig von der Nutzungszeit unterschiedliche Konfigurationsdateien vom Interpretationsmodul ausgelesen werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Konfigurationsdatei während der Laufzeit des Navigationsprozesses ausgelesen wird, wobei die daraus vom Interpretationsmodul durch Interpretation erzeugten Voreinstellungsdaten die zuvor verwendeten Voreinstellungsdaten ersetzen.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Voreinstellungsdaten auf mehrere Konfigurationsteildateien verteilt sind, wobei alle Konfigurationsteildateien nacheinander aus- gelesen und interpretiert werden.
1 1. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass durch die Voreinstellungsdaten die Entscheidungslogik zur Bestimmung der Manöveranweisungssequenz, die aus einer Datenbank abgerufen und ausgegeben wird, definiert wird.
12. Verfahren nach einem der Ansprüche 1 bis 1 1 , dadurch gekennzeichnet, dass durch die Voreinstellungsdaten die Entscheidungslogik zur Bestimmung des zeitlichen Ablaufschemas (01 ) einer Manöveranwei- sungssequenz gesteuert wird.
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Konfigurationsdatei zumindest ein tabellarisch gespeichertes Ablaufschema (02, 03, 04) enthält.
14. Verfahren nach Anspruch 13 , dadurch gekennzeichnet, dass während der Generierung einer Manöveranweisung durch Auswertung des tabellarischen Ablaufschemas (02) eine Grobklassifizierung einer Kreuzung oder eines Straßenabschnitts auf der Route er- folgt.
15. Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass das tabellarisch gespeicherte Ablaufschema (02) mehrere Zeilen und mehrere Spalten umfasst, wobei jede Zeile einen Entscheidungs- knoten des Ablaufschemas repräsentiert.
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass j ede Zeile eine Bedingungszelle, die eine logische Bedingung aufweist, enthält.
17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass jede Zeile zumindest eine Verweiszelle aufweist, wobei die Verweiszelle die Sprungverweise auf andere Entscheidungsknoten enthält, und wobei bei Abarbeitung des tabellarischen Ablaufschemas (02) beginnend bei einer Startzeile jeweils die logische Bedingung der Bedingungszelle beantwortet wird und der der Antwort zugeordnete Sprungverweis aus der gleichen Zeile durchgeführt wird.
18. Verfahren nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass die Konfigurationsdatei zumindest ein tabellarisch gespeichertes Entscheidungsschema (03) enthält, wobei während der Generierung einer Manöveranweisung durch Auswertung des Entscheidungsschemas (03) die Auswahl der Manöveranweisungssequenz, die aus einer Datenbank abgerufen und ausgegeben wird, erfolgt.
19. Verfahren nach einem der Ansprüche 13 bis 18, dadurch gekennzeichnet, dass die Konfigurationsdatei zumindest ein tabellarisch gespeichertes
Entfernungsschema (04) enthält, wobei während der Generierung einer Manöveranweisung durch Auswertung des Entfernungsschemas (04) der zeitliche Ablauf der Ausgabe einer Manöveranweisungssequenz gesteuert wird.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102007053213A DE102007053213A1 (de) | 2007-11-06 | 2007-11-06 | Verfahren zum Betrieb eines Navigationssystems |
| PCT/DE2008/001626 WO2009059575A1 (de) | 2007-11-06 | 2008-10-09 | Verfahren zum betrieb eines navigationssystems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| EP2208024A1 true EP2208024A1 (de) | 2010-07-21 |
Family
ID=40386508
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EP08847125A Withdrawn EP2208024A1 (de) | 2007-11-06 | 2008-10-09 | Verfahren zum betrieb eines navigationssystems |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8457884B2 (de) |
| EP (1) | EP2208024A1 (de) |
| DE (1) | DE102007053213A1 (de) |
| WO (1) | WO2009059575A1 (de) |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5177685A (en) * | 1990-08-09 | 1993-01-05 | Massachusetts Institute Of Technology | Automobile navigation system using real time spoken driving instructions |
| US6199013B1 (en) | 1997-07-15 | 2001-03-06 | Navigation Technologies Corp. | Maneuver generation program and method |
| US6249720B1 (en) * | 1997-07-22 | 2001-06-19 | Kabushikikaisha Equos Research | Device mounted in vehicle |
| US6212474B1 (en) | 1998-11-19 | 2001-04-03 | Navigation Technologies Corporation | System and method for providing route guidance with a navigation application program |
| US6385542B1 (en) * | 2000-10-18 | 2002-05-07 | Magellan Dis, Inc. | Multiple configurations for a vehicle navigation system |
| DE10311336A1 (de) * | 2003-03-14 | 2004-09-23 | Siemens Ag | Elektronisches System, insbesondere ein elektronisches Informations- und/oder Kommunikationssystem eines Kraftfahrzeuges |
| DE102007036627A1 (de) * | 2007-08-02 | 2009-02-05 | Navigon Ag | Verfahren zum Betrieb eines Navigationssystems |
-
2007
- 2007-11-06 DE DE102007053213A patent/DE102007053213A1/de not_active Ceased
-
2008
- 2008-10-09 EP EP08847125A patent/EP2208024A1/de not_active Withdrawn
- 2008-10-09 WO PCT/DE2008/001626 patent/WO2009059575A1/de not_active Ceased
- 2008-10-09 US US12/741,326 patent/US8457884B2/en active Active
Non-Patent Citations (1)
| Title |
|---|
| See references of WO2009059575A1 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20110015855A1 (en) | 2011-01-20 |
| WO2009059575A1 (de) | 2009-05-14 |
| DE102007053213A1 (de) | 2009-05-07 |
| US8457884B2 (en) | 2013-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE60124157T2 (de) | Navigationsvorrichtung | |
| EP2507589B1 (de) | Verfahren zur vereinfachung einer beschreibung einer fahrtroute | |
| DE4429322A1 (de) | Navigationsverfahren für Kraftfahrzeuge | |
| DE10005780A1 (de) | Verfahren zur Routenplanung in einem Navigationssystem | |
| DE102012016768A1 (de) | Technik zum Verarbeiten kartographischer Daten für das Bestimmen energiesparender Routen | |
| DE102019002790A1 (de) | Verfahren zur Prädiktion einer Verkehrssituation für ein Fahrzeug | |
| EP2068123A2 (de) | Verfahren zum Betrieb eines Navigationsgeräts | |
| DE102019213836A1 (de) | Verfahren zum Betrieb eines Navigationssystems eines Kraftfahrzeugs, Kraftfahrzeug, Computerprogramm und elektronisch lesbarer Datenträger | |
| WO2023072466A1 (de) | Routenplanung für automatisierte fahrzeuge mit minimierung manueller eingriffe | |
| EP2997333B1 (de) | Verfahren zum betreiben eines navigationssystems, navigationssystem und kraftfahrzeug | |
| EP2208024A1 (de) | Verfahren zum betrieb eines navigationssystems | |
| DE102005058145B4 (de) | Verfahren zur optischen Ausgabe einer Vielzahl von auswählbaren Zielbegriffen | |
| DE102021108211A1 (de) | Informationenverarbeitungsvorrichtung, Anzeigesystem, Anzeigesteuerungsverfahren und nicht-transitorisches lesbares Medium | |
| EP4673705A1 (de) | Verfahren zum überprüfen einer beförderungsfahrt eines nutzers, sowie elektronisches beförderungsinformationssystem und computerprogramm | |
| EP2100097B1 (de) | Navigationseinrichtung | |
| DE102018217610A1 (de) | Verfahren zur Luftqualitätsoptimierung, Steuerung, Fahrzeug und System zur Durchführung des Verfahrens | |
| WO2018108462A2 (de) | Verfahren zum bereitstellen einer textbasierten beschreibung zumindest einer route für eine fahrt eines kraftfahrzeugs sowie steuervorrichtung und kraftfahrzeug | |
| DE102008052941A1 (de) | Verfahren zur Bestimmung von Kartenattributen | |
| DE102006013297B4 (de) | Verfahren zum Betrieb eines Navigationssystems | |
| DE102023206655B3 (de) | Verfahren und Assistenzsystem zur aktivitätsbasierten Navigationsunterstützung und entsprechend eingerichtetes Kraftfahrzeug | |
| EP1941239B1 (de) | Navigationssystem und Navigationsverfahren | |
| EP2040039B1 (de) | Routenbereitstellungsvorrichtung sowie Verfahren zum Betreiben einer solchen | |
| WO2015169420A1 (de) | Verfahren zum betrieb eines navigationssystems eines kraftfahrzeugs und kraftfahrzeug | |
| DE102019203638A1 (de) | Verfahren zur Berechnung einer Route unter Berücksichtigung von Parkmöglichkeiten | |
| EP1944576B1 (de) | Verfahren zum Aktualisieren von geographischen Daten |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
| 17P | Request for examination filed |
Effective date: 20100520 |
|
| AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR |
|
| AX | Request for extension of the european patent |
Extension state: AL BA MK RS |
|
| DAX | Request for extension of the european patent (deleted) | ||
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
| 18D | Application deemed to be withdrawn |
Effective date: 20130503 |