DE102013201930A1 - Method for data processing of navigation device, involves storing card data of digital card in memory, where data set is provided with predicted location or predicted link that is determined depending on position by movement model - Google Patents

Abstract

The method involves storing a card data of a digital card in a memory (SP1), where a data set is provided with a predicted location or a predicted link. The predicted location or predicted link is determined depending on a position by a predetermined movement model. A subset of the card data is selected depending on the data set and is assigned to a partial card data quantity. The partial card data quantity is stored in another memory (SP2), where the latter memory has a faster access time than the former memory. An independent claim is included for a device for data processing of a navigation device.

Description

The invention relates to a method and a corresponding device for data processing of a navigation device.

In modern navigation systems, ever larger amounts of additional information are displayed on a map. As a result, ever larger amounts of data are transmitted, which can lead to delays in the presentation of a display of the navigation device.

The object on which the invention is based is, on the one hand, to provide a method and, on the other hand, a device for data processing of a navigation device, which contributes to enabling a fluid representation on a display of the navigation device.

The object is solved by the features of the independent claims. Advantageous embodiments are characterized in the subclaims.

The invention is characterized on the one hand by a method and on the other hand by a corresponding device for data processing of a navigation device. In a first memory, map data of a digital map is stored. A data record is provided which has at least one predicted location and / or a predicted connection determined as a function of a position by means of a movement model. Depending on the record, a subset of the map data is selected and assigned to a submap data set. The partial map data set is stored in a second memory, the second memory having a faster access time than the first memory.

The map data in this context represent data required by the navigation device for creating and displaying a map with additional information on traffic, topography and the like. In this case, the map data can also be stored on one or more elements of the first memory which are separate from one another. For example, the first memory can have a first memory element, such as a hard disk, on which parts of the map data are stored and have a second memory element, such as a CD and / or DVD and / or another hard disk, on which further parts of the map data are stored are.

The data record represents at least one predicted location and / or connection that the user of the navigation device is likely to visit.

Depending on this data set, therefore, part of the map data which is likely to be needed shortly may be loaded into the first memory. Thus, this submap data set may be readily available when needed. Thus, it can be helped to prevent delays in the display on a display of the navigation device.

According to an advantageous embodiment, the sub-map data quantity for a map display required data. Such data may be, for example, data needed for basic calculation and / or display, such as rendering information and / or a terrain model and / or building locations and / or satellite imagery. Thus, important data needed for map display and / or map calculation can be loaded faster when needed.

According to a further advantageous embodiment, the part-card data set has data for signaling additional information on a card to be signaled. Thus, additional information such as information on important points on the map and / or traffic information and / or traffic signs can be loaded into the faster second memory so that they can be loaded faster when needed.

According to a further advantageous embodiment, the predicted location and / or the predicated connection is determined by means of a predetermined multimodal motion model.

The multimodal motion model is intended for various modalities, such as running, cycling, using a motor vehicle, such as a car or a motorcycle or a truck. Further, the modalities may include the use of a train, a tram, a bus, a ship, an airplane, a wheelchair, a lift, an escalator, and the like.

In this case, the multimodal movement model can each comprise a subset of the modalities and / or resources, the subset in particular comprising at least two different modalities. Thus, through the multimodal motion model, several modalities can be used in determining the predicted location and / or the predicted connection.

According to a further advantageous embodiment, the movement model is determined depending on a navigation route. For example, the movement model can be adjusted as soon as a navigation route has been entered.

According to a further advantageous embodiment, the provided data record has data which is representative of a location information associated with the predicted location and / or a connection information associated with the predicted connection. The partial map data set additionally comprises a part of the data of the data record. Thus, data may be loaded into the second faster memory that is directly associated with the predicted location and / or the predicated connection, thereby potentially being of particular interest to the user. Such information is, for example, information such as a curve radius and / or a slope and / or a traffic sign.

Embodiments of the invention are explained in more detail below with reference to the schematic drawings.

Show it:

1 a control device, a first memory and a second memory,

2 a flow chart for data processing of a navigation device,

3 various elements to explain a multimodal movement model,

4 a flow chart for creating the multimodal motion model and

5 Units by which a predicted location and / or a predicated connection is determined.

Elements of the same construction or function are identified across the figures with the same reference numerals.

1 shows a control device SV and a first memory SP1 and a second memory SP2. The control device SV has a computing unit, a data and program memory and at least one interface, with which it is signal-wise coupled to the first memory SP1 and / or the second memory SP2 for transmitting and receiving data. Furthermore, the control device SV can be signal-coupled with a display unit, not shown, for transmitting data to the display unit. The control device SV is for example in a navigation device 11 and / or in a vehicle 3 (please refer 3 ) arranged. Basically, she can be stuck in the vehicle 3 However, it can also be arranged, for example, in a mobile terminal 5 , such as a smartphone or the like.

The control device SV can also be referred to as a device for operating a navigation device.

The second memory SP2, seen from the control device SV, has a faster access time than the first memory SP1. The second memory SP2 is, for example, a main memory of the navigation device 11 or the control device SV. The first memory SP1 is, for example, a hard disk and / or a CD and / or a DVD and / or a memory of a server, which is connected to the control device SV, for example by means of a wireless radio link. The first memory SP1 is designed, for example, as a structural unit, but it may alternatively be distributed over two or more structural units.

Map data KD is stored in the first memory SP1. The map data KD in this context represent the navigation device 11 data needed to create and display a map with additional information on traffic topography and the like. The map data KD can in this case also be stored on the one or more modules of the first memory SP1. For example, part of the map data KD may be stored on a hard disk of the navigation device 11 and a further part of the map data KD on a CD and / or DVD and / or another hard disk, which is installed, for example, in a server, which is connected to the navigation device by means of a wireless radio link 11 is coupled.

For data processing of the navigation device 11 is in the data and program memory of the control device SV preferably at least one program stored during the operation of the navigation device 11 can be processed. The program is described below with reference to the flowchart of 2 explained in more detail.

The program, which is executed in the control device SV, is started in a step S1 in which variables can be initialized, if necessary.

In a step S3, a data record DS is provided, which at least one depends on a position by means of a predetermined Movement model determined predicted location and / or has a predicated connection. For example, the predicated location is a location that the user of the navigation device 11 probably wants to visit. The predicated connection is, for example, a connection that is the user of the navigation device 11 probably uses, such as a stretch of road.

In a step S5, depending on the data set DS, a subset of the map data KD stored in the first memory SP1 is selected. Since the data record DS has a predicted location and / or a predicated connection that is a user of the navigation device 11 Probably, for example, a subset of the map data KD needed to calculate and / or display a map in a predetermined area around the predicted location and / or the predicated connection may be selected. Optionally, the predetermined range and / or the subset may be predetermined by the memory size of the second memory SP2 and or by a maximum predetermined amount of data. Optionally, the subset may also be restricted to certain contents of the map data KD. For example, only additional information, such as information on traffic and / or points on the map can be selected and / or only important data required for the calculation and / or display of the map, such as rendering information and / or terrain information and / or the like can be selected ,

In a step S7, the subset of the map data KD is assigned to a sub map data set TD.

In a step S9, the partial map data amount TD is stored in the second memory SP2.

In a step S11, the program is ended and may optionally be restarted in step S1.

In this way, the partial map data set TD, which for example has data for signaling additional information on a signaled card and / or data required for map display, can be stored in the second memory SP2, which has a faster access time. The sub-map data set TD can in this case be, for example, data for rendering the map and / or a terrain model and / or building information and / or satellite imagery and / or information on important points and / or traffic information and / or traffic signs and / or other data required for map display and / or or have data required for additional information.

3 shows various elements for explaining a multimodal motion model by means of which, alternatively or additionally, the predicted location and / or the predicated connection are determined. In the 3 designated 1 a backend server. Further, the vehicle 3 available and the mobile terminal 5 , which is designed in particular as a smartphone and a user of the vehicle 3 assigned. Basically, you can also use several mobile devices 5 be provided, for example, the various users of the vehicle 3 , ie persons, are assigned.

The backend server 1 has at least one communication interface via which it can communicate with at least one other component. So also points the vehicle 3 as well as a communication interface on which, for example, with the backend server 1 can communicate.

The vehicle 3 has a vehicle sensor system, for example, a position determination unit 7 may include, for example, GPS-based, and / or a gyrometer 9 or other vehicle sensors. In addition, in the vehicle 3 also the navigation device 11 arranged. The navigation device 11 is for example also the position determination unit 7 assigned and they can also communicate with other vehicle sensors. In the navigation device 11 For example, the control device SV is arranged.

The mobile device 5 , which is designed in particular as a smartphone, for example, includes a further position determination unit 13 and / or an acceleration sensor 15 , In this way it is designed to capture its position, in particular quasi-continuously.

The mobile device 5 also includes a communication interface, which may be, for example, a mobile radio interface, via the position data of the mobile terminal 5 and associated time data can be transmitted, in particular to one or more location-based services 17 , Also the respective location-based service 17 It has a communication interface via which it can communicate directly or indirectly with the communication interface of the mobile device 5 can communicate. Examples of such location based services are Google Latitude, Gowalla, Foursquare, Qype, Geoloqi, and Facebook Places. For example, Google Latitude is designed to allow access to a user's tracks receives and focuses on positions and their history.

Gowalla, Foursquare, Qype, Geoloqi and Facebook Places provide access to check-ins and context information such as location descriptions of the user. Such location-based services may provide additional access to a check-in history of friends.

Google Calendar provides a broad range of interaction opportunities related to events, contacts, and places.

The location-based services also have a communication interface to the respective mobile terminal 5 also a communication interface, via the location-based service tuple comprising position data and associated time data related to the respective user can be retrieved. In this context, for example, they have a respective API that can be addressed using REST and can also be represented using Atom or JSON. In addition, most location-based services also provide libraries for php, C #, and Java.

In this respect, provision of respective location-based service tuples is, for example, with the backend server 1 just possible. Typically, authorization must be established to connect to the location-based service and retrieve corresponding location-based service tuples. For example, in the case of web services, this can be done using OAuth2.

Determining the multimodal motion model, which by means of the flowchart of the 4 will be explained in more detail below, for example, in the control device SV and / or the backend server 1 respectively. Alternatively or additionally, however, this can also be distributed to one or more of the set of the control device SV, the backend server 1 , of the vehicle 3 and the mobile terminal 5 respectively. Thus, for example, in particular individual steps to this only on the mobile device 5 or in the vehicle 3 , how, for example, are processed in the control device SV, which may be desirable, for example, with regard to data protection considerations and / or privacy protection of the respective user.

Furthermore, in the case of multiple users of the vehicle 3 also several corresponding mobile terminals associated therewith 5 be present and related to the respective user related data from the mobile terminal 5 to the respective location-based services 17 be transmitted.

A flow diagram of a program for exemplary realization of determining the movement model is based on 4 and will be explained in more detail below. It is whole or distributed in respective data and program memories of the control device SV, the back-end server 1 and / or the navigation device 11 and / or the mobile terminal 5 saved. As part of the program, the multimodal movement model is created, which is a personal movement model of the user of the vehicle 3 includes.

The program is started in a step S21 in which variables can be initialized if necessary.

In a step S23, tuples TUP are provided relative to a respective user, which include position data and associated time data relative to the respective user. Thus, vehicle sensor-based tuples are provided in this context.

Further, location based service tuples are provided by at least one of the location based services. These also include position data and associated time data relative to the respective user. In this context, the location-based service tuples may also include information about check-ins, attributes of the places the user visits, contacts, current friends, notes, and even appointments.

In particular, in step S23, corresponding tuples TUP relative to the respective user are provided for a suitably selected, in particular longer, period. This period can, for example, include several days or even several weeks or several months.

Check-ins provide feedback on which positions the user actually wants to be. In addition, they lead to a certain semantics in the sense that one knows in which kind of place the user is, which name is to be assigned to the place and how often he is at this place. One-time check-ins can be classified as of little importance. In addition, however, it should be taken into account that a user might forget to check in or make it just before leaving the respective place and so there is no indication of an arrival time and length of stay. Calendar entries, contact information, and friends' positions can be used to decide whether the user wants to meet someone in a particular location, which can be used to great advantage in non-routine prediction within the movement model.

In this way, a plurality of tuples TUP can thus be provided in the step S25.

In a step S27, the information contained in the tuples TUP is cleaned up and the information is merged.

For this purpose, it is assumed, for example, that vehicle-sensor-based tuples TUP are already cleared and are thus adapted to the road network, for example, using so-called map matching techniques. Parking positions can be extracted, for example, using so-called clustering methods (such as DJ clustering). In this context, for example, park cluster tuples are determined as a function of at least one parking indicator determined on the vehicle side. Such a parking indicator may, for example, be a state of an acceleration sensor 15 of the vehicle 3 be, or other operating variables of the vehicle 3 that are representative of the vehicle itself 3 located in a parking position. Thus, for example, an inactive state of the position determination unit 7 of the vehicle 3 to be a parking indicator. For example, where the parking indicator represents a park state when the position determination unit 7 is inactive for a given sleep duration threshold.

In principle, as part of the cleanup of the tuples TUP those tuples TUP are discarded which have position data with a larger accuracy radius, ie a higher degree of inaccuracy, than a tuple TUP with almost the same time data. Thus, for example, those location-based service tuples that are timed to vehicle sensor-based tuples during a ride on the vehicle are discarded 3 correspond.

Further, those location-based service tuples are discarded whose position data has a precision radius greater than a predetermined inaccuracy threshold. The accuracy radius is so representative of a maximum inaccuracy of the respective position data. The predetermined inaccuracy threshold may be, for example, 800 m.

Further, based on respective location-based service tuples, a minimum distance is determined depending on their distance to temporally adjacent tuples based on their respective position data minus a sum of the accuracy radii of the respective tuples associated with the respective position data. Those location-based service tuples are discarded whose consideration in the case of a movement trajectory to be determined based on a plurality of tuples TUP results in the minimum distance assigned to them falling below a predetermined minimum distance value.

In addition, in step S27, those location-based service tuples are discarded whose consideration in a motion trajectory to be determined based on several tuples implies a speed of the user above a predetermined speed threshold and / or an acceleration of the user above a predetermined acceleration threshold and related to tuples TUP with temporally adjacent time data.

The predetermined speed threshold may be, for example, 300 km / h. The predetermined acceleration value can be, for example, 3.2 × 10 ⁵ km / h ² .

Further, those location-based service tuples based on check-in are discarded and in which a distance based on the respective position data between the respective check-in based location-based service tuple and a further tuple within a given time window is larger is a predetermined check-in distance value where the additional tuple is the one closest to the location-based service tuple based on the respective check-in.

In a step S29, stops are determined on the basis of the tuples TUP remaining after the processing of step S27, specifically with regard to determining the respective destination point of the user. Thus, location-based service tuples based on check-ins are classified as candidate stop tuples. There are location-based service tuples that have a given spatial relationship with respect to their position data and have no temporally adjacent tuples outside the given spatial relationship but with a time interval less than a stop distance threshold to a candidate stop cluster tuple summarized.

Subsequently, a dominant stop tuple is then determined as a function of a candidate stop residence time and / or after accumulation of the cardiac stop tuple. The candidate stop duration may be determined, for example, in the context of clustering the respective tuple in determining the respective candidate stop clusters. Optionally, for location-based service tuples based on check-ins, a duration of stay is also associated with the respective tuple TUP. Basically, for example, a density-based clustering is done in this context.

The respective determined dominant stop tuple can then represent a target position of the respective movement trajectory of the user.

The respective dominant stop tuple is assigned, based on the associated movement trajectory, a park cluster tuple and thus a link is established between the two, thus containing the information which parking position the user has visited in this case with regard to the target position represented by dominant stop tuple.

In addition, a parking time duration is preferably determined and assigned to the respective park cluster tuple depending on the assigned movement trajectory and the dominant stop tuple.

Furthermore, in the course of determining the movement trajectory, a respective mode of transport, ie modality, is preferably determined for respective sections of the respective movement trajectory as a function of data of the tuples. In this context, for example, typical movement pattern or other sensor signal characteristics can be used for the respective means of transportation. In principle, this can also be done, for example, by using data from the acceleration sensor 15 of the mobile terminal 5 consequences. In addition, it can be used in this context, for example, that when using underground public transport during their use regularly no satellite-based position determination is possible due to a lack of the corresponding signal, such as the GPS signal.

In a step S31, the personal movement model is then created using the data prepared in steps S27 and S29 ie the non-thrown tuple, the determined movement trajectories, the determined candidate stop residence times, and also using the time information that can be assigned to the respective movement trajectory For example, the time duration from the starting point of the respective movement trajectory to the target point, represented by the dominant stop tuple.

Furthermore, the creation of the personal movement model also takes place using the other historical information which can be derived from the time data of the tuple TUP, for example with respect to the respective days of the week, which can be assigned to the determined movement trajectories, and / or the respective time of day, that of the respective movement trajectory is assignable.

In addition, for different users of a particular vehicle 3 appropriate personal movement models are created and these are then used with respect to the respective vehicle 3 related to all its users.

The respective personal movement models can also be created according to a variety of modalities, with examples of the modalities are: running, so in various forms, such as running, walking, hiking, strolling and the like, cycling, driving a car, such a private or renting a car, riding a motorcycle, driving a truck, driving a train, tram and the like, driving a bus, driving a ship, flying with an airplane, driving a wheelchair, using a lift, using an escalator and the like.

The respective personal movement models determined in this way, also taking into account the various modalities, are preferably fused to form a multimodal movement model, this also especially with regard to a respective resource, such as a vehicle, a bicycle, an airplane and the like, but also the respective ones Person can be done.

In this connection, unless already explained above, a multiplicity of data sources can be used, which in particular include the user's electronic calendar or calendars, recorded movement profiles, for example of a smartphone, a vehicle and the like, location-based services, databases of locations of Interest, also referred to as Points of Interest, digital road map data for motor vehicles, bicycles and / or pedestrians, maps of buildings, digital data relating to air and / or ship routes, public transport timetables and the like.

For example, the multimodal motion model is in the backend server 1 saved. However, it can in principle also in the vehicle 3 and / or the mobile terminal 5 be stored completely or partially.

Based on 5 are represented units which can form parts or the whole of a prediction system in this connection and on which a corresponding prediction method can proceed. Such is a server 21 provided, for example, the backend server 1 may be, but also arranged or trained otherwise. On the server 21 the multimodal motion model is stored and used there to predict one or more predicted locations and associated location information. In addition, by means of the multimodal movement model also in this context or multiple predicted connections are determined to the one or more predicted locations.

This is done in each case starting from a position provided in this context. This can also be done depending on a time assigned to the respective position.

Starting from the respective position and, if appropriate, the assigned point in time, one or more locations can then be predicted by means of the multimodal movement model, in which context a predefined time horizon can be taken into account, that is to say those possible locations can be predicted which start from the point in time Time horizons are possible predicted places. The prediction can be done arbitrarily, that is, for example, based on one or different resources in the above sense. In this context, corresponding probability information can also be taken into account in the frame of the prediction. In this context, prediction algorithms can be used which are used, for example, in learning navigation systems.

In addition, corresponding calendar entries can also be used automatically to determine the predicted location (s). In this context, in prediction, a corresponding classification of respective clusters into working days, weekends, days, time of day and night time and also the time during the day can be used to provide suitable temporal information for the prediction.

In addition, the prediction may also include a prediction of a predictive schedule using the multimodal motion model. The predicted locations determined in the context of the prediction, the assigned location information and also the one or more predicted connections to the one or more predicted locations and the associated connection information are then provided in the form of a data record DS in each case. They are so in particular over an interface 25 provided.

In this context, for example, the data set DS can be offered via an Internet service, for example in an XML or JSON format. the interface 25 can also be realized using a so-called client API.

With the reference number 23 is in the 5 a client, where the client 23 especially external to the server 21 can be trained, but does not have to be. The client 23 is formed, for example, in the control device SV, so that these via the interface 25 one or more requests to the server 21 can send. The client 23 may, for example, alternatively or additionally in the mobile terminal 5 be educated. However, he can in principle also in the vehicle 3 or any other location. The client 23 is designed in this context, via the interface 25 one or more requests to the server 21 to send.

In this context, an authentication is preferably required, which can be carried out in particular in the context of an authentication process, in the context of which, for example, a user name and a password must be transmitted in particular. In return, the corresponding client receives, for example, a time-based authentication token. This authentication token must then be present for all requests to the server 21 to be provided. Authentication can also be used on multiple sessions, also referred to as sessions. In particular, a status in this context can also be a prediction on the server 21 be followed. In this way, data protection requirements can be met.

In particular, various queries are provided, which may be designed, for example, as functions or methods, for example, in the context 27 a selection of possible such requests shown. Examples of such methods or functions are:
getMobilityHorizon (), getProperties (), getRessources (), updateHorizon ().

The method getMobilityHorizon () has transfer parameters, which may include, for example, the position include the time and / or a selection of the type of location information and / or connection information and / or a corresponding horizon parameter specifying over which period the prediction should occur and / or whether a selection of the predicted places to be returned or of the predicted location and / or the predicted connections should be made with regard to the probability information that is representative of a probability that a respective predicated connection is used or another probability information that is representative of that the predicted location is also taken by the respective resource.

In addition, an identifier of the respective resource or of the respective resources is also passed as a parameter with respect to which the data record DS is requested. The requested data set DS represents in this context a so-called mobility horizon.

The respective predicted location can be identified by corresponding position information, for example. The data set DS, which, as explained above, can also be referred to as a mobility horizon, comprises in particular an identification of the respective resource or of the respective resources with respect to which it is output. In addition, the mobility horizon preferably also includes time stamp information for which the mobility horizon is generated. In addition, it also includes a starting position, which may also be a set of starting positions, especially if it is not clear, due to corresponding inaccuracies, which is the exact starting position.

The structure of the data set DS is in this context such that it can be represented in particular in the form of a graph. It thus comprises the respective predicted locations, which are identified in particular by a location identification and include associated location information, such as the respective location position, and / or a list of all resources that are at the predicted location and / or a description of the location using, for example a name, an address and the like. For example, the location information may also include a list of possible outgoing calls. In addition, it may also include information regarding the respective predicted subordinate locations, such as meeting rooms within a building or floors within a building. In addition, the location information may also include the further probability information representative of the presence of the respective resource at the respective predicted location. In addition, other information may be assigned as location information.

Furthermore, the data record DS may preferably also comprise one or more predicted connections to the one or more predicted locations, which may be represented in particular by a corresponding identification. The respective predicted connection is associated with corresponding connection information in this context. The connection information may be, for example, a period of time required to reach its end by means of the respective predicated connection from its assigned start. In addition, the connection information may also include the respective resource. It may also include the probability information representative of a probability that the respective predicated connection will be used. In addition, the connection information may also include other information. Such other information regarding the predicated connection may also include so-called profiles as used in Advanced Driver Assistance Systems (ADAS) protocols. A specific implementation provides z. For example, the ADASIS v2 protocol.

Thus, a curve profile and / or a slope profile and / or a speed can thus be included. Furthermore, such other information may also be representative of a weather and / or an availability of mobile radio connections. However, it may also alternatively or additionally represent costs of the predicted connections. Such costs may be, for example, tolls, but they may also be vehicle costs, and / or corresponding usage fees.

For example, by the method getproperties (), this can be done by the client 23 over the interface 25 which type of location information and / or connection information is to be selectively provided. As a return, a list of those types of location information and / or connection information can be returned, which in fact via the interface by means of the respective modal movement model for this case 25 can be provided.

By means of the method getRessources (), it is thus possible, for example, to transfer which types of resources or which named-named resources, such as a specific person, from the client 23 over the interface 25 be requested. The return is then a corresponding list of resources which, based on transfer parameters, actually exist in the respective modal movement model and can thus be returned.

Using the updateHorizon () method, an updated position is passed as a parameter, which is particularly representative of where a resource has moved. In addition, it includes an identification of the mobility horizon, a so-called main identification, which was previously requested or returned using the getMobilityHorizon () method. Optionally, a corresponding period of time can also be transferred, after which in each case an updated mobility horizon at the client 23 over the interface 25 should be returned.

The transfer of the above updated position is optional.

In response to the method updateHorizon () then returns the corresponding mobility horizon in the form of the respective data set DS via the interface 25 , In this way, a corresponding update can be made without much effort.

LIST OF REFERENCE NUMBERS

1

backend server

3

vehicle

5

mobile terminal

7

Position Determination Entity

9

gyro

11

navigation device

13

further position determination unit

15

accelerometer

17

location-based service

21

server

23

client

25

interface

27

frame

DS

record

KD

map data

SP1

first memory

SP2

second memory

SV

control device

S1 to S33

steps

TD

Part map data set

TUP

tuple

Claims (7)

Method for data processing of a navigation device ( 11 ), in which map data (KD) of a digital map are stored in a first memory (SP1), - a data set (DS) is provided which has at least one predicted location and / or one predicted connection determined by a predetermined movement model in that, depending on the data record, a subset of the map data (KD) is selected and assigned to a sub map data set (TD), - the sub map data set (TD) is stored in a second memory (SP2), the second memory (SP2) being a faster Access time than the first memory (SP1). The method of claim 1, wherein the partial map data set (TD) comprises data needed for map display. Method according to Claim 1 or 2, in which the part-card data set (TD) has data for signaling additional information on a signaled card. Method according to one of the preceding claims, in which the predicted location and / or the predicated connection is determined by means of a predetermined multimodal motion model. Method according to one of the preceding claims, in which the movement model is determined as a function of a navigation route. Method according to one of the preceding claims, in which the provided data record (DS) comprises data representative of a location information associated with the predicted location and / or connection information associated with the predicated connection and the partial map data set (TD) additionally a portion of the data of the data set (DS). Device for data processing of a navigation device ( 11 ), wherein the device is associated with a first memory (SP1) in which map data (KD) of a digital map are stored and to which a second memory (SP2) is assigned, the device being adapted to a method according to one of the claims 1 to perform 6.

Images