GB2416844A - Navigation device and method for exchanging data between resident applications - Google Patents

Abstract

Navigation software is integrated with other kinds of software running on the same device so that capabilities of the navigation software can be made available from within the other applications. Those applications can export street, city or postcode format address data to the navigation software. The address data can then be converted to a co-ordinate system based address by the navigation software, which can then automatically be set as the destination address used by the navigation software in calculating the route and/or automatically marked on a map generated and displayed by the navigation software. In a contacts application the contact record may include the facility to "navigate to" which when selected would automatically transfer the address to the navigator. The navigation software is also arranged to pass back geocoded, eg. W6C34, data to the other application. Similarly address data may be transferred from/to browser or messaging applications.

Description

NAVIGATION DEVICE AND METHOD FOR EXCHANGING DATA BETWEEN RESIDENT APPLICATIONS BACKGROUND OF THE INVENTION 1. Field of the invention This invention relates to a navigation device, such as GPS based receiver, that can display simulated navigati on data and a related method. The device find particular application as an in-car navigation system. Data can be exchanged between applications resident on the device. 2. Description of the prior art GPS based devices are well known and are widely employed as in-car navigation systems. Reference may be made to the Navigator series software from the present assignee, TomTom B.V. This is software that, when running on a PDA (such as a Compaq iPaq) connected to an external GPS receiver, enables a user to input to the PDA a start and destination address. The software then calculates the best route between the two end- oints and displays instructions on how to navigate that route. By using the positional information derived from the GPS receiver, the software can determine at regular intervals the position of the PDA (typically mounted on the dashboard of a vehicle) and can display the current position of the vehicle on a map and display (and speak) appropriate navigation instructions (e.g. 'turn left in 100 m'). Graphics depicting the actions to be accomplished (e.g. a left arrow indicating a left turn ahead) can be displayed in a status bar and also be superimposed over the applicable junctions/turnings etc in the roads shown in the map itself. Reference may also be made to devices that integrate a GPS receiver into a computing device programmed with a map database and that can generate navigation instructions on a display. The term 'navigation device' refers to a device that enables a user to navigate to a pre-defined destination. The device may have an internal system for receiving location data, such as a GPS receiver, or may merely be conncctable to a receiver that can receive locauon data. Reference may be made to WO 01/74037, in which a mobile wireless device with a GPS receiver, able to obtain longitude and latitude information, sends that information to a remote web server over a wireless network for reverse gcocoding - i.e. determining the street address from the latitude and longitude. That street address is then sent back to the wireless device over the wireless network to enable the device to display its location in street/city format. SUMMARY OF THE INVENTION In a first aspect, there is a navigation device programmed with a map database and navigation software that enables a route to be planned between two user-defined places, wherein the navigation software presents an open interface that is capable of being used by multiple applications resident on the device to allow the transfer of data to and/or from the navigation software. A core characteristic of the present invention is that the navigadon software presents an open interface to other applications resident on the device. Flence, those other applications can readily send data to the navigation software for that software to process and receive data from the navigation software. This enables various new and powerful techniques, some of which are described below. For example, the device can be programmed to be able to display a menu option that, if selected, causes the automatic export of street, city format or postcode format address data used by one of the applications resident on the device to the navigation software resident on the device for processing, the application enabling a user to use the address data for purposes other than navigation. By providing navigation software on the same device as the application with street, city or postcode format address data, and enabling export of that data from the application to the navigation software, it is possible for the device to rapidly process that data in new and useful ways. For example, selection of the menu option may initiate the conversion of the address data to a co-ordinate system based address by the navigation software, which can then automatically be set as the destination address used by the navigation software in calculating the route and/or automatically marked on a map generated and displayed by the navigation software. Further, the co-ordinate system based address may be automatically returned to the application (or a different application resident on the device) and stored as part of the data held by or accessible by that application. BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be described with reference to the accompanying drawings, in which Figure 1 is a screen shot from a navigation device implementing the present invention; the screen shot shows a plan map view and a status bar running along the bottom of the display; Figure 2 is a screen shot from the navigation device implementing a 3-D view; Figure 3 is a screen shot from the navigation device showing various route planning functions that enable a user to require the device to plot a new route to the destination that (l) is an alternative route; (11) avoids a roadblock immediately ahead; (iii ) avoids predefined roads or (lv) is a reversion to the original route; System Overview The present mvention is implemented in software from TomTom B.V. called Navigator. Navigator software runs on a touch screen (i.e. stylus controlled) Pocket PC powered PDA device, such as the Compaq iPaq. It provides a GPS based navigation system when the PDA is coupled with a GPS receiver. The combined PDA and GPS receiver system is designed to be used as an ln-vehicle navigation system. The invention may also be implemented in any other arrangement of navigation device, such as one with an integral GPS rcceiver/computer/display, or a device designed for non-vehicle use (e.g. for walkers) or vehicles other than cars (e.g. aircraft). The navigation device may implement any kind of position sensing technology and is not limited to GPS; it can hence be implemented using other kinds of GNSS (global navigation satellite system) such as the European Galileo system. F,qually, it is not hmited to satellite based location/velocity systems but can equally be deployed using ground-based beacons or any other kind of system that enables the device to determine its geographic location. Navigator software, when running on a PDA, results in a navigation device that causes the normal navigation mode screen shown in Figure 1 to be displayed. This view provides driving instructions using a combination of text, symbols, voice guidance and a moving map. Key user mtcrface elements are the following: a 2-D map 1 occupies most of the screen. The map shows the user's car and its immediate surroundings, rotated in such a way that the direction m which the car is moving is always "up". Running across the bottom quarter of the screen is the status bar 2. The current location of the device, as the device itself determines using conventional GPS location finding and its orientation (as inferred from its direction of travel) is depicted by an arrow 3. The route calculated by the device (using route calculation algorithms stored in device memory as applied to map data stored in a map database in device memory) is shown as darkened path 4 superimposed with arrows giving the travel direction. On the darkened path 4, all major actions (e.g. turning corners, crossroads, roundabouts etc.) are schematically depicted by arrows 5 overlaymg the path 4. The status bar 2 also includes at its left hand side a schematic 6 depictmg the next action (here, a right turn). The status bar 2 also shows the distance to the next action (i.e. the right turn - here the distance is 220 meters) as extracted from a database of the entire route calculated by the device (i.e. a list of all roads and related actions defining the route to be taken). Status bar 2 also shows the name of the current road 8, the estimated time before arrival 9 (here 2 mmutes and 40 seconds), the actual estimated arrival time 10 (11.36am) and the distance to the destination 11 (1.4Km). The GPS signal strength is shown in a mobile-phone style signal strength indicator 12. If the user touches the centre of the screen 13, then a navigation screen menu is displayed; from this menu, other core navigation functions within the Navigator application can be initiated or controlled. Allowing core navigation functions to be selected from a menu screen that is itself very readily called up (e.g. one step away from the map display to the menu screen) greatly simplifies the user interaction and makes it faster and easier. The area of the touch zone which needs to be touched by a user is far larger than in most stylus based touch screen systems. It is designed to be large enough to be reliably selected by a single finger without special accuracy; i.e. to mimic the real-life conditions for a driver when controlling a vehicle; he or she will have htde time to look at a highly detailed screen with small control icons, and still less time to accurately press one of those small control icons. Hence, using a very large touch screen area associated with a given soft key (or hidden soft key, as in the centre of the screen 13) is a deliberate design feature of this implementation. Unlike other stylus based applications, this design feature is consistently deployed throughout Navigator to select core functions that are likely to be needed by a driver whilst actually driving. Hence, whenever the user is given the choice of selecting on-screen icons (e.g. control icons, or keys of a virtual keyboard to enter a destination address, for example), then the design of those icons/keys is kept simple and the associated touch screen zones is expanded to such a size that each icon/key can unambiguously be finger selected. In practice, the associated touch screen zone will be of the order of at least 0.7 cm<2>and wdl typically be a square zone. In normal navigation mode, the device displays a map. Touching the map (i.e. the touch sensitive display) once (or twice in a different implementation) near to the screen centre (or any part of the screen in another implementation) will then call up a navigation menu (see Figure 3) with large icons corresponding to various navigation functions, such as the option to calculate an alternative route, and re-calculate the route so as to avoid the next section of road (useful when faced with an obstruction or heavy congestion); or recalculate the route so as to avoid specific, listed roads. The actual physical structure of the device itself may be fundamentally no different from any conventional handheld computer, other than the integral GPS receiver or a GPS data feed from an external GPS receiver. Hence, memory stores the route calculation algorithms, map database and user interface software; a microprocessor interprets and processes user input (e.g. using a device touch screen to input the start and destination addresses and all other control inputs) and deploys the route calculation algorithms to calculate the optimal route. 'Optimal' may refer to criteria such as shortest time or shortest distance, or some other user-related factors. More specifically, the user inputs his start position and required destination in the normal manner into the Navigator software running on the PDA using a virtual keyboard. The user then selects the manner in which a travel route is calculated: various modes are offered, such as a 'fast' mode that calculates the route very rapidly, but the route might not be the shortest; a 'full' mode that looks at all possible routes and locates the shortest, but takes longer to calculate etc. Other options are possible, with a user definmg a route that is scenic - e.g. passes the most POI (points of interest) marked as views of outstanding beauty, or passes the most POIs of possible interest to children or uses the fewest junctions etc. Roads themselves are described in the map database that is part of Navigator (or is otherwise accessed by it) running on the PDA as lines - i.e. vectors (e.g. start point, end point, direction for a road, with an entire road being made up of many hundreds of such sections, each uniquely defined by start point/end point direction parameters). A map is then a set of such road vectors, plus points of interest (POIs), plus road names, plus other geographic features like park boundaries, river boundaries etc, all of which are defined in terms of vectors. All map features (e.g. road vectors, POIs etc.) are defined in a co-ordinate system that corresponds or relates to the GPS co-ordinate system, enabling a device's position as determined through a GPS system to be located onto the relevant road shown in a map. Route calculation uses complex algorithms that are part of the Navigator software. The algorithms are applied to score large numbers of potential different routes. The Navigator software then evaluates them against the user defined criteria (or device defaults), such as a full mode scan, with scenic route, past museums, and no speed camera. The route which best meets the defined criteria is then calculated by a processor in the PDA and then stored in a database in RAM as a sequence of vectors, road names and actions to be done at vector end-points (e.g. corresponding to pre-determined distances along each road of the route, such as after 100 meters, turn left into street x). A core characteristic of Navigator is that it presents an open interface to other applications resident on the device. Hence, those other applications can readily send data to Navigator software for Navigator t[upsilon] process and receive data from Navigator. This enables various new and powerful techniques, some of which are described below. Gcocoding The Navigator software is programmed with the WGC84 (or other co-ord system) coordinates of roads and house numbers along a road. Flence, when a user defines a start or destination street/city or postcode address as part of the normal route planning process, the software determines the associated WGC84 co-ordinates (this process is called 'gcocoding'); it can then also mark the start and destination positions on the maps it can display with appropriate icons. Navigator can share this gcocoding capability with other applications (e.g. make it seamlessly and automatically available from within those applications). Integration between Navigator and Contacts Application It is possible to auto-generate an option, displayed within a contacts application running on the device, to navigate to that contact within the Navigator program. Flence, when viewing a contact record in the contacts application, one of the available menu items is a function 'navigate to': if selected, this automatically opens the Navigator software, causes the export of the street, city or postcode format address used in the contacts application to Navigator, which then geocodes that contact address and automatically sets that geocoded contact address as the destination. As a further example, it is possible to show the location of the contact address on the maps displayed by Navigator: an option 'show on map' may hence be selected for a given contact address from within the contacts application. If selected, then the contact address, in street, city or postcode format, is exported to the Navigator software, which then geocodes it and displays on a map it generates a suitable icon at the appropriate location. This icon can be annotated with suitable information (e.g. contact name and address; possibly a thumbnail photo image of the contact). Pass back of geocoded data Navigator software also enables WGC 84 (or other co-ordinate) system data to be added automatically to a street/city etc. address in a contacts application or other application by using the co-ordinate system knowledge of the integrated Navigator navigation program. The user can, from within the contacts application, select a 'geocodc address' function to be performed in relation to a specific address (or a bulk group of addresses). The contacts appUcation hence exports the contact address from the database used by it (in house number, street, city format or postcode format) to the engine in the Navigator software that converts addresses expressed in these formats to WGC84 co-ordinates. Tins engine then determines the WGC84 co-ordinates and returns that WGC84 data to a new field in the database used by the contacts application - the new field stores and makes available the WGC84 data within the contacts application (or indeed other applications, not only running on the device but also resident on remote devices). Being able to automatically add a geo-coded location (e.g. the WGC 84 format location) of an address to the normal street, city etc. format address stored in (or otherwise accessible by) a contacts application is very powerful because many location based services will use geo-coded data. I'or example, business cards in vCard format often include an address in street, city format. With the present invention, a vCard received via e-mail or short range wireless etc. by the device can be processed by the device extracting the street address and sending that for geo-coding by the resident Navigator appUcation; the geo-coded data can then be returned to the contacts database storing the vCard data to augment that data. This can facilitate many kinds of location based services that rely on geo-coded data; for example, nnagine that the vCard recipient is a sales person and the vCard is from a customer; after the vCard address has been geo-coded, the device will have (and can download to a server) a geo-coded database of all customer contacts. Then, it will be far simpler to implement future activities that rely on accurate knowledge of customer locations, such as making service calls or deUvenng goods, since this will often be done usmg software that requires geo-coded data. Integration between Navigator and a Messaging AppUcation As another example, presence data will become a pervasive characteristic of personal mobile communications; a mobile telephone user's presence data defines the status of that user across many parameters (e.g. whether contactable by voice, data, SMS etc; current activity; current mood; physical or logical (e.g. work; home) location etc.). Presence data may be widely accessible to third parties; this enables in theory someone to determine the location of a friend etc. whose presence derived location data they have access to and can see (typically in a messaging application). But that location data will often be in a geo-coded format - interpreting a geo-coded address is inherently difficult for people. With the present implementation, real-time geo-coded data incoming to a device can be passed uirough to the Navigator software on that device for display on a map generated by Navigator. This makes locating the person straightforward. In addition, Navigator can also reverse geo-code - namely, determine the associated street, city etc, format from input geo-coded data. Then, if the user is interested in viewing the presence data, he can also see a normal street, city format location address (generated by the Navigator software by reverse gcocoding) as well. This can be included as an annotation to the POI marking the location on the Navigator generated map of the location of the person whose presence data has been obtained. That annotation can also clude other k ds of presence data (e.g. mood, current activity etc.). Integration between Navigator and a Browser Application Navigator software functionaUty can be integrated with a browser running on the device as follows: when the device displays a web page (or other kmd of mark up language page) that includes an address in street, city or in postcode format, a user can readily take that address and send it to the Navigator software for it to display a map showmg the actual location. This can be done with a browser plug-in that allows a user to select the address in the web page (e.g. highlight it); a drop down menu can then be selected. This menu mcludes the options 'Show location in Navigator' and 'Drive to this location'. Selecting the 'Show location in Navigator' option causes the automatic export of the address to Navigator, which then geocodes it and displays a map indicating the actual location. Selecting the 'Drive to this location' option causes the automatic export of the address to Navigator, which then geocodes it and uses the geocoded address as the destination address to calculate a route.

Claims (10)

1. [Lambda] navigation device programmed with a map database and navigation software that enables a route to be planned between two user-defined places, wherein the navigation software presents an open interface that is capable of being used by multiple appUcations resident on the device to allow the transfer of data to and/or from the navigation software.

2. The device of Clanri 1 in which the navigation software makes available its geocoding capability to at least one of the applications by receiving non-geocoded location data from that application; deriving cort csponding geocoded location data and returning that geocoded location data to the application.

3. The device of Claim 1 in which the navigation software makes available a reverse geo-coding capability to at least one of the applications by receiving geocoded location data from that application; deriving corresponding non-geocoded location data in street, city format and returning that street, city format location data to the appUcation.

4. The device of Claim 1 in which one of the applications resident on the device is a contacts appUcation.

5. The device of Claim 1 in which one of the applications resident on the device is a browser application.

6 The device of Claim 1 in which one of the applications resident on the device is a messaging application.

7. The device of Claim 6 in which the location data is part of presence data.

8. The device of Claim 4 programmed to display a menu option to navigate to an address in the contacts application and selecting that option automatically deploys the navigation software and sets the address as the destination address.

9. The device of Claim 1 programmed to display a menu option to show on a map an address in the contacts appUcation and selecting that option automatically deploys the navigation software and causes the location of the address to be indicated on a map.

10. A method of displaying navigation information, the method being deployed in a device programmed with a map database and navigation software that enables a route to be planned between two user-defined places, the method comprising the step of using an open interface that is capable of being used by multiple appUcations resident on the device to allow the transfer of data to and/or from the navigation software.