CA2219037C - Interface layer for navigation system - Google Patents

Interface layer for navigation system Download PDF

Info

Publication number
CA2219037C
CA2219037C CA002219037A CA2219037A CA2219037C CA 2219037 C CA2219037 C CA 2219037C CA 002219037 A CA002219037 A CA 002219037A CA 2219037 A CA2219037 A CA 2219037A CA 2219037 C CA2219037 C CA 2219037C
Authority
CA
Canada
Prior art keywords
data
navigation
programming
navigation application
geographic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
CA002219037A
Other languages
French (fr)
Other versions
CA2219037A1 (en
Inventor
Richard A. Ashby
Paul M. Bouzide
Vijaya S. Israni
David S. Lampert
Senthil K. Natesan
Grant S. Killey
John C. Jasper
Robert P. Fernekes
Jerry S. Feigen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Navteq Corp
Original Assignee
Here Global BV
Navigation Technologies Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Here Global BV, Navigation Technologies Corp filed Critical Here Global BV
Publication of CA2219037A1 publication Critical patent/CA2219037A1/en
Application granted granted Critical
Publication of CA2219037C publication Critical patent/CA2219037C/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09BEDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
    • G09B29/00Maps; Plans; Charts; Diagrams, e.g. route diagram
    • G09B29/10Map spot or coordinate position indicators; Map reading aids
    • G09B29/106Map spot or coordinate position indicators; Map reading aids using electronic means
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3863Structures of map data
    • G01C21/387Organisation of map data, e.g. version management or database structures
    • G01C21/3878Hierarchical structures, e.g. layering
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29Geographical information databases
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968Systems involving transmission of navigation instructions to the vehicle
    • G08G1/0969Systems involving transmission of navigation instructions to the vehicle having a display in the form of a map
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99932Access augmentation or optimizing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface

Abstract

An improved method and system that provides for a data access interface layer in a navigation system. The navigation system is of the type that includes a navigation application software program that provides navigating features to a user of the system and a geographic database stored on a computer-readable storage medium wherein the geographical database includes information relating to the geographical region about which the navigation system provides the navigation features to the user. The data access interface layer is preferably stored in the navigation system as a library of software functions. The data access interface layer operates in conjunction with the navigation system application software. The data access interface layer isolates the navigation application software from the geographic data which are stored on the storage medium. The data access interface layer intercepts requests by the navigation application software for geographic data. The data access interface layer retrieves geographic data from the storage medium and converts the data into a format usable by the navigation application software. The data access interface layer also provides for memory management that facilitates accessing and using geographic data from the particular storage medium quickly and efficiently. By recognizing that different media types have different physical formats, the data access interface layer accommodates and isolates the differences so that the portions of the data access interface layer that interact with the navigation application software can be generic.

Description

2 FOR NAVIGATION SYSTEM
3
4 The present application relates to navigation systems and in particular, 11 the present application relates to a navigation system interface layer that 12 facilitates use and access of a geographic database stored on a physical storage 13 medium.
14 Computer-based navigation systems for use on land have become available in a variety of forms and provide for a variety of useful features.
One 16 exemplary type of navigation system uses ( 1 ) a detailed data set of one or more 17 geographic areas or regions, (2) a navigation application program, (3) 18 appropriate computer hardware, such as a microprocessor, memory, and storage, 19 and, optionally, (4) a positioning system. The detailed geographic data set portion of the navigation system is in the form of one or more detailed, 21 organized data files or databases. The detailed geographic data set may include 22 information about the positions of roads and intersections in or related to one or 23 more specific geographic regional areas, and may also include information 24 about one-way streets, turn restrictions, street addresses, alternative routes, hotels, restaurants, museums, stadiums, offices, automobile dealerships, auto 26 repair shops, etc.
27 The positioning system may employ any of several well-known 28 technologies to determine or approximate one's physical location in a 29 geographic regional area. For example, the positioning system may employ a GPS-type system (global positioning system), a "dead reckoning"-type system, 1 or combinations of these, or other systems, all of which are well-known in the 2 art.
3 The navigation application program portion of the navigation system is a 4 software program that uses the detailed geographic data set and the positioning system (when employed). The navigation application program may provide the 6 user with a graphical display (e.g. a "map") of the user's specific location in the 7 geographic area. In addition, the navigation application program may also 8 provide the user with specific directions to locations in the geographic area 9 from wherever the user is located.
Some navigation systems combine the navigation application program, 11 geographic data set, and optionally, the positioning system into a single unit.
12 Such single unit systems can be installed in vehicles or carried by persons.
13 Alternatively, navigation application programs and geographic datasets may be 14 provided as software products that are sold or licensed to users to load in their own personal computers. In further alternatives, the navigation system may be 16 centrally' or regionally located and accessible to multiple users on an "as 17 needed" basis, or alternatively, on-line via a network or communications link.
18 Personal computer-based systems may be stand-alone systems or may utilize a 19 communication link to a central or regional or distributed system. Also, users may access a navigation system over an on-line service such as the Internet, or 21 over private dial-up services, such as CompuServe, Prodigy, and America 22 Online. In-vehicle navigation systems may use wireless communication 23 connections. Navigation systems may also be used by operators of vehicle 24 fleets such as trucking companies, package delivery services, and so on.
Navigation systems may also be used by entities concerned with traffic control 26 or traffic monitoring.
27 Computer-based navigation systems hold the promise of providing high 28 levels of navigation assistance to users. Navigation systems can provide 29 detailed instructions for travelling to desired destinations, thereby reducing travel times and expenses. Navigation systems also can provide enhanced 31 navigation features such as helping commuters and travellers avoid construction 1 delays and finding the quickest routes to desired destinations. Navigation 2 systems can also be used to incorporate real-time traffic information.
3 In order to provide these useful and enhanced features in a navigation 4 system, there is a need to gather and organize comprehensive, detailed, reliable, and up-to-date data about geographical regions and areas. There is also a need 6 to continuously update the geographic data since many data can rapidly become 7 out-of date. Presently, the collection of such geographic data and the provision 8 of such data in a computer-usable format are provided by Navigation 9 Technologies of Sunnyvale, California.
One potential problem associated with providing enhanced features and 11 updated geographic databases for navigation systems is that there are numerous 12 different navigation system platforms. These platforms may have different 13 hardware, navigation software, operating systems, and so on. Many of these 14 different platforms have developed independently and are incompatible with each other. Thus, even if it were possible to gather updated geographic data 16 and produce an updated computer-readable geographic database, it becomes 17 difficult to provide and distribute geographic databases that can be used with 18 the various different types of navigation system platforms due to the numerous 19 different platforms that exist. This problem may be exacerbated in the future as navigation system manufacturers develop new generations of navigation systems 21 with more and enhanced features.
22 Another problem exists with regard to providing updated geographic 23 data for existing navigation systems. Just like conventional printed maps, 24 geographic information used in computer-based navigation systems can become out-of date. For example, new roads are built, businesses change locations, 26 road construction closes roads, detours are established, museum and restaurant 27 hours change, etc. It is expected that end-users, such as vehicle owners who 28 have navigation systems in their vehicles, will want to have the geographic data 29 in their navigation systems updated from time to time.
The proliferation of multiple, different, incompatible navigation system 31 platforms, mentioned above, also presents an obstacle to providing updated 32 geographic data for end-users, i.e. the persons and businesses who own and use 1 navigation systems. In order to provide updated geographic data for an end-2 user's navigation system over the lifetime of the navigation system, the provider 3 of geographic data needs to provide a product that not only has updated 4 geographic data, but also that is compatible with the user's particular navigation system. Over the expected lifetime of navigation systems, which may be ten 6 years or more, this would require supporting a growing number of old, 7 incompatible navigation systems and platforms. If specialized versions of 8 updated geographic data products had to be produced for each separate, 9 different type or version of navigation platform, the number of different products would continue to increase over time thereby making the provision of 11 updated geographic data products to end-users difficult and expensive.
12 Accordingly, it is an object of the present invention to provide a solution 13 to the problem of providing geographic data for a variety of hardware 14 platforms.
Further, it is an object of the present invention to provide an improved 16 navigation system and geographic navigation databases) for use therein, that 17 can be efficiently developed, manufactured, customized, distributed, and/or 18 updated across a variety of navigation system platforms, operating systems, and 19 releases.

22 To achieve the foregoing and other objectives and in accordance with 23 the purposes of the present invention, there is provided an improved method 24 and system for a data access interface layer in a navigation system. The navigation system is of the type that includes a navigation application software 26 program that provides navigating features to a 'user of the system and a 27 geographic database stored on a computer-readable storage medium wherein the 28 geographical database includes information relating to the geographical region 29 about which the navigation system provides the navigating features to the user.
The data access interface layer is preferably stored in the navigation system as a 31 library of software functions. The data access interface layer operates in 32 conjunction with the navigation system application software. The data access i interface layer isolates the navigation application software from the geographic 2 data which are stored on the storage medium. The data access interface layer 3 intercepts requests by the navigation application software for geographic data.
The data access interface layer retrieves geographic data from the storage s medium and converts the data into a format usable by the navigation application 6 software, The data access interface layer also provides for memory 7 management that facilitates accessing and using geographic data from the particular storage medium quickly and efficiently. By recognizing that different 9 media types have different physical formats, the data access intertace Layer to accommodates and isolates the differences so that the portions of the data 11 access intertace layer that interact with the navigation application software can 12 be generic.
z3 In accordance with the first aspect of the invention there is provided a i4 computer program product for use in a navigation system wherein the navigation a.5 system includes a navigation application program that provides navigating 16 features to a user of the navigation system and a geographic database stored i ~ on a physical storage medium in a computer-readable physical storage format, 18 the computer program product comprising an interface layer comprising an 19 interface layer located logically between the navigation application program and 2 o the geographic database, the interface layer comprising programming for:
21 accepting and processing requests for geographic data from the navigation 22 application program; and decompressing geographic data from the physical 2 3 storage format and providing the geographic data to the navigation application 24 program in a decompressed format.
2 5 In accordance with a second aspect of the invention there is provided a 2 6 method of using a computer-based navigation system wherein the navigation 2 ~ system includes navigation application program functions wherein the navigation 2s application program functions are adapted to use a geographic database stored 2 9 on a computer readable storage medium in a physical storage format, the 3 o method comprising: reading a metadata file from the storage medium;
storing a 31 portion of the metadata file in memory; accepting a request from one of the 32 navigation application program functions for geographic data; transforming
- 5 -1 geographic data stored in the physical storage format into a format usable by the 2 navigation application including using the metadata file to translate from a 3 version level of the physical storage format to a version level of the navigation 4 application program functions; and providing the transformed geographic data to the one of the navigation application program functions.
s In accordance with a third aspect of the invention there is provided in a navigation system that includes application programs that provide navigation-s related functions, wherein the navigation system uses geographic data stored on a computer readable medium, interface layer programming comprising: a query 1 o subsystem that accepts requests for geographic data from the application 1 i programs and provides responses thereto; an indexes management subsystem 12 that identifies a location of data on the medium at which is located data required 13 to respond to the requests received by the query subsystem; a physical-to-1~ logical subsystem that transforms data read from the medium into a format used is in the responses; and a resources management subsystem that provides access i 6 to memory resources and I/O of the navigation system for use by the 1 ~ subsystem, the indexes management subsystem, and the physical-to-logical 1 s subsystem.
19 In accordance with a fourth aspect of the invention there is provided in a 2 o navigation system having navigation application programs and that uses 21 geographic data stored on a physical storage medium in a computer-readable 22 physical storage format, an improvement comprising: an intertace layer that 23 defines a first set of calls that can be used by the navigation application 24 programs to access a set of geographic data entities on the physical storage 25 medium, wherein the set of geographic data entities includes one of: a single 2 s entity, a fist of multiple entities, and no data entities, and further wherein the 2 ~ geographic data entities in the set of geographic data entities accessed by the 28 navigation application programs using the intertace layer inform to a logical 29 data model which has a decompressed fomnat, and wherein the intertace layer 3 o accepts calls that allow the navigation application programs to formulate queries 31 for data, and wherein the calls may be qualified by spatial and non-spatial 32 attributes of desired entities, and wherein the attributes used to qualify a query 5a 1 for data can be used singly or in combination and can specify a range or a single 2 value, and further wherein the geographic data on the physical storage medium 3 include spatially organized data, non-spatially organized data, and index data, 4 and wherein the spatially organized data comprises data that represent s segments of roads, and wherein the spatially organized data are organized into parcels which contain the geographic data entities representing geographic 7 features encompassed within physical geographical localities within a s represented geographic region, and wherein the non-spatially organized data 9 comprise data representing names of navigable features, and wherein the index to data include indexes that relate the spatially organized data and non-spatially l organized data to each other.
12 Further features and advantages of the invention will be apparent from 13 the detailed description which follows together with the accompanying drawings.

is BRIEF DESCRIPTION OF THE DRAWINGS
16 FIG. 1 is a diagram illustrating a navigation system including a storage 17 medium upon which geographical data, and optionally other data, are stored.
18 FIG. 2 is a diagram illustrating the software components in the navigation 19 system of FIG.1.
2 o FIG. 3 is a block diagram illustrating the software components of the 21 navigation system of FiG. 1 including the major systems of the interface layer of 22 FIG. 2.
23 FIG. 4 is a block diagram illustrating one embodiment of the resource 24 manager software architecture of FIG. 3.
2s FIGS. 5A and 5B are illustrations representing memory storage during 2 s operation of the cursor management system show in FIG. 3.
2~ FIG. 6 is an example illustrating a parcel ID used in the physical address 2s storage mapperof FIG. 4.
29 FIG. 7 is a flow diagram illustrating the process for linking the navigation 3 o application component with the data interface layer.
31 FIG. 8 is a block diagram illustrating another embodiment of the resource 32 manager software architecture of FIG. 3.
5b 3 I. Overview of navigation system 4 Referring to FIG. 1, there is a diagram illustrating an exemplary configuration of a navigation system 10. The navigation system 10 is a
6 combination of hardware and software components. In one embodiment, the
7 navigation system 10 includes a processor 12, a drive 14 connected to the
8 processor 12, and a memory storage device 16, such as a ROM, for storing a
9 navigation application software program 18. The navigation application software program 18 is loaded from the ROM 16 into a memory 20 associated 11 with the processor 12 in order to operate the navigation system. The processor 12 12 may be of any type used in navigation systems, such as 32-bit processors 13 using a flat address space, such as a Hitachi SH1, an Intel 80386, an Intel 960, 14 a Motorola 68020 (or other processors having similar or greater addressing space). Processor types other than these, as well as processors that may be 16 developed in the future, are also suitable. A storage medium 22 is installed in 17 the drive 14. In one present embodiment, the storage medium 22 is a 18 CD-ROM. In another alternative embodiment, the storage medium 22 may be a 19 PC Card (PCMCIA card) in which case the drive 14 would be substituted with a PCMCIA slot. Various other storage media may be used, including fixed or 21 hard disks, DVD (digital video disks) or other currently available storage 22 media, as well as storage media that may be developed in the future. The 23 storage medium 22 includes geographic data.

27 The navigation system 10 may also include a positioning system 24.
28 The positioning system 24 may utilize GPS-type technology, a dead reckoning-29 type system, or combinations of these, or other systems, all of which are known in the art. The positioning system 24 outputs a signal 26 to the processor 12.
31 The signal 26 may be used by the navigation application software 18 that is run 32 on the processor 12 to determine the location, direction, speed, etc., of the 33 navigation system 10. The navigation system 10 uses the geographic data 1 stored on the storage medium 22, possibly in conjunction with the output 26 2 from the positioning system 24, to provide various navigation application 3 features. These navigation application features may include route calculation, 4 map display, vehicle positioning (e.g. map matching), maneuver generation (wherein detailed directions are provided for reaching a desired destination), 6 and other features. These navigation application features are provided by 7 navigation application programs (i.e. subprograms or functions) that are part of 8 the navigation application software program 18. The navigation features are 9 provided to the user (e.g., the vehicle driver) by means of a display 27, speakers 29, or other means.
11 Referring to FIG. 2, the navigation application software program 18 12 includes separate applications (or subprograms) 200. The navigation application 13 programs 200 of the navigation system 10 may be regarded as including route 14 calculation functions, maneuver generation functions, map display functions, vehicle positioning functions, destination resolution capabilities, and so on.
16 FIG. 2 shows these separate navigation applications 200 including a route 17 calculation function 28, a map display function 30, a maneuver generation 18 function 32, and other functions or subprograms 34. Although these navigation 19 application subprograms are represented as separate functions or applications within the navigation application software program 18, these functions may be 21 combined and provided as a single program.
22 In FIG. 2, the storage medium 22 is shown to have geographic data 40 23 stored on it. The geographic data 40 are in the form of one or more computer-24 readable data files or databases. The geographic data 40 may include information about the positions of roads and intersections in or related to a 26 specific geographic regional area, and may also include information about one-27 way streets, turn restrictions, street addresses, alternative routes, hotels, 28 restaurants, museums, stadiums, offices, automobile dealerships, auto repair 29 shops, etc. The geographic data 40 are organized in a format and stored on the storage medium 22 in a manner that facilitates use and access by the navigation 31 application functions 200 of the navigation application program 18. The 32 organization and storage of the geographic data 40 are described in more detail _7_ 1 in the above referenced copending application entitled "IMPROVED SYSTEM

3 PHYSICAL MEDIA."
4 The various separate navigation applications 200 of the navigation application software 18 access and read portions of the geographic data 40 from 6 the storage medium 22 in order to provide useful navigation features to the user 7 of the navigation system 10. In a present embodiment, a data access interface 8 layer 41 is located between the various navigation applications 200 (such as the 9 functions 28, 30, 32, and 34) and the geographic dataset 40. The data access interface layer 41 isolates the navigation application functions 200 from the 11 formatting, storage, and other details of the geographic data 40.
Accordingly, 12 the data access interface layer 41 provides for various different navigation 13 system platforms to use a common geographic database product, i.e. the 14 geographic dataset 40 stored on the storage medium 22. In addition, the data access interface layer 41 facilitates allowing an end-user to update the 16 geographic data in the end-user's navigation system.
17 II. Data access interface layer - overview 18 The data access interface layer 41 is a software component that may 19 reside in the navigation system 10. In a preferred embodiment, at least a portion of the data access interface layer 41 is linked or compiled into the 21 executable module that forms the navigation application software 18 in the 22 navigation system 10 that is loaded into the memory 20 (FIG. 1 ) from the ROM
23 16 when the navigation system 10 is operated. Within the data access interface 24 layer 41 there are several subsystem components. There are internal interfaces between these subsystem components and external interfaces to the navigation 26 application software components 200 and operating system 202 of the 27 navigation system 10. Data are presented to the navigation applications as 28 logical data entities. The logical data model entity records are fixed length and 29 contain decompressed data without any of cross-reference information.
In a preferred embodiment, the data access interface layer 41 is provided 31 in the form of a library of software functions. This library of functions _g_ _ CA 02219037 1997-10-23 1 provides data access for use by the various components or subprograms 200 of 2 the navigation application software program 18. In one preferred embodiment, 3 some or all of these library functions are directly linked to the various 4 navigation applications 200 to form the navigation software product 18.
Thus, the data access interface layer 41 is incorporated into the navigation application 6 software of the navigation systems of OEM's (original equipment 7 manufacturers) or aftermarket automotive navigation systems, which use a 8 separately stored geographic database. In alternative embodiments, discussed 9 below, the data access interface layer 41 may be incorporated into other-than-in-vehicle navigation systems.
11 In a preferred embodiment, the source code is written in the C
12 programming language, although in alternate embodiments, other languages 13 may be used.
14 Because the data access interface layer 41 is used with various different navigation systems, the interface layer 41 takes into account differences among 16 these systems. Some in-vehicle navigation systems have relatively small 17 quantities of RAM, slow I/O devices, and proprietary and/or real-time-oriented 18 operating system kernels. Some of these navigation systems calculate an 19 optimal route and provide real-time, turn-by-turn guidance to the end-user.
Accordingly, it is advantageous to integrate various position and heading sensor 21 information in real-time and in the background. Some of these navigation 22 systems also provide cartographic display, a flexible capability to obtain route 23 destination points, and an interface oriented to in-vehicle ergonomics.
24 As mentioned above, the data access interface layer 41 isolates the navigation application software 18 from the size, complexity, and evolution of 26 the geographic map database 40 on the physical medium 22. In a preferred 27 embodiment, similar or identical data access interface layers can used by 28 different navigation systems. The data access interface layer 41 is portable 29 across different hardware platforms. The data access interface layer 41 provides versatility to support most or all envisioned navigation application 31 functionality for a wide range of product capabilities and hardware platforms.
32 In a preferred embodiment, the software library that comprises the data access 1 interface layer uses less than 256 K bytes of memory and 16 Kbytes of stack 2 memory, and at least 256 Kbytes of heap memory.
3 As mentioned above, the geographic data 40 is stored on the storage 4 device 22, such as a CD-ROM.

8 The features used in the physical storage format provide 9 for efficient access to the geographic data and associated third party data ("TPD"). Different types of storage media have distinct data capacities and 11 access characteristics. Accordingly the physical storage format features 12 disclosed in the copending application account for the various media intended 13 for use in navigation systems. Although the present embodiment of the data 14 access interface layer 41 uses the physical storage format disclosed in the copending application, some or all of the features of the data access interface 16 layer disclosed herein may be used with other formats.
17 As described in the copending application, the geographic data are stored 18 on the medium by means of a geographic dataset compiler. The compiler 19 accepts geographic data and associated third party data in an interchange format. The geographic data and third party data are input to the compiler 21 which generates an output in the form of an appropriate physical storage 22 format. The geographic data may be published by Navigation Technologies of 23 Sunnyvale, California.
24 FIG. 3 is a block diagram of the navigation system 10 showing components of the data access interface layer 41. In FIG. 3, the data access 26 interface layer 41 is shown in the navigation application software 18 logically 27 below the navigation application programs 200 and above the operating system 28 202. This allows the data access interface layer 41 to be responsive to data 29 access requests from the various navigation application software programs 200.
The software library that forms the data access interface layer 41 may be 31 regarded as being composed of three major subsystems. The topmost 32 subsystem is the data access programming interface query logic ("DQL" or
-10-_ CA 02219037 1997-10-23 1 "query logic") subsystem 210. The query logic subsystem 210 provides a 2 function call interface 212 to the navigation application software programs 200.
3 The data access interface layer 41 defines a data structure view (referred to as 4 the "Logical Data Model" or "LDM") of the geographic data 40 on the storage medium 22 to the navigation application programs 200.
6 In a presently preferred embodiment, the data structure view defined by 7 layer 41 is in the C-language. As mentioned above, the logical data model 8 represents the entities in fully decompressed form. The entities in the logical 9 data model form are not compacted. Although this results in wasted space within data entities, it facilitates immediate use of the data entities by the
11 navigation application. Each of the data entities of a given type may have a
12 fixed, known predetermined size. Also, in a preferred embodiment, entities in a
13 logical data format include no cross-reference information or other types
14 information that require processing before the data can be used by the navigation application.
16 The query logic subsystem 210 includes a set of function calls that allow 17 the navigation application programs 200 to request a particular set of entities in 18 the logical data model format. The query logic subsystem 210 also implements 19 the logic that locates the requested entities and manages the resulting data set which is then returned to the requesting component of the navigation 21 application programs 200.
22 The query logic subsystem 210 resolves data access queries in terms of 23 subdivisions of the physical media, called "parcels", which contain the requested 24 data in the physical storage format of the geographic data 40 on the medium 22. The query logic subsystem 210 also provides for management of the query 26 result set, which can be expressed in terms of a "cursor" for those queries that 27 can return more than one record. The cursor is a construct that allows the 28 navigation application programs to access parts of a large query result set 29 without requiring an in-memory copy of each record in translated logical data model form.
31 Below the query logic subsystem 210 is an index management and data 32 translation (IMN) subsystem 216. The index management and data translation . CA 02219037 1997-10-23 1 subsystem 216 provides several separate functions. The first function uses 2 index information to locate data for physical entities stored on the medium as 3 directed by the query logic subsystem 210. A second function provided by the 4 index management and data translation subsystem 216 is to unpack or otherwise decompress the optimized entities and to transform the entities into the logical 6 data model data entities that are returned to the requesting navigation 7 application program 200. Where the geographic data 40 stored on the medium 8 are packed or compressed, the second function provided by subsystem 216 also 9 serves to unpack or otherwise decompress the optimized physical entities so that they may be transformed to the logical data model format. Another function 11 provided by the index management and data translation subsystem is the 12. provision for forward/backward compatibility across different versions, as 13 explained further below.
14 Below the index management and data translation subsystem 216 is the resource management subsystem 220. As mentioned above, in some navigation 16 systems, the amount of memory is relatively small and the I/O bandwidth is 17 relatively low. Conventional techniques for the management of these resources 18 may be limited. For example, one approach used in some navigation systems to 19 solve performance problems due to slow I/O is to use memory to cache data, thereby minimizing physical I/O. But memory in these types of navigation 21 systems may be limited as well, particularly where multiple functions of the 22 navigation application 200 may need to operate concomitantly.
23 An improved approach to resource management is provided by the 24 present embodiment. In the present embodiment, the data access interface layer 41 is provided with its own resource management subsystem 220 that is 26 separate from any resource management function provided by the navigation 27 application programs 200. The interface layer 41 is provided with a portion of 28 the navigation system memory for its exclusive use and which is managed by 29 the resource management subsystem 220. In addition, the resource management subsystem 220 has the capability to use additional portions of navigation system 31 memory when they are not needed by the navigation application programs. The 32 resource management subsystem 220 provides for improved management of 1 memory and I/O by focussing on data access requirements of the query logic 2 subsystem taking into account the specific data organization of the physical 3 storage format. The resource management subsystem 220 mediates access to 4 cache memory buffers and the physical I/O channel for data access tasks.
Management of these resources also benefits from coordination of actions and 6 data needs above the level of the data access interface layer 41, i.e. in the 7 software of the navigation application programs 200. The data access needs of 8 the navigation application programs 200 are used to help determine which data 9 to retain in cache memory. An advantageous way to provide this information to the resource management subsystem 220 is through additional access 11 program parameters that allow the data access interface layer 41 to prepare data 12 in the background for anticipated future use. This is in addition to data access 13 calls where the navigation application program waits for immediately required 14 data. In addition, the resource management subsystem 220 may accept parameters that allow for controlling the order of data access from the physical 16 medium.
17 Each of these interface layer subsystems is discussed in more detail 18 below.
19 III. Query Logic (DQL) Subsystem 210 The query logic subsystem 210 represents one level of the software 21 library that forms the data access interface layer 41. The query logic subsystem 22 210 implements an interface 212 to the navigation application programs 200 by 23 providing a view of the geographic database to the navigation application 200.
24 In a present embodiment, the data access interface 41 provides for data access.
The data access interface 41 defines a set of C=language data structures (the 26 logical data model) and a set of function calls that deliver these logical data 27 model entities to the navigation application software programs 200, which use 28 the function calls to access the geographic data. (Although a preferred 29 embodiment of the data interface layer 41 is defined as C-language structures, the interface layer could be defined in any suitable programming language). In 31 a preferred embodiment, each of the data access interface layer function calls _ CA 02219037 1997-10-23 1 made by the navigation application programs is implemented as a wrapper 2 around a corresponding function call in the query logic subsystem 210.
3 In general, the query logic subsystem 210 provides three kinds of data 4 access capability to the navigation application programs. One kind of data access provided by the query logic subsystem allows the navigation application 6 programs to request a particular data entity by its database identifier (DBID).
7 The query logic system 210 provides the requested data entity to the navigation 8 application in the logical data model format. Another kind of data access 9 provided by the query logic subsystem 210 allows the navigation applications to request a set of data entities that are related to a particular data entity.
The 11 query logic subsystem provides the navigation application with a cursor 12 (explained in more detail below) to the resultant set of data entities.
Some or 13 all of the data entities in the resultant set may be in the logical data format. A
14 third kind of data access provided by the query logic subsystem allows the navigation application to obtain data based upon a search request. The query 16 logic subsystem returns a cursor to a resultant set of data entities that match the 17 search criteria.
18 The functions that form the interface 212 allow the navigation 19 application programs 200 to request a particular entity or a group of entities (such as "nodes", "places", "segments", "points of interest", "postal codes", and 21 so on) which can be qualified by a particular subset of attributes (such as "all 22 segments that have an end point at node X", or "all municipalities including the 23 word "Lake" in name, and so on) which are either directly a part of or are 24 otherwise closely associated with the entity. Alternatively, these requests can also be qualified by geographical parameters or attributes, such as all segments 26 within a specified rectangular area or inside a particular named place. The 27 geographic qualifiers can be applied to the primary map data entities and can be 28 useful for narrowing down a search for desired data.
29 The functions in the query logic subsystem 210 provide for pervasive access to data. This means that access to any and all logical data model entities 31 is supported with a reasonable level of performance regardless of navigation 32 application intent. For example, the route guidance software 28 (FIG. 2) may 1 require access to point-of interest data. Support for pervasive access to data 2 occurs regardless of the classification of entities that occurs at the physical 3 storage format level to optimize data access performance to the base set of 4 entities required for important functions such as route calculation or map display. Pervasive access to data offers some synergy with the geographic 6 query qualifiers. For example, rectangular queries are commonplace for 7 geometric data such as segments or nodes, but are also useful for street names 8 and points-of interest.
9 The query logic subsystem 210 also includes the ability to initiate a data access transaction that is predictive in nature, e.g. where data are not required 11 right away but are anticipated to be needed soon. This type of data access 12 transaction preferably occurs in the background, allowing the navigation 13 application programs to continue to perform work. As such, the query logic 14 subsystem 210 provides the capability to make these predictive access calls in addition to normal access calls where the data are required immediately. This 16 function~coordinates with the navigation application programs 200 to predict 17 what data may be required next.
18 Some of the query logic subsystem functions return a single entity or 19 additional detail about a particular entity. However, others of the functions return an unpredictable number of entities. Depending on the particular query 21 and the degree to which it is qualified, this number could potentially be quite 22 large. For this reason, these query logic subsystem functions include a cursor 23 management subsystem 249. A cursor is defined at the time of the query. The 24 cursor forms a window (explained below) into an arbitrarily large result set built by the query. The cursor allows the navigation application to specify how 26 many entities should be returned at a time when data are fetched through the 27 cursor. General-purpose cursor management functions in the data access 28 programming interface 212 allow the navigation application software programs 29 200 to subsequently move this window in a flexible and convenient manner.
-15-1 A. Query resolution 2 The data query logic subsystem 210 implements the interface to the 3 navigation application programs 200 by resolving queries from the programs to 4 a set of physical data subdivisions, called parcels, which exist on the media.
These parcels may contain spatially-organized data, non-spatial data, index 6 information, or other data. Once parcels are identified in response to a query, 7 they are read into memory. The data within a parcel may be further organized 8 into subsets to minimize the amount of data that need to be examined in a 9 parcel to resolve a query. The appropriate parcels or parcel data subsets are identified and entities are located within those parcels or parcel data subsets in 11 order for the data query logic subsystem 210 to build a cursor result set for a 12 particular request. Alternatively, a single logical data record may be returned 13 directly to the navigation application software programs 200 for simpler queries 14 which always return a single record and which do not require construction of a cursor. However, both of these approaches locate and obtain one or more
16 physical parcels, which ultimately reside in the physical storage format on the
17 storage medium 22, and physically examine some subset of the parcel data to
18 locate the entities that make up the result set. Once the result set is identified,
19 the entities are transformed into the logical data model format and returned to the navigation application software programs 200.
21 Resolving queries requires information about the particular physical 22 storage format used on the storage medium 22. The data access interface layer 23 41 isolates the parts of its software library that are dependent upon the specific 24 physical storage format allowing other components of its library to be independent of a particular physical format. The components that are 26 dependent upon the storage format are included in the index management and 27 data translation subsystem 216. This subsystem 216 includes two further 28 subsystems: the index management and navigation subsystem 242 and the 29 physical-to-logical data translation subsystem 244.
At least two approaches are used to minimize accesses to the physical 31 medium. One approach is to use index information within parcels to look up 32 data. Another approach is to use data entity ID's that explicitly identify the 1 parcel in which the data entity is located. (This latter approach is described in 2 more detail in the above-referenced copending application.) Both index 3 information and explicit data entity ID's are used to resolve a query to the 4 parcel, subdivision of a parcel, or record level. The location and type of index information that is available depend on the physical storage format. It follows 6 also that the algorithm for navigating the index also depends on the physical 7 storage format. The function for navigating the index on the physical medium 8 is included in the index management and navigation subsystem 242. Similarly, 9 the transformation of compressed data from the format on the physical media into a form amenable for query resolution and translation to the logical data 11 model format for return to the navigation application program is included in the 12 physical-to-logical data transformation subsystem 244.
13 The query resolution process provided by the query logic subsystem 210 14 depends for data access upon the format-dependent services provided by the index management and navigation subsystem 242 and the physical-to-logical 16 subsystem 244. This allows the imnlementatien c,f the n"P,-~ in~ir e»~,c~r~to,,., 17 210 to be generic and independent of the physical storage format. The query 18 resolution process also makes use of lower-level services to obtain parcels from 19 the physical medium or cache memory and to obtain private dynamic memory buffers. These services are provided by the resource management subsystem 21 (SRM) 220. The index management and navigation subsystem 242, the 22 physical-to-logical subsystem 244, and the resource management subsystem 23 build a foundation for the query resolution process and appear logically below 24 the level of the data query logic subsystem 210 in FIG. 3. This layered approach defines additional interfaces between the data query logic subsystem 26 210 and both the index management and navifation subsystem 242 and the 27 physical-to-logical subsystem 244.
28 One interface 248 in the index management and navigation subsystem 29 242 takes an index specifier and query parameters information from the data query logic subsystem 210 and returns a set of parcel identifiers. A parcel 31 identifier is a format-specific construct for identifying the parcel that is related 32 to the physical organization of the data in the physical storage format on the 1 medium. The parcel identifiers are then passed to the resource management 2 subsystem 220 to obtain a pointer to the physical parcel in memory. Another 3 interface 250 in the index management and navigation subsystem 242 provides 4 for the translation from a specific entity identifier passed by the navigation application program 200 via the data query logic subsystem 210 to an identifier 6 for the parcel which contains that entity. To further resolve a query to a 7 particular parcel data subset or record, additional interfaces 253 between the 8 data query logic 210 and index management and navigation subsystem 242 are 9 required. The query parameters passed via this interface 253 are used by the index management and navigation subsystem 242 to navigate the internal index 11 of the parcel (i.e. the index for the parcel data subsets) to locate the 12 corresponding parcel data subset or record.
13 When internal index information is not present to resolve a query to a 14 particular entity or set of entities within the paxcel, a brute-force record inspection or binary search techniques are provided at the level of the data 16 query logic subsystem 210. When these approaches are used, the entities are 17 represented in an decompressed intermediate format ("DIF") that allows 18 attribute values to be examined in a form that is independent of the physical 19 storage format.
The decompressed intermediate format is independent of the physical 21 storage format, which may vary in different types of media. In a preferred 22 embodiment, the intermediate format is also independent of any changes to the 23 version level of the physical format. This independence allows the query logic 24 subsystem 210, which is the primary client of the physical-to-logical subsystem 244, to examine and understand data in this representation to resolve queries.
26 The decompressed intermediate format conversion interface is primarily record-27 based, with provisions for conversion within parcel subdivisions, if necessary.
28 The conversion process may also use metadata tables (described below) to 29 facilitate the translation to the decompressed intermediate format from newer physical storage format data specification levels.
31 The decompressed intermediate format exists to prevent the time and 32 space overhead required to maintain records in full logical data model format.

1 Entities in logical data model format are much larger in size than in the 2 corresponding decompressed intermediate format. Logical data model entities 3 are fixed-sized entities that are known to the application software and returned 4 from the query logic system 210 through the interface 212. Deferring S conversion from intermediate to logical data model format to only those records 6 that are returned to the navigation application minimizes the amount of memory 7 and conversion overhead required for entities that do not satisfy a particular 8 query. There is a one-to-one relationship between decompressed intermediate 9 format and logical data model entity types.
The transformation into the decompressed intermediate format relies on 11 an interface 257 provided by the physical-to-logical subsystem 244. This 12 utilizes the intermediate format which localizes all data corresponding to an 13 entity within the same parcel. The amount of memory required to hold the data 14 in this intermediate format is preferably smaller than the amount of data that would be necessary to hold the same data entities in the logical data model 16 format. Finally, when entities that comprise the result set have been identified 17 by the query resolution logic, another physical-to-logical interface 255 is 18 available to translate the data to the logical data model format for return to the 19 navigation application programs 200.
B. Cursor management 21 The query result from the data access interface layer 41 is copied into 22 memory buffers provided by the navigation application software programs 200 23 regardless of whether or not cursors are involved. This allows the data access 24 interface layer 41 to compress (i.e. compact) the memory allocated to it in its memory pool without affecting the navigation application programs 200. The 26 cursor management subsystem 249, mentioned above, is part of the query logic 27 subsystem 210. When a cursor-based query call is invoked in the data access 28 interface layer 41, an internal cursor is constructed by the cursor management 29 subsystem 249 and a unique reference to the cursor is returned to the one of the navigation application programs 200 that requested the data. The cursor 31 reference is used to obtain all or some portion of the resulting data. When data 1 are obtained via a cursor, the navigation application program 200 specifies a 2 memory buffer in a size that is a multiple of the returned logical data model 3 entity size. This multiple is based on how many records at a time the 4 navigation application program prefers to (or can afford to) handle at one time.
In a preferred embodiment, this technique is facilitated because the logical data 6 model entities are of a known fixed size.
7 The cursor management subsystem 249 stores the entities that comprise 8 the cursor result set in two different ways. Referring to FIG. SA, some of the 9 entities in the result set are saved in fully-translated logical data model form.
Whether or not all entities in the set are maintained in the logical data model 11 form depends on the number of entities that make up the query result set.
For 12 cases in which the result set size is below a first threshold, the entire set is 13 maintained as an array 511 of decompressed logical data model entities. For 14 cursors whose results set exceeds this first threshold, the remaining are maintained in a second array 513 that includes only entity identifiers. The 16 entity identifier (which in many cases may be the database identifier, or 17 "DBID") allows the record in the physical parcel to be quickly accessed for 18 transformation into the logical data model format.
19 The memory used to maintain the cursor result set is dynamically allocated using the internal private dynamic memory management interface 21 provided by the resource management subsystem 220, as explained further 22 below. When very large result sets are encountered, a partial result set may be 23 maintained if the number of entities satisfying the query exceeds yet another 24 threshold. This second threshold is provided to minimize any possible adverse memory impact of a very large result set. Each of these thresholds may be 26 configured at the time that the executable module 18 including the navigation 27 application programs 200 and the data access interface layer 41 are compiled.
28 The full or partial nature of a particular query is reported to the calling 29 navigation application program 200 so that the number of records returned by the query can be properly interpreted.
31 When a partial result set is maintained for a reference cursor, the query 32 resolution process temporarily comes to a halt once the maximum partial query
-20-1 limit is encountered. In order to continue the query at a later time, the cursor 2 also maintains enough information to resume the query resolution process at the 3 point it left off.
4 The cursor management subsystem 249 provides additional cursor functionality. Once a cursor is defined for a particular query, the cursor is 6 positioned at the beginning of the result set. A "fetch next" cursor function fills 7 the result buffer of the navigation application (specified in the query call which 8 established the cursor) with the next N records and positions the cursor after the 9 last record returned. The cursor is maintained as a "window" of logical data model records that moves across the result set, so that the cursor fetch process 11 is simply a memory-to-memory copy from the cursor's address space internal to 12 the data access interface layer 41 to the address space of the navigation 13 application program 200.
14 Various forms of cursor manipulation functions are also provided by the cursor management subsystem 249 including the ability to reset the cursor 16 position to the beginning, end, or an absolute position in the result set.
A "get 17 previous" cursor function is also provided to augment the "get next"
18 functionality. The absolute positioning function is useful in the context of the 19 result set record count returned by the query function which establishes the cursor.
21 IV. Index management and navigation (IMN) subsystem 242
22 Referring again to FIG. 3, the index management and navigation
23 subsystem 242 contains a portion of the physical format-specific index
24 management and navigation software in the software library that forms the data access interface layer 41. The index management and navigation subsystem 26 242 allows the query logic subsystem 210 and the resource management 27 subsystem 220, above and below the index management and navigation 28 subsystem 242, respectively, to be independent of the physical storage format 29 used on the medium.
Index information is used to resolve the location of a parcel which 31 contains a desired entity or entities based on various search criteria.
Indexes _ CA 02219037 1997-10-23 1 are also used in some cases to locate a particular data subset within a parcel.
2 (An index which is used to resolve to a particular parcel may be regarded as an 3 external index and an index used to resolve to a parcel internal subdivision may 4 be regarded as an internal index because it is stored in the parcel.) External indexes are used to minimize or eliminate having to physically access parcels 6 that may not contain the requested data. Both external and internal indexes also 7 help to minimize the amount of decompression and translation that needs to 8 occur in order to inspect candidate entities. Because various aspects of working 9 with index information to resolve to the parcel, parcel data subset, or level are related to the specific physical storage format, this functionality is implemented 11 within the format-specific index management and navigation subsystem 242.
12 Some of the characteristics of index information that depends on the 13 particular physical storage format include the unique identifier for the parcel 14 containing the root of the index on the physical media, what type of index is used, and whether the index resolves to the parcel, data subset parcel, or record 16 level. Additionally, certain types of index information may exist on one type of 17 storage format, but not on another. In order to maintain information about 18 these index characteristics, a framework exists to maintain this information 19 within the index management and navigation subsystem 242. This information may reside on the physical medium. This information may be read at 21 initialization time and maintained in memory for use by index management and 22 navigation subsystem 242.
23 This index information framework that maintains the details of the 24 indexes present on the physical storage format includes a set of interfaces that the data query logic subsystem 210 can use to obtain the information it 26 needs to determine the optimum index to use based on the query parameters 27 received via a call from the query logic subsystem 210. In a preferred 28 embodiment, a minimum subset of indexes is provided, regardless of the 29 physical storage format. Using a minimum subset of indexes minimizes unnecessary overhead in the query logic subsystem 210 that would result from a 31 completely flexible set of indexing capabilities. The indexing information 32 framework 245 also provides a structure upon the query parameter set that is 1 passed to the index management and navigation subsystem 242 to resolve a 2 query using a particular index. Finally, this framework is extensible, allowing 3 new index types to be defined for future physical storage formats, and allows 4 indexes to be defined in terms of entities and/or attributes that do not exist in current database versions or specifications.
6 Several different indexing schemes are used, depending on media size, 7 media access characteristics, entity type, and the physical organization of a 8 particular physical storage format. For example, a kd-tree, or variants thereof, 9 is used for 2-dimensional resolution of spatial data, and a wide-and-shallow B
tree is used for certain nonspatial data in a physical storage format used for 11 CD-ROM. The index management and navigation subsystem 242 implements 12 the logic used to locate and navigate within these different types of index trees.
13 For external index information, the leaf nodes of these trees specify a particular 14 parcel identifier. For index information that is internal to a parcel, the leaf nodes instead specify a particular parcel data subset or record. Each unique 16 type of index intended for use in the data access interface layer 41 is 17 implemented within a separate module, preferably in C source code. This 18 minimizes code size by reducing unnecessary code from being included when a 19 particular indexing scheme is not used in a particular physical storage format.
Because external indexing information is stored in parcels on the 21 physical media, the index management and navigation subsystem 242 uses the 22 resource management subsystem 220 to physically read the index information 23 from the storage medium into a memory buffer. In alternate embodiments, 24 these index parcels may be retained in memory as the index navigation process proceeds, since it can be expected that some of these indexes will be reused 26 within the same function call or even beyond it. For this reason, index parcels 27 are retained in memory by the caching logic implemented by the resource 28 management subsystem 220.
29 In one embodiment, when a task (such as a function in the query logic system 210) requires an index, the index management subsystem 242 first 31 checks for the availability of the index. If the desired index is available, the 32 index management system returns a message to the task indicating availability 1 of the index and includes a handle for searching using the index. The handle 2 includes a pointer which is called to perform searches using the index. The 3 task obtains memory storage (as explained below) and constructs information 4 for the key of the index. The task also obtains memory to hold the result of the index search.
6 V. Physical-to-Logical Data Translation (P2L) Subsystem 244 7 The physical-to-logical data translation (P2L) subsystem 244 includes 8 the storage format-specific data translation software in the software library that 9 forms the data access interface layer 41. This allows the data query logic subsystem 210 and the resource management subsystem 220 to be independent 11 of the physical storage format.
12 An interface 260 for translation of an entity in the physical storage 13 format form (which may be a compressed form) to the decompressed 14 intermediate form is provided by the physical-to-logical subsystem 244.
This interface 260 first decompresses the entity. This is followed by a 16 metatranslation step 261, if necessary. The memory buffer used to hold the 17 result is provided by the data query logic subsystem 210. The metatranslation 18 step 261 can be bypassed when the version levels of the physical storage format 19 and the intermediate decompressed format are equal for greater efficiency.
Once the data query logic subsystem 210 identifies an entity to be 21 returned to the navigation application program 200, it uses an interface 263 in 22 the physical-to-logical subsystem 242 that translates the entity from the 23 decompressed intermediate form to the final logical data model form. For non-24 cursor single-entity queries, the calling navigation application program supplies the memory buffer which holds the translated logical data model 26 output. Otherwise, a dynamically-allocated private cursor memory buffer is 27 supplied by the data query logic subsystem 210. Unlike the table-driven 28 metatranslation process, the logical data model translation is coded into the 29 physical-to-logical software implementation.
It may be desired for entities in the decompressed intermediate form to 31 persist within or even across data access calls for subsequent repeated access.

1 This could minimize the CPU overhead required to repeatedly perform 2 decompression and metatranslation on the same data as well as minimize the 3 memory management overhead involved with otherwise repeatedly allocating an 4 output buffer. The management of this persistence is provided by the data query logic subsystem 210. This approach takes the anticipated CPU and 6 memory savings into account, along with examination of data access patterns to 7 determine how often repeated access to the same decompressed data occurs.
8 The overall performance of the metatranslation process is also a factor in this 9 analysis.
In an alternative embodiment, some data entities may undergo direct 11 transformation from the physical storage format into the logical data model 12 format without intermediate translation into the decompressed intermediate 13 format.
14 Metatranslation describes the translation of data from the compressed physical storage format representation at some particular data version level (also 16 referred to as a "specification level") to the intermediate decompressed 17 representation known to the data query logic subsystem 210 at some other data 18 version level. Metadata tables 259 are used to facilitate the transformation from 19 one version level to another. The physical storage format metadata tables are read off of the medium into semipermanently allocated memory at system 21 initialization time. The metadata process is described more fully below.
22 VI. Resource management (SRM) subsystem 220 23 The resource management subsystem 220 provides access to memory 24 and I/O resources for the software library that forms the data access interface layer 41. The resource management subsystem 220 manages the availability of 26 navigation system memory and I/O resources for use by the data access 27 interface layer 41 in a mufti-tasking environment' in which the navigation 28 application programs 200 also contend for these resources. In a preferred 29 embodiment, the resource management subsystem 220 does not manage memory and I/O resources for the navigation application software programs 200
-25-1 for tasks other than accessing the geographical database via the interface layer 2 41.
3 There are two primary data access interfaces to the resource 4 management subsystem 220. The first allocates and frees workspace memory from a pool that is reserved exclusively for use by the data access interface 6 layer 41. The second interface specifies a parcel identifier and returns a pointer 7 to a cache memory buffer that contains the parcel. The priority of the parcel 8 can be specified, i.e. an indication of how soon (relatively) the parcel is needed.
9 This feature enables prioritization of parcel I/O transactions and persistence of parcel data in cache when cache is in contention. When a requested parcel is 11 not found in cache, a physical I/O transaction is initiated to read the parcel off 12 the medium. There are additional interfaces in the resource management 13 subsystem 220 that are used to allow the navigation application software 200 to 14 adjust the resource management strategies at run time.
There are at least two approaches that the resource management 16 subsystem 220 uses to increase performance. The first is to minimize and 17 optimize I/O transactions within a constrained memory environment consisting 18 of a portion of the navigation system's heap memory that is dedicated to the 19 software library that forms the data access interface 41. The second is to manage access to this relatively small portion of memory. Memory 21 management also includes methods for maintaining data in cache buffers to 22 minimize I/O and for compacting of the dedicated heap memory. These 23 approaches are achieved with small amounts of CPU and memory overhead. In 24 order to implement these approaches, the physical organization of data on the storage medium, as well as the query optimization techniques implemented in
26 the data query logic subsystem 210 and index management and navigation
27 subsystem 242,' is taken into account.
28 This resource management subsystem 220 works across a wide variety
29 of media types, physical storage formats, operating system environments, and device driver capabilities. A variety of mechanisms are provided to optimize 31 the resource management subsystem 220 for a particular navigation system 32 platform and navigation software application. These mechanisms include the 1 setting of configuration parameters at compile time. Also included are a set of 2 function calls in the data access interface layer 41 that influence resource 3 management behavior at run time. Additionally, the calls for data access are 4 designed to take advantage of built-in resource management capabilities such as background data access. Further, the resource management subsystem provides 6 for prioritization of requests for multiple parcels when more than one parcel is 7 requested by a function (i.e. function level granularity), and alternatively the 8 resource management subsystem can even provide for prioritization of requests 9 for multiple parcels even when parcels are requested by more than one function.
FIG. 4 illustrates one embodiment of the interface layer 41 used in a 11 mufti-tasking environment in a navigation system. Each navigation application 12 task, APP1, APP2 ... APPn, that makes data access interface calls is linked with 13 a interface layer software library, LIB1, LIB2 ... LIBn, in shared code space.
14 Each library implements the data query logic subsystem 210, the index management and navigation subsystem 242, and the physical-to-logical 16 subsystem 244, as well as most (or all) of the resource management subsystem 17 220. As shown in the embodiment of FIG. 4, the I/O manager (IOM) portion 18 270 of the resource management subsystem 220 is implemented as a separate 19 process from the rest of the subsystems (i.e. the data query logic subsystem 210, the index management and navigation subsystem 242, and the physical-to-21 logical subsystem 244, as well as most of the resource management subsystem 22 220) of the data access interface layer 41. This means that the I/O manager 23 270 may not be statically-linked with the application programs 200 as are the 24 rest of the subsystems in the interface layer, but instead operates with each separate navigation processes, 200A, 200B, ... 200n, via the linked portions of 26 the interface layer in each process. This allows the I/O manager 270 to 27 continue to process physical I/O in the background while these other tasks 28 continue to run. This embodiment of the I/O manager 270 would be used in 29 navigation systems that do not have a device driver that supports asynchronous I/O notification capability. However, an alternative embodiment of the I/O
31 manager 270 may be used if the navigation system is of a type that includes a 1 device driver that supports an asynchronous I/O notification capability.
This 2 alternative embodiment is described in more detail below.
3 A. Memory Management 4 As shown in FIG. 4, a portion 278 of the system heap memory 276 is allocated exclusively for use by the data access interface layer 41. The portion 6 278 is the interface layer memory pool. This memory pool 278 is separate 7 from the portion 283 of the memory used by the navigation applications 200.
8 The size of the memory pool 278 is determined by the navigation application 9 program 200 through a call to the resource management subsystem 220 through the data access programming interface 212. The resource management 11 subsystem 220 allows the navigation application program 200 to change the size 12 of the pool 278 dynamically at run time (as illustrated by the arrow 275 13 between the two subdivisions). In one embodiment, the minimum size of the 14 memory pool 278 is 256 Kbytes, with additional memory provided for CD-ROM media to increase the amount of data in cache.
16 The memory pool 278 is used by the data access interface layer 41 for a 17 cache for parcels of varying size that are read from the physical medium as 18 well as for a general-purpose heap that is private to the software library 19 functions of the data access interface layer 41. Buffers allocated 'from this heap memory are used as general working space to hold decompressed data records 21 and for cursor result sets.
22 The memory used for cache buffers tends to be larger and more uniform 23 in size than memory allocated from the general-purpose private heap memory, 24 which is typically smaller and more variably-sized. The management of cache buffers also takes into account the fact that a strategy for persistence is 26 provided. Additionally, searching for a particular parcel in cache should incur 27 as little overhead as possible.
28 These dissimilar yet overlapping memory management objectives are 29 supported by a two-tiered approach. The first tier is responsible for the management of the more uniform and larger buffers which are suitable for 31 parcel cache purposes. The second tier operates in terms of these larger buffers 1 and divides them into smaller and less uniform pieces for general-purpose heap 2 memory allocation. The cache buffer persistence strategy is implemented in 3 terms of the first tier of memory buffer management.
4 Both tiers of memory management are performed by a memory management library ("MML" or "memory manager") 280. The memory 6 management library 280 is part of the locally resident portion of the resource 7 management subsystem 220 that is linked with the navigation application 8 software 200 and runs as part of each of the navigation application processes.
9 The memory management library 280 is a shared code library that uses mutual exclusion technique (described below) to allow multiple applications to have 11 concurrent access to memory. For example, there may be multiple concurrent 12 navigation application processes, such as processes 200A, 200B, ... 200n.
The 13 memory management library 280 also implements the cache management 14 process.
This two-tiered memory management architecture minimizes the amount 16 of memory required for control structures used to keep track of internal 17 memory allocation. These control structures, together with the cache 18 management control structures, are resident in the memory pool 278 of the data 19 access interface layer 41. Interprocess communication (IPC) techniques such as semaphore protection are used by the memory management library to serialize 21 memory requests by arbitrating access to these control structures in a 22 multi-tasking environment. This is illustrated by the dotted lines 277 23 connecting the memory management library 280 from each navigation 24 application task, 200A-200n, to the memory pool 278 Finally, a portion of the memory allocated from the memory pool 278 is 26 used by the software library components of the data access interface layer 41.
27 This portion of the memory pool is not shared (or otherwise returned) to the 28 navigation application software program 200. This is facilitated by providing 29 that the navigation application program 200 allocate its own private buffers to hold returned logical data model data entities. This isolation allows the 31 resource management subsystem 220 to pursue compaction strategies to 1 minimize fragmentation of the memory pool 278 without requiring the 2 navigation application programs 200 to handle this memory management task.
3 B. Cache management 4 Requests for data and index parcels are routed through the memory management library 280 in terms of a parcel identifier. A search for the parcel 6 in cache memory is performed. A physical I/O request to the I/O manager 270 7 occurs when the parcel cannot be found in cache. Once the parcel is in cache 8 memory, an interface 285 in the resource management subsystem 220 locks the 9 parcel in the buffer when the buffer address is returned to the data query logic subsystem 210. This prevents the buffer from being swapped out when a data 11 access interface call is active. An additional interface 279 of the resource 12 management subsystem 220 releases this lock, and is called before the data 13 access interface call returns control to the navigation application program.
14 Swapping may occur when a large number of concurrent parcel requests causes the system to approach memory overcommitment.
16 The persistence strategy for the cached parcels is also implemented in 17 the memory management library 280. This strategy takes buffer locks, priority, 18 usage history, and usage counts into account in order to determine which 19 buffers should be swapped out.
The navigation application software program 200 is in position to 21 anticipate what data may be needed eventually versus what data are required 22 immediately. In order to differentiate data access requests between immediately 23 required data and data to prepare for subsequent access, the resource 24 management subsystem 220 supports synchronous (i.e., waits for result in the foreground) and asynchronous (i.e., processing' continues while I/O proceeds in 26 the background) parcel requests. The asynchronous calls are used by "cache 27 prepare" data access interface functions. An asynchronous request allows the 28 navigation application program 200 to continue doing useful work while the I/O
29 transaction proceeds in the background. An interface call 281 in the resource management subsystem 220 is also provided to allow the navigation application 31 program 200 to cancel a asynchronous data request. In addition, a resource
-30-1 priority value is provided in each data access interface call to give even finer 2 control to the navigation application program 200 to manage these foreground 3 and background requests.
4 C. I/O manager 270 In the embodiment shown in FIG. 4, the I/O manager 270 receives 6 requests for physical I/O. These I/O requests originate with the synchronous 7 and asynchronous "request parcel" interfaces 287 provided by the resource 8 management subsystem 220 whenever the requested parcel cannot be found in 9 cache memory. When this occurs, the memory management library 280 initiates an I/O request via the I/O manager interface 269 which results in an 11 I/O transaction request being put into an I/O manager message queue. The I/O
12 manager interface 269 is depicted in FIG. 4 in the statically-linked portion 271 13 of the resource management subsystem 220. In this case, contention to the I/O
14 queue is managed using interprocess communication techniques such as message queues 273 connecting the I/O manager interface 269 to the separate 16 I/O manager process 270. The message queues 273 provide a single point of 17 event notification for each process (i.e. client). The message queues 273 may 18 be used for notification of events, including I/O completion, memory allocation 19 completion, or resource access allowance. Other events may also be supported.
There is one client message queue for each process (i.e., client).
21 In a preferred embodiment, I/O transactions arriving via the queue 273 22 are received in terms of parcel identifiers. Also included may be an indication 23 of the priority of the request, an identification of the task (client) making the 24 request, an indication of a message queue used by the originator of the request.
By using parcel identifiers, the memory manafement library 280 and the I/O
26 manager 270 can remain independent of the physical storage format.
27 Dependencies on the physical storage format in the resource management 28 subsystem 220 are discussed below. Translation from parcel identifier to 29 physical media address occurs for these I/O requests. When the I/O
transaction is dispatched to the media device, the I/O manager 270 requests a cache buffer
31 from the memory management library 280 to hold the data to be read from the 1 media. This reduces interprocess communication overhead by preventing 2 cancelled requests from needlessly requesting and releasing a buffer, and 3 minimizes cache contention by allocating the buffer at the latest possible time.
4 There are two functions that the I/O manager 270 provides to enhance system performance. One function already mentioned is to allow physical I/O
6 to occur in parallel with other activities. This allows other navigation 7 application software functions 200 or data access interface layer software 41 to 8 continue to run while a physical I/O transaction is in progress. The other 9 function provided by the I/O manager 270 is a serialization function that allows incoming I/O requests to be reordered. This reordering is based on several 11 factors, including the priority of the request, the physical location of the data on 12 the media, the current read head position. Other factors may also be included.
13 Note that even within a single transaction submitted by a single navigation 14 application process, multiple parcels may be specified. This means that I/O
reordering can result in increased performance even when only a single task is 16 requesting data (i.e., "functional level granularity"). Additionally, because 17 index and data information may appear redundantly, particularly for physical 18 storage formats for media with relatively slow random access performance such 19 as CD-ROM, the I/O manager 270 selects the closest of the redundant parcels to read. This feature is provided in part by the support for scattered reads 21 provided by the I/O manager 270.
22 All of the reordering capabilities described above use the ability of the 23 I/O manager 270 to maintain the current physical read head location. This is 24 obtained from the media device driver 290 (FIG. 3). The I/O manager 270 also depends on the ability to obtain a physical media address (or addresses, for 26 redundantly-placed parcels) from an "opaque" parcel identifier. (By "opaque" is 27 meant that the I/O manager 270 can pass along the parcel identifier without 28 knowing to what it specifically refers on the physical storage format medium.) 29 The physical medium address depends on the physical storage format. These dependencies are isolated from the generic portion of the I/O manager 270 by 31 two additional resource management components: a physical storage format
-32-1 address mapper (PAM) 296 and a file directory mapper (FDM) 298. Media 2 device isolation is provided by a media device isolation layer (MDIL) 300.
3 (In a preferred embodiment, the I/O manager 270 handles all data read 4 from the medium. Under certain circumstances, the navigation application may access the data on the medium directly. For example, if there is a specific type 6 of third party data stored on the medium, it may be preferable for the 7 navigation application to access it directly. In addition, certain other types of 8 data may benefit from being read directly from the medium or bypassing 9 storage in cache. These types of data include sound or video data. Due to the way these types of data are used, it may be preferable for sound or video data 11 to bypass cache storage and stream directly to the navigation application for 12 presentation to the end-user.) 13 D. File directory mapper 298 14 The geographic database 40 exists in one or more physical binary files on the storage medium 22. The parcel identifiers for all data in these files, 16 both index and map data information, are closely related to a physical offset or 17 address in one of these files. All interface layer I/O from the I/O manager 18 is performed in terms of a physical media address and an extent (size).
These 19 addresses and extents are represented in terms of an integer number of physical subdivisions on the medium. For CD-ROM media, this physical subdivision is 21 the 2 Kbyte sector. The I/O manager 270 uses the services provided by the 22 physical storage format address mapper 296 to obtain the physical media 23 address for a parcel relative to the beginning of its file. In order for the I/O
24 manager 270 to generate the absolute media address, the starting location of the file is determined. This information is provided by file directory mapper 26 (FDM) 298. A file directory exists at some known location on the medium.
27 This directory provides a physical media address for each of the files on the 28 medium, regardless of whether they are geographic files or not. This file 29 directory is specified for the particular medium. In a preferred embodiment, the ISO-9660 standard filesystem for CD-ROM media is used, although other 31 alternative file systems may also be suitable. For read/write media, a DOS
-33-1 FAT file system may be provided, with the geographic file stored as a read-2 only file organized contiguously on the medium to bypass the FAT
indirection.
3 The file directory mapper 298 isolates the I/O manager 270 from the 4 media-specific (and therefore physical storage format specific) file directory organization. The file directory mapper 298 provides an interface which 6 translates a file name to the physical media address of the beginning of the file.
7 This interface may be available to the navigation application software 200, so 8 that the locations of third party or navigation application-specific files, if any, 9 can be obtained. This interface allows the navigation application to implement a file I/O framework based on file descriptors and byte offsets so that third 11 party or navigation application-specific files can be accessed via the media 12 device driver interface.
13 The file directory mapper 298 is able to ascertain the location of the file 14 directory on the medium 22 based upon a predetermined information of its structure. When invoked, the file directory mapper 298 reads the directory 16 from the known location on the medium. This is illustrated by the interface 17 301 between the file directory mapper 298 and the media device 22. A
private 18 buffer obtained from the memory management library 280 is used to hold a 19 temporary copy of the directory until the offset is determined. This activity takes place at initialization time for all geographic data files to minimize 21 repeated access of the directory. The starting location for each file is retained 22 within the file directory mapper 298 for the duration of an operating session.
23 E. Physical storage format address mapper 296 24 As mentioned above, the physical storage format address mapper 296 translates a parcel identifier (i.e. a "parcel ID") into a physical media address 26 (or addresses) relative to the beginning of the file the parcel is located in.
27 More specifically, the physical storage format address mapper 296 translates a 28 parcel ID to a physical sector address and sector count on the medium by using 29 the file address mapper 298 to locate the file on the medium and translating the logical parcel ID to a starting physical sector and sector count. Multiple 31 addresses are returned for redundantly placed index and data parcels. The
-34-_ CA 02219037 1997-10-23 1 address mapper 296 is a component of the I/O manager subsystem 270 that 2 does not physically interact with the medium 22.
3 The parcel identifiers are closely related to the physical addresses of the 4 parcel on the medium. The identifier also carriers information about parcel size and a bit (or other information) which indicates the presence of redundant 6 copies of the parcel on the medium. An example of a parcel ID 600 is 7 illustrated in FIG. 6. The parcel ID 600 may consist of one part 641 that is an 8 offset from the start of the file containing the parcel, a second part 602 that 9 indicates the size of the parcel, and a third part 603 that indicates whether there are redundant copies of the parcel on the medium. The locations of redundant 11 copies of the parcel are determined by use of a table which is retained in global 12 memory throughout an operating session of the navigation system. This 13 information can be combined algorithmically within the physical storage format 14 address mapper 296 in a physical storage format-specific way to generate the i 5 physical address using minimal CPU or memory table overhead.
16 The physical media address (or addresses for redundantly stored parcels) 17 returned by the physical storage format address mapper 296 is not a byte 18 address, but is instead at a physical subdivision of the medium. For CD-ROM
19 media, this subdivision is the 2 Kbyte sector. For read/write media, the subdivision may be a smaller size such as 256. Similarly, the parcel size may 21 also be expressed in these terms.
22 The interface to the physical storage format address mapper 296 takes a 23 parcel identifier (parcel ID) and returns a relative physical media address (or a 24 set of physical media addresses for redundantly stored parcels) along with the parcel size. This information corresponds to the portions 601 and 602, 26 respectively, of the parcel ID. The relative physical media address (or 27 addresses) is added to an absolute file starting location address that has been 28 obtained from the file directory mapper 298 at initialization time to produce an 29 absolute physical address (or addresses) for the parcel. If redundant copies of parcel are provided, the I/O manager 270 then chooses the closest address based 31 on current read head location, and passes this address, the parcel extent (size),
-35-1 and the address of the cache buffer obtained from the memory management 2 library 280 to the media device isolation layer 300 to initiate the physical I/O.
3 F. Operating system isolation layer (OSIL) 302 4 An operating system isolation layer (OSIL) 302 provides an interface between the generic operating system services to which the data access interface 6 layer 41 is written and the particular services provided by the operating system 7 202 of the navigation system platform. For example, the operating system 8 isolation layer 302 can be utilized to support various operating systems 9 including ITRON, OS9, pSOS, VRTX, VxWorks, proprietary operating systems, and single task operating systems. The operating system isolation 11 layer 302 is a software module that is related to a specific platform (or OS) and 12 enables the data access interface layer 41 to operate on a particular platform.
13 There are several different types of operating system services. The first 14 consists of general purpose services, such as string functions (including transformation between multi-byte and wide-character formats), math functions, 16 common utilities such as searching and sorting, and the like. The software 17 library that comprises the data access interface layer 41 uses some of these 18 operating system services. For example, an ANSI C standard library (stdlib) 19 interface is used for these functions. The memory management functions malloc() and free() also fall under the stdlib interface. These are used by the 21 resource management subsystem 220 to allocate and resize the memory pool 22 278 for internal management (as mentioned above).
23 The other set of OS-level interfaces that the resource management 24 subsystem 220 uses includes the protection of shared data structures in memory such as the memory management and cache control structures, and the I/O
26 queue. Contention to these structures by multiple tasks linked to the data 27 access interface layer 41 is managed using interprocess communication 28 mechanisms such as semaphores and message queues. The resource 29 management subsystem 220 preferably uses the standard POSIX.4 interfaces for these mechanisms.
-36-1 If another type of interface is provided by the operating system 202 of 2 the navigation system 10, the operating system isolation layer 302 implements 3 the ANSI C stdlib and POSIX.4 interfaces as a translation layer to the 4 interfaces for the native services provided by the navigation system OS. If it is not, then the service is implemented within the operating system isolation layer 6 302.
7 Note that even though the resource management subsystem 220 uses 8 logical POSIX.4 semaphore and message queue interfaces, this does not 9 necessarily mean that a physical semaphore or message queue is used underneath. For example, it may be faster and/or easier, compared to using a 11 physical semaphore, to simply disable interrupts while in a critical section of 12 code, such as reading or updating a shared cache control structure, and reenable 13 the interrupts afterward. In a preferred embodiment, use of interrupts is limited 14 to actions that are predictably short in order to limit any impact on other tasks.
Alternatively, the I/O queue can be implemented as a "semaphore-protected"
16 shared memory buffer instead of a message queue when the I/O manager 270 is 17 implemented completely within the statically-linked software library of the data 18 access interface layer 41. This alternative embodiment is discussed below.
A
19 still further alternative is to provide a single interface layer task with no mufti-tasking contention to these internal resource management structures 21 whatsoever.
22 The operating system isolation layer 302 allows a definition for the 23 standard interfaces to which the data access interface software library 41 can be 24 written. Some of the operating systems to which the data access interface layer 41 may be ported provide some or all of these interfaces. In these cases, the 26 interface service provided by the OS can be used instead of the corresponding 27 function provided by the operating system isolation layer 302. Some UNIX
28 variants and some embedded-oriented operating systems provide complete ANSI
29 C stdlib and POSIX.4 services.
G. Media device isolation layer (MDIL) 300
-37-1 The media device isolation layer (MDIL) 300 serves a similar function 2 to the operating system isolation layer 302, except for the media device driver 3 interface. In general, particularly for slow CD-ROM media, performance is 4 improved significantly when scattered or skipped read support is provided by the device driver. This feature provides for reading some number of 6 noncontiguous but nearby sectors into the same number of separate memory 7 buffers provided by the caller application. This feature provides approximately 8 sequential-access performance without having to dispatch each request 9 separately. This feature may incur some additional rotational latency and possibly require a seek backwards when used on media such as CD-ROM, 11 because data are physically stored in a spiral on such media. Additionally, this 12 feature may require having to allocate a larger contiguous memory buffer to 13 hold the desired sectors as well as any unwanted gaps.
14 The media device isolation layer 300 supports a scattered read device capability without requiring the actual device to support scattered reading.
The 16 I/O manager component 270 of the resource management 220 writes to a single 17 device interface which takes an array representing a sequence of physical media 18 addresses, extents, and memory buffer pointers. The size of this sequence is 19 configurable. If the media device provided by the navigation system accepts this kind of scattered read interface, then the media device isolation layer 21 may not be needed. However, the device interface provided by the navigation 22 system 10 may not provide for this feature even if scattered read support is 23 provided. For example, a linked-list containing this information, rather than an 24 array and size may be required. Alternatively, the data structure may be ordered differently. Accordingly, in a present embodiment, this type of 26 translation can be handled within the media device isolation layer 300.
27 There are also media device drivers that do not support scattered read.
28 This may be the case for fast drives or for read/vvrite media.
Alternatively, 29 relatively slow device performance may be balanced with more memory for cache. In these cases, the media device isolation layer 300 dispatches each of 31 the I/O transactions into the input array one-by-one.
-38-1 Accordingly, the media device isolation layer 300, like the operating 2 system isolation layer 302, is tailored to a specific type of media and may be 3 specifically prepared for the process of porting the data access interface layer 4 41 to a particular platform. In a preferred embodiment, the media device isolation layer 300 and the operating system isolation layer 302 are the only 6 two components that are platform dependent. Further in the preferred 7 embodiment, the remaining library functions that comprise the data access 8 interface 41 have identical source code for all platforms.
9 VII. Operation Memory Pool Initialization and Allocation 11 In a preferred embodiment, the amount of memory available to the 12 interface layer is, in part, a function of the particular hardware platform of the 13 navigation system. Further, in a preferred embodiment, the amount of memory 14 that is made available to the interface layer may be controlled, to a limited extent, by the navigation application. Referring to FIGS 3 and 5, in one 16 embodiment, the navigation application 200 may use an API (application 17 programming interface) call to the memory manager 280 at system 18 initialization. At this point, the memory manager 280 can allocate a certain 19 amount of memory for use by the interface layer. One way by which the memory manager can allocate .memory for use by the interface layer is to use a 21 function call, such as malloc(), to the operating system of the navigation 22 application to obtain an allocation of memory.
23 The memory allocated by the memory manager 280 at initialization 24 forms the interface layer memory pool 278. The memory manager 280 subdivides the memory in this memory pool 278 into multiple memory blocks.
26 In a preferred embodiment, each block is contiguous area of memory of a 27 predetermined, fixed size. The predetermined memory block size may be 1 28 Kbyte or 2 Kbyte or any other size consistent with the hardware and software 29 of the navigation system. In one embodiment, the memory manager 280 first obtains and allocates a minimum amount of memory required for the interface 31 layer and then obtains additional blocks of memory, by again making a function
-39-1 call (e.g. mallocQ) to the operating system, to obtain additional memory until it 2 has allocated all the memory that the navigation application has configured for 3 the interface layer. By allocating a single area of memory for minimum usage 4 at initialization time and then allocating additional memory later, memory fragmentation can be reduced as later dellocation and reallocation results in 6 resizing the memory usage of the interface layer, as explained below.
7 Deallocation and reallocation 8 In a present embodiment, the interface layer advantageously provides for 9 dynamic adjustment of the amount of memory used by the interface layer. This allows a portion of the memory in the navigation system to be used alternately 11 by either the interface layer or the navigation application programs depending 12 upon which of these has the greater need for the memory. In a preferred 13 embodiment, one or more of the additional blocks of memory over the 14 minimum amount allocated by the interface layer may be subsequently returned to the navigation application when the navigation application requires additional 16 memory. According to this embodiment, during operation, the navigation 17 application program 200 may request that an amount of memory be returned 18 from the interface layer. The navigation application may require this additional 19 memory for a memory intensive task, such as the display of a large number of items. Upon receiving the request, the memory manager 280 checks whether 21 there is additional memory allocated to the interface layer in the memory pool 22 278 over the required minimum. If so, the memory manager 280 identifies an 23 amount equal to one or more blocks, rounded up to the next higher whole block 24 over the amount requested by the navigation system. (In a preferred embodiment, when allocating or deallocating memory from the navigation 26 system, the memory manager 280 handles whole blocks.) By returning an 27 amount rounded up to the next higher whole block over that amount that was 28 requested by the navigation application, the interface layer assures that the 29 navigation application receives at least the amount of memory it needs. The memory manager returns the memory to the navigation application by using a 31 function call to the navigation system operating system, such as free().
-40-1 Similarly, when the navigation application program no longer requires 2 the additional memory, it can return the memory to the interface layer.
3 Returning memory from the navigation application to the interface layer may 4 follow a process similar to the initial memory allocation procedure, described above. In this manner, the interface layer can be assured of a minimum amount 6 of memory for its own use, as well an additional amount of memory that it can 7 routinely use thereby providing a relatively high overall level of performance.
8 Furthermore, when the navigation application has an intensive task, it can 9 temporarily use some or all of the interface layer's memory allocation over the minimum amount. This feature of the interface layer provides for an 11 advantageous use of the resources of the navigation system by allowing for 12 dynamic adjustment of the memory usage.
13 Memory pool usage 14 The memory manager 280 provides memory from the memory pool 278 for two different kinds of tasks. First, memory in the pool is used for a private 16 workspace for the use of the interface layer subsystems. Second, memory in 17 the pool is used for cache, i.e. to hold data read from the medium. When a 18 parcel of data is read from the medium, it is stored in a cache buffer. The 19 memory manager 280 keeps track of the number of available memory blocks in the memory pool and the number of blocks which may be allocated for private 21 workspace. In some embodiments, newly allocated or freed blocks are 22 preferably used for cache rather than for private workspace.
23 . The memory manager 280 allocates memory from the memory pool 278 24 for both cache and for private workspace in response to requests from tasks for buffers. A requested buffer may be smaller, larger, or the same size as one of 26 the memory blocks in the memory pool. When attempting to satisfy a request 27 for a memory buffer larger in size than the fixed memory block size, the 28 memory manager attempts to locate a set of contiguous memory blocks that 29 satisfy the buffer size requested, and allocate these multiple contiguous blocks to service the request. Requests for memory may also be made for amounts 31 less than the size of a whole block. The memory manager subdivides a
-41-1 memory block to satisfy smaller requests. Requests for smaller amounts of 2 memory are more typically made for private workspace rather than for cache.
3 Each allocated buffer, whether for cache or private workspace, is 4 assigned a buffer ID. This buffer ID is a constant handle associated with the buffer over the lifetime of the buffer. Memory pointers to the buffer may 6 change due to memory compaction. In a preferred embodiment, for buffers 7 used for cache, the parcel ID is used as the buffer ID. For buffers used for 8 internal workspace, a unique buffer identifier is generated.
9 Task buffer counts and task buffer status The resource management system keeps track of each task's cache buffer 11 count. A task's buffer count corresponds to how many buffers are "owned" by 12 a task. Buffers are owned by a task whenever a task requests or reads data in a 13 buffer or whenever a buffer is shared with another task that had ownership and 14 the other task subsequently releases its ownership. If the buffer is used for cache, the data in the buffer include a parcel read from the medium and the 16 ownership of the buffer is determined by the task that requested the parcel.
17 When more than one task requests data in a buffer, the memory manager 18 assigns ownership of the buffer to the last task that requested the data in the 19 buffer or the last task that read data from the buffer. A task loses ownership of a buffer when another task takes ownership of the buffer or when the task 21 ignores the data (i.e. the parcel) in the buffer. A task also loses ownership of a 22 buffer when the buffer is swapped out. A task's cache buffer count changed 23 each time the task takes control of or loses a buffer.
24 Tasks may have assigned minimum and maximum cache buffer limits.
These limits relate to how many buffers can be "owned" by a task. These 26 limits may be enforced only when there is contention for available memory 27 resources. Otherwise, each task is permitted to use as much memory as is 28 available. When memory resources are in contention, tasks that exceed their 29 maximum buffer limits will lose buffers. Tasks will not lose buffers if they are only at their minimum buffer limits.
-42-1 Each buffer has a status. The memory manager 280 keeps track of the 2 status of each of the buffers. The status of a buffer derives from the status of 3 the tasks using the buffer. More than one task may be using a single buffer.
4 The memory manager 280 maintains a status of each task that accesses the parcel.
6 A buffer's status may be "locked", "active", or "ignore." When the 7 contents of the buffer are currently in use by a task, the task status and the 8 buffer status are set to "locked." If any one task using a parcel in a buffer is 9 locked, then the buffer is locked as well. When a buffer is locked, it is not available for swapping out of cache. Also, in a preferred embodiment, a locked 11 buffer may not be moved, such as during memory compaction.
12 A buffer in "active" status indicates that one or more tasks may still be 13 interested in the contents of the buffer, but that the buffer can be swapped out 14 if the memory in it is needed. Information about the task, its resource priority, and so on, remain associated with the buffer so that these factors can be 16 evaluated by the memory manager when the manager is seeking memory to 17 ' swap out. Unless the buffer is needed for other tasks, the data remains in the 18 cache buffer and the buffer is available, if needed, for other tasks that may need 19 to access the data in the buffer.
A buffer in "ignore" status indicates that no tasks are currently using the 21 memory in the buffer. Therefore, this buffer may be used for other tasks or 22 swapped out. Ignored buffers may also be moved and/or compacted.
23 Compaction 24 The resource manager also provides compaction and so-called "garbage collection" of the interface layer memory pool '278. As memory blocks are 26 allocated and deallocated, fragmentation may occur within the memory pool.
27 The memory manager 280 groups together adjacent unused memory blocks and 28 memory blocks having "ignore" status for subsequent reuse for cache or private 29 workspace. In addition the memory manager may physically move unlocked buffers in order to decrease fragmentation.
-43-_ CA 02219037 1997-10-23 1 In determining when to swap out or compact memory, the memory 2 manager takes into account resource priority, task buffer counts, and buffer 3 status. In general, a high priority application or an application that frequently 4 accesses its cache will have a reduced likelihood of having its buffers swapped out.
6 When deallocating or compacting the memory, it may be preferred to 7 select the memory in the region closest to the original boundary between the 8 interface layer's allocated memory 278 and the application's allocated memory 9 283.
Processing of a query task 11 As mentioned above, the interface layer defines a set of calls that can be 12 used by a navigation application program to access a set of geographic data 13 entities on a physical storage medium. The set returned by the interface layer 14 can be empty, can include a single entity, or can return a list of multiple entities. ~ These returned entities conform to the logical data model, described 16 above, which is a decompressed format. The interface layer accepts calls that 17 allow the navigation application to formulate a query for data. These calls may 18 be qualified by spatial as well as non-spatial attributes of the desired entities.
19 The attributes used to qualify a query can be used singly or in combination, and can specify a range or a single value.
21 In a preferred embodiment, the geographic data on the medium are 22 organized into one or more files. The data include spatially organized data, 23 non-spatially organized data, and index data. The storage medium may include 24 other types of data as well. The spatially organized data include data such as segments of roads and nodes. In a preferred embodiment, these data are 26 organized into parcels which contain the data entities encompassed within 27 physical geographical localities within the geographic region. Non-spatially 28 organized data may include data, such as names of navigable features. These 29 data may be organized in a manner that facilitates their use, such as alphabetically or by municipality. Indexing data include indexes that relate the 31 various spatial and non-spatial data to each other. These indexes may include
-44-1 kd-tree indexes, B-tree indexes, and so on. In a preferred embodiment, all 2 these types of data are included in parcels, each identified by a unique parcel 3 ID. In a preferred embodiment, the parcel size is related to a physical sector 4 size on the physical medium. For example, for CD-ROM media, the sector size is 2 Kbytes and the parcel size is a multiple of the sector size, e.g. 16 Kbytes.
6 In a preferred embodiment, the interface layer accesses data from the medium 7 in whole parcels and loads whole parcels into memory in a single physical read 8 in order to resolve a query. Multiple parcels may be read into memory in order 9 to resolve a query transaction.
When the query logic subsystem 210 receives a call for geographic data 11 from the navigation application program 200, the request may be in the form of 12 a "geo-coded" request. This means that the navigation application 200 wants 13 data relating to certain geographic conditions or boundaries. The query logic 14 subsystem 210 resolves the request into parcel ID's by mapping the request to a set of parcels so that the data can be retrieved from the medium. This is done 16 using the index management subsystem 242. Accordingly, it may necessary to 17 first access the index data in order to identify the parcel ID's of the geographic 18 data needed to respond to the query. Commonly-used index data may be read 19 into memory at initialization time. If the desired index data are not already in memory, they are read from the medium.
21 Once the parcel ID of the desired data is identified, the request for the 22 parcel is directed to the memory manager 280. The memory manager examines 23 the cache portion of the memory pool to determine whether the requested parcel 24 has already been stored in cache memory in response to a request from a previous task. If the requested parcel is already in cache, the memory manager 26 280 returns a pointer to the cache buffer to the requesting task and locks the 27 buffer (as explained above). If the requested parcel is not already in cache, the 28 memory manager 280 sends the request to the I/O manager 270. In the I/O
29 manager, the requested parcel is compared to a list of parcels that have already been requested but not yet been sent to the media driver. If the parcel is on the 31 list of requested parcels, the task's (client's) identification is added to the 32 information associated with the parcel. If the parcel is not in the list, the parcel
-45-_ CA 02219037 1997-10-23 1 is added to the list along with an identification of the task (client) requesting 2 the parcel and information indicating the parcel's sector location and length.
3 When a task requires a plurality of parcels, the listing of parcels are sent as a 4 group to the Il0 manager for retrieval in order to satisfy the request at the same time.
6 For each parcel requested, the I/O manager 270 calls the physical 7 address mapper 296. The physical address mapper 296 translates the parcel ID
8 and returns the parcel size and physical starting sector (or sectors if the parcel 9 is stored redundantly). Using this information, the I/O manager 270 sorts the I/O requests in priority and sector proximity order taking into account the 11 current read head position. For parcels stored redundantly, the I/O manager 12 270 selects the sector that results in the minimum search time.
13 The I/O manager 270 calls the memory manager 280 to allocate cache.
14 The memory manager 280 scans a list of free memory in the memory pool 278 to find available memory and adds the available memory to cache. The 16 memory manager 280 locks a buffer, as described above, to indicate that the 17 memory associated with the buffer is reserved for I/O. Data are also stored that 18 identifies the client task that requested the I/0.
19 If the memory manager 280 finds no available memory, it attempts to swap out memory. As mentioned above, locked buffers are not swapped out.
21 If there are any buffers whose status is "ignore", these are swapped out first. If 22 memory is still needed in order to allocate cache for a new I/O, the list of tasks 23 is examined to see if any tasks have exceeded their maximum buffer limit.
If 24 so, the memory manager 280 searches for any unlocked buffers used by the task and these are selected for swapping out. If memory is still needed for 26 allocating to new data, buffers whose status is '"active" are examined and these 27 are swapped out for use for the new data.
28 If the request for a memory buffer for the new I/O cannot be satisfied 29 with the available memory in the memory pool 278, the memory manager 280 may perform compaction of the memory pool. As described above, only 31 unlocked buffers are available for compaction.
-46-1 It may occur that even after compaction no memory is available in the 2 size requested by the I/O manager for the new I/O. If this occurs, the memory 3 manager 280 returns information to the I/O manager 270 indicating the largest 4 cache space that is available. The I/O manager 270 then scans. the I/O
request list to determine whether any I/O request waiting to be serviced can be satisfied 6 by the available cache. If there is an I/O request waiting to be serviced that 7 can be satisfied with the available cache size in memory, this I/O request is 8 serviced. The I/O manager 270 sends a message to the memory manager 280 9 to lock the cache memory that is available in the requested size. The I/O
manager 270 then sends the I/O request to the media driver for retrieval.
11 If no I/O request in the I/O request list matches the available memory, 12 the I/O manager 270 temporarily stops generating new requests for cache to the 13 memory manager 280. Eventually, as tasks are completed, the memory 14 manager 280 unlocks or frees memory and as memory becomes available, the pending I/O requests are serviced.
16 When the memory manager 280 indicates to the I/O manager 270 that 17 cache is available to service an I/O request, the buffer is reserved. The I/O
18 manager services the I/O request list by building scattered read requests.
A
19 number of reads may be chained together. Once this information is sent to the media driver, the I/O requests are removed from the I/O request list.
21 The memory manager 280 sets the status of the cache buffer to "active."
22 The memory manager returns a pointer to the buffer back to the task that 23 requested the data, e.g. a call from the query logic subsystem. Once the pointer 24 to the buffer is returned to the task that requested it, the buffer's status is set to "locked." The data in the cache buffer are used as appropriate. The pointer to 26 the buffer is not changed until the task unlocks the buffer, e.g. by indicating 27 that it has finished with the data in the buffer. When the data (in the logical 28 data model format) are returned to the navigation application and therefore the 29 data in the cache buffer are no longer needed by the task, the task in the query logic subsystem 210 also returns a message to the memory manager to reset the 31 cache buffer from "locked" to "active" or "ignore" indicating that the data are
-47-_ CA 02219037 1997-10-23 1 not presently needed. When it is no longer "locked", the buffer may be 2 compacted, moved or released.
3 In general data are maintained in cache for as long as possible consistent 4 with other requirements. This provides the advantage that once data are in memory they are stored in a cache because of the possibility that the data may 6 be needed for a subsequent task. Therefore, the data may persist in cache over 7 a period of time that includes several calls from the navigation application. In 8 order to provide for memory compaction and defragmentation, data which are 9 not locked may be moved by the memory manager 280 from one memory location to another. In order to find the data which may be in cache, a task 11 requests the data by the buffer ID, which in a preferred embodiment is the same 12 as the parcel ID for cache data. Therefore, when a task requests a parcel, it 13 obtains a pointer to an address of a buffer. The "pointed-to" buffer has a buffer 14 ID which is the same as the requested parcel ID. In this manner, the memory manager 280, by keeping track of buffer ID's and their addresses, returns a 16 pointer to the task indicating where the buffer is located. If the memory 17 manager 280 moves a buffer during compaction, it keeps track of new location 18 of the buffer so that the appropriate pointer can be returned to any task 19 requesting that particular buffer. Pointers maintained in memory buffer itself are by offset and not absolute address as the base block address can move.
21 Processing of a request for private workspace task 22 As mentioned above, the memory manager 280 also allocates buffers for 23 private workspace for interface layer functions. As mentioned above, if the 24 memory required by an interface layer function is smaller than one of the fixed sized blocks in the memory pool 278, the memory manager 280 subdivides the 26 block into smaller sized portions. When a request for private workspace is 27 made, the memory manager 280 first searches memory blocks that are already 28 in use by private memory functions to determine whether there is sufficient 29 space available in the block to meet the memory needs of the new request.
Additional blocks may be allocated for private workspace, if needed.
-48-_ CA 02219037 1997-10-23 1 The memory manager 280 assigns a unique buffer ID to each block used 2 for private workspace. These buffers are locked while in use by the interface 3 layer function.
4 Operation of the physical-to-logical data translation subsystem The physical-to-logical subsystem 244 subsystem is responsible for 6 translation of information from the optimized physical storage format found in 7 parcels read from the medium into memory by the resource management 8 subsystem 220. This translation occurs in two phases. The first phase is from 9 the compressed physical storage format to the decompressed intermediate format (DIF) that can be examined to resolve queries. The second phase is 11 from the decompressed intermediate format to the final logical data model 12 format that is returned to the application via the query logic system 210.
13 Operation of cursor management system 14 The tasks that request data, as described above, may result in either small or large amounts of data being found. The cursor management subsystem 16 249, which is part of the query logic subsystem 210, handles these results 17 regardless of the amount of data that results from a request. Operation of the 18 cursor subsystem begins with a function in the query logic subsystem that 19 expects to require use of the cursor subsystem in connection with a request for data. Several different functions in the query logic subsystem 210 can expect 21 to retrieve data that requires use of the cursor management subsystem.
First, 22 the function in the query logic subsystem initializes memory, i.e. a buffer, for 23 the cursor. The cursor cache is a portion of memory that holds an array of data 24 structures. The structures are determined by the query function based on the query type. Information about the structures are passed to the cursor 26 management subsystem. The information may include the number of records to 27 be used in a cursor cache, record size, number of data entity ID's (DBID's) that 28 could be stored in the cursor memory, and so on. Some of this information 29 may be fixed in size, such as the DBID. Referring to FIG. SA, this information
-49-1 is used to set up the arrays 511 and 513 for holding the decompressed data 2 entities and the data entity ID's, respectively.
3 After the cursor's cache is allocated, the query is processed to obtain the 4 data results, as described above. If multiple entities are located that satisfy the request, each of the data entities retrieved is stored in fully decompressed 6 logical data format in the array 511 until the array is full. The data entity ID's 7 (DBID's or database identifiers) for the records stored in the array 511 are 8 included in the second array 513. In addition, if the number of data entities 9 identified as matching the query exceeds the number of data entities that can be stored in decompressed form in the first array 511, the data entity ID's for these 11 additional data entities are stored in the second array 513 after the ID's of the 12 data entities stored in the first array. In the example of FIG. SA, twenty data 13 entities are stored in fully decompressed form in the first array 511 and the 14 entity ID's of 100 data entities (including the first twenty) are stored in the second array 513. Any of these data entities in the first array 511 can be 16 immediately returned to the navigation application program since they are fully 17 decompressed. Both the number of entities that can be stored in the 18 decompressed array 511 and the number of database ID's that can be stored in 19 the array 513 are determined by the query function that calls the cursor management system.
21 In a preferred embodiment, the first array 511 supports both FIFO (first-22 in-first-out) and LIFO (last-in-first-out) during use of the cursor cache.
If a 23 record beyond the last record in the array is requested, for example record 21, 24 that data entity is found (using the entity's DBID in the second array 513), decompressed into the logical data format, and stored in decompressed form in 26 the first array 511 replacing the oldest record (e.g. record 1). Similarly, if 27 record 22 is requested, it is found using the data entity ID from the second 28 array 513, decompressed into logical data format; and stored replacing record 2 29 in the first array 511. This type of access is in the forward direction and would use FIFO. On the other hand, if record 1 were then requested, record 1 would 31 be retrieved, decompressed, and stored in decompressed form in the first array 32 511 replacing record 20. Record 20 would be replaced since it is the oldest
-50-' CA 02219037 1997-10-23 1 record in the first array 511. This type of access is in the reverse direction and 2 would use LIFO.
3 Another example is shown in FIG. SB. In FIG. SB, the first array 511 4 is shown as being occupied with records 25 through 44. If record 24 were requested, it would be decompressed and would be stored in the first array S

6 replacing record 44. If record 23 were then requested, it would be 7 decompressed and would be stored in the array 511 replacing record 44, and so 8 on.
9 In FIGS. SA and SB, the second array 513 (i.e. the array that holds only the data entity ID's) is shown to have a size that accommodate only 100 data 11 entity ID's. It is possible that the query will result in more than 100 entities.
12 When there are more entity ID's than will fit into the second array S 13, the 13 cursor subsystem retains information that provides for one or more additional 14 pages of data entity ID's.
The following example illustrates the paging function of cursor system.
16 For purposes of this example, it is assumed that the first array 511 can hold 20 17 decompressed data entities and the second array 513 can hold 100 data entity 18 ID's, but that the query results in 1000 records.
-51-' CA 02219037 1997-10-23 1 Cursor Page ID's range ID's range Page header in in ID array 513 cache array 3 2 80-180 100-120 gp 13 12 880-980 900-920 gg0 In the example, initially the first array 511 includes records 80-100 in 16 decompressed form and the second array 513 is includes the first 100 data 17 entity ID's. At this point, neither the first nor the second array includes any 18 data entities or ID's beyond record 100. If the application want to access the 19 lOlth record, the query has to be resolved again. All the data entity ID's in the second array 513 are cleared and replaced with entity ID's for records 80-180.
21 The record 101 is decompressed and stored in the first array 511 replacing 22 record 80. The table shows the ranges for each page when there are 1000 23 records and the arrays 511 and 513 hold 20 records and 100 entity ID's, 24 respectively.
The arrays described above can be used with various types of data 26 including types of data that do not have their own entity ID's. These types of 27 data may be attributes associated with, or describe, entities in the database.
28 Examples of these types of data include blocks, landmarks, and text. For these 29 types of data, a virtual ID is assigned by the cursor management system.
The
-52-' CA 02219037 1997-10-23 1 virtual ID would be similar to a regular data entity ID except that instead of 2 representing a type of entity, it would represent an offset, or other type of 3 information.
4 Certain types of data may not be handled by the cursor management system, but instead would bypass the cursor management system and be sent 6 directly to the navigation application. These types of data may include shape 7 points. The navigation application would provide appropriate memory buffers 8 to accept the shape point information.
9 VIII. Porting and Configuration FIG. 7 is a flow chart showing a process for compiling the source code 11 for the data access interface layer and the navigation application software 12 programs to form an executable module. In a preferred embodiment, the source 13 code for the navigation application functions is written and saved as libraries of 14 source code functions 502. These libraries are compiled to form an object code module 504 for the navigation application functions. This object code is then 16 statically linked with the source code 506 for the interface library functions to 17 form an executable module 510 which is specific to a particular navigation 18 system platform. The executable module 510 may be installed on the 19 navigation system platform in various ways. For example, the executable module may be copied from an additional drive slot or may be pre-installed 21 into some form of non-volatile memory in the navigation system.
22 In a preferred embodiment, the data access interface layer software 23 includes a number of tunable parameters whose values can be adjusted to 24 optimize performance on a particular platform. These parameters can be adjusted as part of the porting process. The porting process includes optimizing 26 these tunable parameters for the combination of navigation application software, 27 OS, media device driver, and hardware.
28 The data access interface software library subsystems have the potential 29 to be configured either at compile time, run time, or both. Some of the configuration information takes the form of a set of C code variables which 31 may reside in a separate source code module. The values of these variables can
-53-1 affect the run time behavior of a particular subsystem. These variables can be 2 initially set to default values and adjusted in source code form. The resulting 3 optimized configuration information is then linked with the implementation of 4 the particular navigation subsystem. Additional configuration information takes the form of conditional compilation statements and preprocessor defined 6 constants, which are used to optimize subsystem behavior at compile time.
7 IX. Updating and compatibility across version changes 8 As mentioned above, one of the advantages provided by the data access 9 interface layer is that it enables updating of the geographic database.
Updating can occur in several contexts. For example, in the context of new navigation 11 systems, it may be that a particular navigation system platform is offered for 12 sale over a number of years. It is desired that when the navigation system is 13 sold, the geographic database provided with the system is up-to-date. This 14 objective can be accomplished using the data access interface layer, described above, by installing a storage medium upon which is stored an up-to-date 16 geographic database into the navigation system at the time of delivery to the 17 end-user customer. Furthermore, from the standpoint of the end-user, it is 18 desirable to allow the end-user to obtain updated geographic data after the 19 navigation system is installed over the lifetime of the navigation system.
To meet this latter objective, subscriptions may be offered that provide end-users 21 with updates on a regular basis. The data access interface layer permits the 22 end-user's system to use updated geographic data.
23 Update transactions can be handled using any of several alternatives.
24 One alternative is to update the geographic data at a central location, compile an entirely new geographic database, and prepare new copies of the storage 26 medium with the new database. These new media would then be distributed to 27 end-user subscribers who then replace their old storage media with the new 28 media. This alternative can be used when the media is not rewritable, such as a 29 CD-ROM. If the medium is rewritable, such as a PCMCIA card, the new geographic database can be applied directly to the old medium. Another 31 alternative is to provide updated geographic data in the form of a separate file
-54-t 1 or database that contains a listing of changes relative to the version of the 2 geographic database in the end-user's system. This separate file can be located 3 on the same medium as the original geographic database (in the case of 4 re-rewritable media), or on a separate medium (in the case that the original medium is read-only). Once the separate file can be accessed in the navigation G system, it is used together with the original geographic database. The updated 7 data from the separate file are transparently applied to the appropriate data 8 entities as they are accessed by the navigation application through the data 9 access interface layer (e.g., a "look aside"). This function 811 may be implemented in the physical-to-logical subsystem 244 of the interface layer.
11 The updated geographic data can be distributed by various different means, 12 including wireless broadcast or updating stations, as disclosed in issued US Patents 13 US 6,289,276, US 6,131,066, US 6,018,695, and US 5,951,620 entitled SYSTEM
14 AND METHOD FOR DISTRIBUTING INFORMATION FOR STORAGE MEDIA.
16 The data access interface layer not only allows the navigation system to 17 use updated geographic data, but also allows the navigation system to use 18 geographic data provided in new formats. The data access interface layer 41 19 and the logical data model can be extended to take advantage of new data attributes or values that are added to the geographic database in the future as 21 requirements arise. New attributes or values can appear in the map coverage 22 data or in the physical storage format. As new map data features emerge, these 23 can be included on the geographic map data media and can be used by any 24 navigation systems that support them. Thus, the physical storage format may evolve to include additional types of information beyond what it currently 26 provided. However, because the data access interface layer isolates the 27 navigation application from the physical geographic database, the navigation 28 application manufacturer need not upgrade its navigation application software 29 every time the geographic database is updated. In addition, the end-user who has an installed navigation system can acquire updated geographic databases 31 over the years and be assured that they will work in his navigation system even 32 if the updated geographic databases include new types of information.
Because
-55-1 the geographic database publisher-distributor does not have to produce multiple 2 different geographic database formats for a variety of different hardware 3 platforms, the geographic databases can be made available to end-users at 4 potentially lower costs, with fewer distribution complexities, and possibly more frequently, as well as with other advantages.
6 If new attributes are added to the physical storage format, or if other 7 changes to the physical storage format are implemented, the version level of the 8 physical storage format may evolve beyond the version level of the navigation 9 application program. Thus, when an updated geographic database is installed in a navigation system, it is possible for the logical data model format and 11 physical storage format version levels to differ. As database version levels 12 increase, as reflected in the physical storage format, forward compatibility is 13 provided by means of the data access interface layer to maintain the viability of 14 the end user's system. Forward compatibility can be supported in this manner for a long time, possibly up to ten years. Some data version changes may 16 consist of adding new attributes or values, and therefore one way that the data 17 access interface layer can accommodate new attribute or values is to filter out 18 the new data, reordering and transforming them to fit the old template.
19 Compatibility across different version levels is provided by metatranslation. Metatranslation uses a set of tables for each version level.
21 Referring to FIG. 3, these metadata tables 259 reside on the storage medium 22 (e.g. on the CD-ROM or PCMCIA card). The metadata tables include 23 information that describes the location, size, type, and content of the various 24 data attributes and values appearing in a given database entity. In the physical-to-logical data translation subsystem 244, conversion between the compressed 26 physical storage format on the medium to the decompressed intermediate format 27 usable by the query logic subsystem 210 utilizes a metadata table for each 28 physical storage format data representation. The physical storage format 29 metadata is used to extract a data element relative to the beginning of a particular physical storage format entity. The data element then undergoes a 31 translation or conversion process which is controlled by the information in the 32 metadata tables.
-56-1 Metadata tables may be located on the storage medium for each data 2 version from the earliest version to a current version. The version level of the 3 software library that forms the data access interface layer 41 is used to identify 4 the appropriate set of metadata to use.
The metadata tables are read from the storage medium through the 6 operating system kernel and physical devices subsystem (i.e., the operation 7 system isolation layer 302 and the media device isolation layer 300). From 8 these subsystems, the resource management subsystem 220 provides the 9 metadata to the physical-to-logical data translation subsystem 244 where the metatranslation is performed. In a preferred embodiment, the metadata are 11 physically read from the medium only at initialization time. The metadata 12 tables are read into memory that is allocated from the heap on a semipermanent 13 basis, so that the metatranslation process can access the tables efficiently for 14 each data access.
Metadata tables can also be used to provide backward compatibility.
16 Some navigation system developers may design their systems so that the 17 navigation application software can be upgraded or updated over time after the 18 navigation system is sold. This upgradability may be offered to take advantage 19 of new features offered in the geographic database. In order to allow a newer navigation application software program to use an older version of a geographic 21 database, a metadata table, for example table 813, can be provided in the new 22 version of the navigation application software. Like the metadata table 23 provided on the storage medium, the information in the metadata table provided 24 with the newer version of navigation application software is used to compare the version levels of the navigation software and the physical storage format.
26 The information in these metadata tables is provided to the physical-to-logical 27 subsystem 244 at initialization time to perform any necessary attribute 28 conversions. As mentioned above, if the version' levels of the navigation 29 application program and the physical storage format are the same, the metadata conversion step is unnecessary and the physical-to-logical subsystem can skip 31 this conversion step.
-57-1 X. Further alternative embodiments 2 The above embodiments disclose an interface layer system that can be 3 used in a navigation system. In one present embodiment, the navigation system 4 is an in-vehicle navigation system that is installed and located in an end-user's vehicle. The type of vehicle may include automobiles, trucks, buses, and so on.
6 The end-users of such a system may include individuals who own or lease their 7 own vehicles, as well as fleet owners, businesses, car rental agencies, trucking 8 companies, transportation companies, and so on. In alternative embodiments, 9 the navigation system may be other-than-in-vehicle. For example, the navigation system may be a hand-held unit that a person can carry on his/her 11 person. Also, the navigation system may be installed in a non-mobile location, 12 such as at a service station, car rental agency, a personal computer and so on.
13 Still further, the navigation system may be installed and used by traffic control 14 agencies, police, delivery services, and so on.
In a preferred embodiment, the interface layer is statically-linked to the 16 navigation application programs after the application programs are compiled in 17 order to form an executable module. In an alternative embodiment, the 18 interface layer may be dynamically linked to the navigation applications.
19 An alternative embodiment is shown in FIG. 8. In this alternative embodiment, asynchronous I/O is supported by the navigation system's media 21 device driver 609. Implementation of asynchronous I/O requires that when a 22 disk I/O is submitted to the kernel, the process invoking the request can 23 continue to run and is notified when the I/O request is complete. In such an 24 alternative, a shared code version of the I/O manager submits the I/O
request and return control to the navigation application. When the I/O is completed, an 26 asynchronous event would be posted to a client message queue for servicing.
27 In this alternative, the I/O manager 270 may exist completely within the 28 statically-linked portion 271 of resource management subsystem 220, i.e the I/O
29 manager 270 would be linked with each of the navigation application programs 200. In this alternative, the I/O queue is implemented as a control structure
-58-1 611 in the memory pool. In this case, interprocess communication techniques, 2 such as semaphore protection, are used to manage contention to the I/O queue 3 from multiple processes. The rest of the features of the interface layers systems 4 would be similar to those described above.
S XI. Conclusion 6 The data access interface layer described above provides a uniform 7 interface that is incorporated in a navigation system. The data access interface 8 layer can be utilized on different navigation system platforms developed by 9 different manufacturers. The data access interface layer functions regardless of the hardware platform or end-user functionality of the navigation system. The 11 data access interface layer provides a common transparent mechanism for 12 accessing geographic data stored on a physical medium. The data access 13 interface layer isolates the navigation application programs from the details of 14 the organization of the geographical data and the physical requirements of the specific storage medium implementation.
16 Because the data access interface layer presents a uniform, consistent 17 view of the geographic database, navigation system developers can continue to 18 develop and enhance their navigation systems to provide new and better 19 functionality without concern about interfacing with the physical medium and the storage format of the geographic database. Navigation system developers 21 can therefore focus on providing new types of navigation application programs 22 and new hardware platforms and operating systems having access to a 23 consistent geographic data interface. From the end-user's point of view, the 24 data access interface layer provides that updated geographic data can be used in the end-user's navigation system, thereby reducing the risk that the navigation 26 system might become obsolete due to the geographic data version becoming out 27 of date.
28 It is intended that the foregoing detailed description be regarded as 29 illustrative rather than limiting and that it is understood that the following
-59-claims including all equivalents are intended to define the scope of the invention.
-60-

Claims (81)

We claim:
1. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program that provides navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising an interface layer located logically between said navigation application program and said geographic database, said interface layer comprising programming for:
accepting and processing requests for geographic data from the navigation application program; and decompressing geographic data from said physical storage format and providing said geographic data to said navigation application program in a decompressed format.
2. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program that provides navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising programming for:
accepting and processing requests for geographic data from the navigation application program; and translating geographic data from said physical storage format and providing said geographic data to said navigation application program; and providing a cursor to said navigation application program in response to a request for geographic data from said navigation application program, said cursor including multiple records, and wherein programming for providing a cursor is responsive to programming for translation and is adapted to receive said geographic data therefrom.
3. The invention of claim 2 wherein said programming providing a cursor further comprises:

programming for providing a first portion of said cursor in a logical data model format;
and programming for providing an entity identifier to a first remainder of said cursor wherein said first remainder is maintained in a compressed format.
4. The invention of claim 3 wherein said programming providing a cursor further comprises:
a fetch next function that provides a second portion of said cursor in said logical data model format, said second portion comprised of said first remainder.
5. The invention of claim 1 wherein said interface layer further comprises:
programming for managing indexes responsive to said programming that accepts and processes requests and to index information, said programming for managing indexes further provides an identifier for obtaining geographic data on said physical storage medium for responding to said requests by said navigation application program.
6. The invention of claim 5 wherein at least a portion of said index information is located on said physical storage medium, and wherein said programming for managing indexes provides parcel identifiers for obtaining pointers to parcels on said physical storage medium containing geographic data for responding to said requests by said navigation application program.
7. The invention of claim 5 wherein said programming for managing indexes further comprises:
an interface for translating a specific entity identifier passed from said navigation application program to a parcel identifier for a parcel on said physical storage medium.
8. The invention of claim 5 wherein said programming for managing indexes further comprises:
an interface for taking an index specifier and query parameters from said programming that accepts and processes requests and returning a set of parcel identifiers.
9. The invention of claim 5 further comprising:

programming for reading said index information from said physical storage medium into a buffer, wherein said programming for managing indexes is coupled to said buffer to obtain said index information therefrom.
10. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program that provides navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising programming for:
accepting and processing requests for geographic data from the navigation application program; and translating geographic data from said physical storage format and providing said geographic data to said navigation application program in a logical data model format, wherein said logical data model format includes uncompressed entity records of fixed lengths, and wherein said programming that translates further comprises:
unpacking said geographic data from said physical storage format into a decompressed intermediate format; and transforming said geographic data from said decompressed intermediate format into data entities in said logical data format for returning to said navigation application program.
11. The invention of claim 1 wherein said programming for decompressing geographic data further comprises:
a first interface for translation of geographic database entities from the physical storage format into an intermediate format; and a second interface for translation of geographic database entities from said intermediate format to the decompressed format in which said geographic data are provided to programming for accepting and processing requests.
12. The invention of claim 11 wherein said programming for decompressing further comprises:

programming responsive to a metadata table on said physical storage medium and said first interface and adapted to translate said geographic data in said intermediate format at a first version level to an intermediate format at a second version level and provide said geographic data in said intermediate format at a second version level to said second interface.
13. The invention of claim 1 wherein said interface layer further comprises:
programming for managing resources comprising:
programming for allocating and freeing memory of said navigation system for use as a memory pool by said interface layer; and programming for accessing a cache memory buffer in said memory pool that stores a parcel read from said physical storage medium, said parcel identified by means of a parcel identifier.
14. The invention of claim 13 wherein said programming for managing resources further comprises:
programming for initiating an I/O transaction from the physical storage medium to read said parcel therefrom if said programming for accessing a cache memory buffer finds that said parcel is not stored in said cache memory buffer.
15. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program that provides navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising programming for:
accepting and processing requests for geographic data from the navigation application program;
translating geographic data from said physical storage format and providing said geographic data to said navigation application program in a logical data model format, allocating and freeing memory of said navigation system for use as a memory pool by said interface layer;
accessing a cache memory buffer in said memory pool that stores a parcel read from said physical storage medium, wherein said parcel can be identified by means of a parcel identifier initiating an I/O transaction from the physical storage medium to read said parcel therefrom if said cache memory buffer accessing means finds that said parcel is not stored in said cache memory buffer, wherein said programming for initiating an I/O transaction stores parcel identifiers in a queue and reorders parcel identifiers while in said queue.
16. The invention of claim 15 wherein said programming for initiating an I/O
transaction translates said parcel identifiers to physical media addresses while in said queue.
17. The invention of claim 15 wherein said navigation system further includes a media device driver and wherein said programming for initiating an I/O transaction obtains from said media device driver a physical read head position and uses said physical read head position when reordering said parcel identifiers.
18. The invention of claim 13 wherein said programming for managing resources further comprises:
programming for locking a cache memory when a parcel is stored therein and a buffer address is returned to said programming that decompresses geographic data.
19. The invention of claim 13 wherein said programming for managing resources further comprises:
programming for resizing said memory pool in response to a call from said navigation application program.
20. The invention of claim 1 wherein the physical storage format of the geographic database organizes said geographic data into a plurality of parcels, and wherein said interface layer further comprises:
programming for associating said requests with parcels in said physical storage format and causing said parcels to be read from said physical storage medium.
21. The invention of claim 1 wherein the physical storage medium comprises a CD-ROM disk.
22. The method of claim 1 wherein said programming for decompressing further comprises:
programming for transforming said geographic data from said physical storage format into an intermediate decompressed format; and programming for transforming said geographic data from said intermediate decompressed format to said decompressed format usable by said navigation application program.
23. A method of using a computer-based navigation system wherein said navigation system includes navigation application program functions wherein said navigation application program functions are adapted to use a geographic database stored on a computer-readable storage medium in a physical storage format, the method comprising:
reading a metadata file from said storage medium;
storing a portion of said metadata file in memory;
accepting a request from one of said navigation application program functions for geographic data;
transforming geographic data stored in said physical storage format into a format usable by said navigation application including using said metadata file to translate from a version level of said physical storage format to a version level of said navigation application program functions; and providing said transformed geographic data to said one of said navigation application program functions.
24. A method of using a computer-based navigation system wherein said navigation system includes navigation application program functions wherein said navigation application program functions are adapted to use a geographic database stored on a computer-readable medium in a physical storage format, the method comprising:
accepting a request from one of said navigation application program functions for geographic data;
using an index to identify the geographic data in said physical storage format for responding to said request;
transforming geographic data stored in said physical storage format into a format usable by said navigation application program functions; and after a plurality of data entities are identified in response to said request from said one of said navigation application program functions, providing a first partial result set of said plurality of data entities in said format usable by said navigation application program functions to said one of said navigation application program functions.
25. The method of claim 24 further comprising the step of:
if said plurality of data entities exceeds a first threshold, providing a first partial result set of said plurality of data entities up to said first threshold in said format usable by said navigation application program functions to said one of said navigation application program functions and maintaining entity identifiers for a portion of said plurality data entities exceeding said first threshold.
26. The method of claim 24 further comprising the steps of:
if said plurality of data entities exceeds a first threshold and a second threshold greater than said first threshold, providing a first partial result set of said plurality of data entities up to said first threshold in said format usable by said navigation application program functions to said one of said navigation application program functions, maintaining entity identifiers for a portion of said plurality data entities exceeding said first threshold, and maintaining a reference cursor to reexecute said request for geographic data for data entities exceeding said second threshold.
27. A method by which navigation systems implemented on different hardware platforms can use copies of a geographic database having a same format, the method comprising the steps of:
providing copies of interface layer programming to manufacturers of said navigation systems implemented on different hardware platforms, wherein said interface layer programming provides a common interface from which a navigation application in each of said navigation systems implemented on different hardware platforms can request geographic data contained in a geographic database associated therewith, wherein the geographic database associated with each of said navigation systems is in said same format; and installing said copies of said interface layer programming in each of said navigation systems implemented on said different hardware platforms.
28. The invention of claim 27 further comprising the steps of:
when operating each of said navigation systems implemented on different hardware platforms, using said navigation application to request geographic data from said interface layer programming according to said common interface; and using said interface layer programming to access and read data from the geographic database in the same format associated therewith to satisfy requests for geographic data from said navigation application.
29. The invention of claim 27 wherein said interface layer programming further comprises:
query logic programming that receives requests from the navigation application for geographic data;
data transformation programming that transforms geographic data from a physical storage format of a physical storage medium upon which said geographic database is stored; and data return programming that provides said transformed geographic data to said navigation application in response to said requests.
30. The invention of claim 29 wherein said interface layer programming further comprises:

indexes management programming responsive to said query logic programming and comprising:
programming that associates said requests from said navigation application with parcel identifiers associated with parcels in said physical storage format containing geographic data; and programming that provides said parcel identifiers to memory management library programming to obtain said parcels to provide to said data transformation programming for transformation therein.
31. The invention of claim 30 wherein said indexes management programming further comprises:
programming that obtains said parcel identifiers from said geographic database, and programming that obtains pointers to parcels on said physical storage medium containing geographic data for responding to said requests by said navigation application.
32. The invention of claim 30 wherein said programming that manages indexes further comprises:
programming that translates specific entity identifiers passed from said navigation application to parcel identifiers for parcels on said physical storage medium.
33. The invention of claim 30 wherein said programming that manages indexes further comprises:
programming that takes index specifiers and query parameters from said query logic programming and returns a set of parcel identifiers.
34. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program that provides navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising programming for:

accepting and processing requests for geographic data from the navigation application program; and translating geographic data from said physical storage format and providing said geographic data to said navigation application program, wherein said programming for translating is responsive to metadata provided with said geographic data and which is used to translate said geographic data at a first version level to a second version level and provide said geographic data at said second version level to said navigation application program.
35. The invention of claim 34 wherein said metadata comprises tables for different version levels.
36. The invention of claim 35 wherein said tables are provided for each data version level from an earliest version level to a current version level.
37. The invention of claim 37 wherein said storage medium comprises one of a CD-ROM disk and PCMCIA card.
38. The invention of claim 34 wherein said metadata is used to provide backward compatibility.
39. The invention of claim 34 wherein said metadata allows a newer navigation application software program to use an older version of a geographic database.
40. The method of claim 23 wherein said metadata file comprises tables for different version levels, and wherein the method further comprises the step o~
using a version level of a data access interface layer that performs the step of accepting a request from one of the navigation applications for geographic data to identify which of said tables to use.
41. The invention of claim 23 wherein said metadata file includes information that describes content of various data attributes and values appearing in a given database entity at a given version level.
42. The method of claim 23 wherein said step of transforming further comprises:
converting from said physical storage format into a decompressed intermediate format;
and converting from said decompressed intermediate format into the format useable by the navigation application.
43. The method of claim 23 wherein said step of transforming further comprises:
using said metadata file to extract a data element relative to a beginning of a particular physical storage format entity.
44. The method of claim 23 wherein the step of reading a metadata file from said storage medium is performed through an operating system kernel.
45. The method of claim 23 wherein the step of reading a metadata file from said storage medium is performed through a physical devices subsystem that includes an operation system isolation layer and a media device isolation layer.
46. The method of claim 23 wherein the step of reading a metadata file from said storage medium is performed at initialization.
47. The method of claim 23 further comprising the step of:
maintaining the metadata file in memory during operation of the navigation system so that said metadata file can be used during subsequent data accesses from said storage medium.
48. A computer program product for use in a navigation system wherein the navigation system includes a navigation application program for providing navigating features to a user of the navigation system and a geographic database stored on a physical storage medium in a computer-readable physical storage format, said computer program product comprising an interface layer comprising programming for:
providing a C language data structure view to the navigation application program;
accepting and processing requests for geographic data from the navigation application program; and translating geographic data from said physical storage format and providing said geographic data to said navigation application program as a C language data structure in a fully decompressed form.
49. The invention of claim 1 wherein said geographic data is provided to said navigation application program in a generic ASCII format.
50. The invention of claim 1 wherein said geographic data is provided to said navigation application program as data entity records of fixed lengths without cross-reference information.
51. In a navigation system that includes application programs that provide navigation-related functions, wherein the navigation system uses geographic data stored on a computer-readable medium, interface layer programming comprising:
a query subsystem that accepts requests for geographic data from the application programs and provides responses thereto;
an indexes management subsystem that identifies a location of data on the medium at which is located data required to respond to said requests received by said query subsystem;
a physical-to-logical subsystem that transforms data read from the medium into a format used in said responses; and a resources management subsystem that provides access to memory resources and I/O of the navigation system for use by said query subsystem, said indexes management subsystem, and said physical-to-logical subsystem.
52. The invention of claim 51 wherein said resources management subsystem comprises:
a memory manager that manages the memory resources of said navigation system that are allocated to said interface layer programming.
53. The invention of claim 52 wherein the memory resources managed by said memory manager includes a cache for parcels of data read from said medium and a general purpose heap used for said query subsystem, said indexes management subsystem, and said physical-to-logical subsystem.
54. The invention of claim 53 wherein said resources management subsystem comprises:
an I/O manager that receives requests for parcels of data to be read from said medium when said parcels are not found in said cache.
55. The invention of claim 53 wherein said I/O manager includes an I/O message queue that contains I/O transactions that include said requests for parcels.
56. The invention of claim 55 wherein said I/O transactions include a priority associated therewith.
57. The invention of claim 54 further comprising:
a physical storage format address mapper that provides to the I/O manager a physical address for a parcel relative to a beginning of a file in which said parcel is located.
58. The invention of claim 57 further comprising:
a file directory mapper that provides to the I/O manager a starting location of said file on said medium.
59. The invention of claim 54 further comprising:
a physical storage format address mapper that translates a parcel ID by which a parcel is identified to a physical sector address and sector count on the medium and returns said physical sector address and sector count to said I/O manager.
60. The invention of claim 59 further comprising:
a file address mapper used by said physical storage format address mapper to locate a file containing the parcel on the medium.
61. The invention of claim 59 wherein said physical storage format address mapper returns multiple addresses for redundantly placed parcels.
62. The invention of claim 59 wherein said I/O manager chooses which of said redundantly placed parcels to read from the medium based upon a current read head location.
63. The invention of claim 54 further comprising:
a file directory mapper that provides to the I/O manager starting locations of each file on said medium.
64. The invention of claim 63 wherein said starting locations are provided as physical media addresses.
65. The invention of claim 64 wherein said physical media addresses conform to ISO-9660.
66. The invention of claim 54 further comprising:
a media device isolation layer that receives a media address, a parcel extent, and an address of a cache buffer from the I/O manager.
67. The invention of claim 66 wherein said media device isolation layer provides a scattered read device capability.
68. The invention of claim 66 wherein said I/O manager provides said media device isolation layer with an array representing a sequence of physical media addresses, extents, and memory buffer pointers.
69. The invention of claim 68 wherein said array has a size which is configurable.
70. The invention of claim 53 wherein each of said parcels is identified by a parcel ID, wherein said parcel ID comprises a first part and a second part, and wherein said first part comprises an offset from a start of a file containing the parcel and wherein said second part comprises a size of said parcel.
71. The invention of claim 70 wherein said parcel ID comprises a third part, wherein said third part comprises an indication whether a redundant copy of the data in said parcel is located in another parcel located on said medium.
72. The invention of claim 71 further comprising:
a table located in a memory of said navigation system containing locations at which redundant copies of parcels are located on said medium.
73. The invention of claim 52 further comprising a memory pool formed of the memory resources of said navigation system by said memory manager.
74. The invention of claim 74 wherein said memory pool is divided into multiple memory blocks, wherein each of said multiple memory blocks is a contiguous area of memory of a predetermined fixed size.
75. The invention of claim 74 wherein said memory manager receives requests for buffers of given sizes from tasks, allocates memory blocks of said given sizes to satisfy said requests for buffers, and assigns buffer ID's to said allocated memory blocks.
76. In a navigation system having navigation application programs and that uses geographic data stored on a physical storage medium in a computer-readable physical storage format, an improvement comprising:
an interface layer that defines a first set of calls that can be used by said navigation application programs to access a set of geographic data entities on the physical storage medium, wherein said set of geographic data entities includes one o~ a single entity, a list of multiple entities, and no data entities, and further wherein said geographic data entities in said set of geographic data entities accessed by said navigation application programs using said interface layer conform to a logical data model which has a decompressed format, and wherein the interface layer accepts calls that allow the navigation application programs to formulate queries for data, and wherein said calls may be qualified by spatial and non-spatial attributes of desired entities, and wherein the attributes used to qualify a query for data can be used singly or in combination and can specify a range or a single value, and further wherein the geographic data on the physical storage medium include spatially organized data, non-spatially organized data, and index data, and wherein the spatially organized data comprises data that represent segments of roads, and wherein said spatially organized data are organized into parcels which contain the geographic data entities representing geographic features encompassed within physical geographical localities within a represented geographic region, and wherein said non-spatially organized data comprise data representing names of navigable features, and wherein said index data include indexes that relate the spatially organized data and non-spatially organized data to each other.
77. The invention of claim 76 wherein said indexes include at least one of a kd-tree index and a B-tree index.
78. The invention of claim 76 wherein the geographic data on said physical storage medium are organized into parcels each of which includes a plurality of data entities and wherein each of said parcels is identified by a unique parcel ID.
79. The invention of claim 78 wherein a size of each of said parcels is related to a physical sector size on the physical storage medium.
80. The invention of claim 78 wherein the interface layer accesses data from the physical storage medium in whole parcels and loads whole parcels into memory in a single physical read in order to resolve said queries.
81. A method of operating a navigation system that includes navigation application programs that are loaded into a memory of said navigation system and executed, and further wherein said navigation system uses geographic data stored on a physical storage medium, the method comprising the steps of:
allocating a resizable portion of said memory for an interface layer program that accepts requests for geographic data from said navigation application programs, determines locations on said physical storage medium at which are located geographic data for responding to said requests, accesses said geographic data from said locations, stores said geographic data accessed from said physical storage medium in a cache formed of said resizable amount of memory, transforms geographic data stored in said cache into a decompressed format and returns geographic data in said decompressed format to said navigation application programs; and resizing said resizable portion of memory in response to a request from said one of said navigation application programs.
CA002219037A 1996-10-25 1997-10-23 Interface layer for navigation system Expired - Lifetime CA2219037C (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/740,298 US6047280A (en) 1996-10-25 1996-10-25 Interface layer for navigation system
US08/740,298 1996-10-25

Publications (2)

Publication Number Publication Date
CA2219037A1 CA2219037A1 (en) 1998-04-25
CA2219037C true CA2219037C (en) 2004-10-12

Family

ID=24975909

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002219037A Expired - Lifetime CA2219037C (en) 1996-10-25 1997-10-23 Interface layer for navigation system

Country Status (5)

Country Link
US (3) US6047280A (en)
EP (1) EP0838771B1 (en)
JP (1) JPH10253367A (en)
CA (1) CA2219037C (en)
DE (1) DE69732755T2 (en)

Families Citing this family (191)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040139049A1 (en) * 1996-08-22 2004-07-15 Wgrs Licensing Company, Llc Unified geographic database and method of creating, maintaining and using the same
JP3143927B2 (en) * 1996-09-20 2001-03-07 トヨタ自動車株式会社 Position information providing system and device
US6047280A (en) * 1996-10-25 2000-04-04 Navigation Technologies Corporation Interface layer for navigation system
US10839321B2 (en) 1997-01-06 2020-11-17 Jeffrey Eder Automated data storage system
US6272429B1 (en) * 1997-12-15 2001-08-07 Ronnie Dansby Detailed information database management system
US6519686B2 (en) * 1998-01-05 2003-02-11 Intel Corporation Information streaming in a multi-process system using shared memory
JP3546680B2 (en) * 1998-01-26 2004-07-28 トヨタ自動車株式会社 Navigation device
JP3927304B2 (en) * 1998-02-13 2007-06-06 トヨタ自動車株式会社 Map data access method for navigation
EP1073957B1 (en) * 1998-03-23 2003-05-21 Microsoft Corporation Application program interfaces in an operating system
US6792432B1 (en) * 1998-03-31 2004-09-14 Sybase, Inc. Database system with methods providing high-concurrency access in B-Tree structures
US6253226B1 (en) * 1998-06-24 2001-06-26 Oracle Corporation Duration-based memory management of complex objects
US6327606B1 (en) * 1998-06-24 2001-12-04 Oracle Corp. Memory management of complex objects returned from procedure calls
JP3402204B2 (en) * 1998-07-08 2003-05-06 日本電気株式会社 Database control method and device
US6263332B1 (en) * 1998-08-14 2001-07-17 Vignette Corporation System and method for query processing of structured documents
US6412053B2 (en) 1998-08-26 2002-06-25 Compaq Computer Corporation System method and apparatus for providing linearly scalable dynamic memory management in a multiprocessing system
US6732120B1 (en) * 1998-09-03 2004-05-04 Geojet Information Solutions Inc. System and method for processing and display of geographical data
US6393149B2 (en) 1998-09-17 2002-05-21 Navigation Technologies Corp. Method and system for compressing data and a geographic database formed therewith and methods for use thereof in a navigation application program
US6519594B1 (en) * 1998-11-14 2003-02-11 Sony Electronics, Inc. Computer-implemented sharing of java classes for increased memory efficiency and communication method
US6438561B1 (en) * 1998-11-19 2002-08-20 Navigation Technologies Corp. Method and system for using real-time traffic broadcasts with navigation systems
US6718332B1 (en) * 1999-01-04 2004-04-06 Cisco Technology, Inc. Seamless importation of data
US6292743B1 (en) 1999-01-06 2001-09-18 Infogation Corporation Mobile navigation system
JP2000222214A (en) * 1999-02-01 2000-08-11 Hitachi Ltd Geographical information display controller
US6343301B1 (en) * 1999-02-24 2002-01-29 Navigation Technologies Corp. Method and system for collecting data for updating a geographic database
US6282540B1 (en) * 1999-02-26 2001-08-28 Vicinity Corporation Method and apparatus for efficient proximity searching
US6694320B1 (en) * 1999-03-01 2004-02-17 Mitel, Inc. Branding dynamic link libraries
US6516320B1 (en) * 1999-03-08 2003-02-04 Pliant Technologies, Inc. Tiered hashing for data access
AU3181900A (en) * 1999-03-26 2000-10-16 British Telecommunications Public Limited Company Computer system
JP3659062B2 (en) * 1999-05-21 2005-06-15 株式会社日立製作所 Computer system
US7100000B1 (en) * 1999-05-28 2006-08-29 International Business Machines Corporation System and methods for processing audio using multiple speech technologies
US6418454B1 (en) 1999-05-28 2002-07-09 Oracle Corporation Method and mechanism for duration-based management of temporary LOBs
US6460046B1 (en) * 1999-06-01 2002-10-01 Navigation Technologies Corp. Method and system for forming, storing and using sets of data values
WO2000079218A1 (en) * 1999-06-22 2000-12-28 Mitsubishi Denki Kabushiki Kaisha Mobile terminal and server in navigation system
US7356559B1 (en) * 1999-07-01 2008-04-08 Affinity Internet, Inc. Integrated platform for developing and maintaining a distributed multiapplication online presence
US7219327B1 (en) * 1999-07-01 2007-05-15 Affinity Internet, Inc. Extensible data model for use in an integrated platform for creating a distribution multiapplication online presence
US7107286B2 (en) 1999-07-26 2006-09-12 Geoqwest International Inc. Integrated information processing system for geospatial media
US6681231B1 (en) 1999-07-26 2004-01-20 The Real Estate Cable Network, Inc. Integrated information processing system for geospatial media
US7644366B1 (en) * 1999-07-30 2010-01-05 Computer Associates Think, Inc. Method and system for displaying a plurality of discrete files in a compound file
US6842758B1 (en) * 1999-07-30 2005-01-11 Computer Associates Think, Inc. Modular method and system for performing database queries
US6581054B1 (en) 1999-07-30 2003-06-17 Computer Associates Think, Inc. Dynamic query model and method
CA2281331A1 (en) * 1999-09-03 2001-03-03 Cognos Incorporated Database management system
JP4080649B2 (en) * 1999-09-20 2008-04-23 パイオニア株式会社 Human navigation system
US6792416B2 (en) 1999-09-21 2004-09-14 International Business Machines Corporation Managing results of federated searches across heterogeneous datastores with a federated result set cursor object
US7197491B1 (en) 1999-09-21 2007-03-27 International Business Machines Corporation Architecture and implementation of a dynamic RMI server configuration hierarchy to support federated search and update across heterogeneous datastores
US7113939B2 (en) 1999-09-21 2006-09-26 International Business Machines Corporation Architecture to enable search gateways as part of federated search
US6466933B1 (en) 1999-09-21 2002-10-15 International Business Machines Corporation Delayed delivery of query results or other data from a federated server to a federated client until such information is needed
US6370541B1 (en) 1999-09-21 2002-04-09 International Business Machines Corporation Design and implementation of a client/server framework for federated multi-search and update across heterogeneous datastores
US6674434B1 (en) * 1999-10-25 2004-01-06 Navigation Technologies Corp. Method and system for automatic generation of shape and curvature data for a geographic database
JP2001159525A (en) * 1999-11-30 2001-06-12 Mitsubishi Electric Corp Navigation device and recording medium
JP3621316B2 (en) * 1999-11-30 2005-02-16 三菱電機株式会社 In-vehicle information processing equipment
JP3739615B2 (en) * 1999-11-30 2006-01-25 三菱電機株式会社 In-vehicle information processing apparatus and recording medium
JP3621317B2 (en) * 1999-11-30 2005-02-16 三菱電機株式会社 In-vehicle information processing equipment
WO2001040996A1 (en) * 1999-12-01 2001-06-07 The Trustees Of Columbia University In The City Of New York Cache sensitive search (css) tree indexing system and method
US6711562B1 (en) 1999-12-01 2004-03-23 The Trustees Of Columbia University In The City Of New York Cache sensitive search (CSS) tree indexing system and method
US6405128B1 (en) 1999-12-20 2002-06-11 Navigation Technologies Corp. Method and system for providing an electronic horizon in an advanced driver assistance system architecture
US6415226B1 (en) * 1999-12-20 2002-07-02 Navigation Technologies Corp. Method and system for providing safe routes using a navigation system
JP3900778B2 (en) * 2000-02-22 2007-04-04 アイシン・エィ・ダブリュ株式会社 Navigation device
AUPQ599700A0 (en) * 2000-03-03 2000-03-23 Super Internet Site System Pty Ltd On-line geographical directory
US6601073B1 (en) * 2000-03-22 2003-07-29 Navigation Technologies Corp. Deductive database architecture for geographic data
US6424976B1 (en) * 2000-03-23 2002-07-23 Novell, Inc. Method of implementing a forward compatibility network directory syntax
WO2001075679A1 (en) * 2000-04-04 2001-10-11 Metamatrix, Inc. A system and method for accessing data in disparate information sources
KR20000053846A (en) * 2000-04-26 2000-09-05 류재익 Spatio-Temporal Object Model for Land Information System
AU2001274826B2 (en) * 2000-05-12 2006-03-16 Starr Braun-Huon Interactive system for processing and retrieving data relating to a particular destination via a communication device
US6829690B1 (en) * 2000-05-23 2004-12-07 Navteq North America, Llc Method and system for accessing spatially organized geographic data in blocks
JP2002055995A (en) * 2000-05-31 2002-02-20 Canon Inc Method and device for information processing
US6665863B1 (en) * 2000-05-31 2003-12-16 Microsoft Corporation Data referencing within a database graph
US7894986B2 (en) * 2000-06-02 2011-02-22 Navteq North America, Llc Method and system for forming a keyword database for referencing physical locations
WO2001095331A2 (en) * 2000-06-09 2001-12-13 Koninklijke Philips Electronics N.V. Method of implicit partitioning the storage space available on a storage medium
CN101284525A (en) * 2000-06-20 2008-10-15 株式会社日立制作所 Vehicle driving controller
US6681382B1 (en) * 2000-09-18 2004-01-20 Cisco Technology, Inc. Method and system for using virtual labels in a software configuration management system
EP1202030B1 (en) * 2000-10-31 2006-04-26 Matsushita Electric Industrial Co., Ltd. Navigation apparatus
AU2002228720A1 (en) * 2000-11-03 2002-05-15 Motorola, Inc. Data encoding method and system
US20020103974A1 (en) * 2000-11-29 2002-08-01 Giacomini Peter Joseph Method and apparatus for economical cache population
US7010308B2 (en) * 2000-12-13 2006-03-07 Telcontar Managing and querying moving point data
FR2818767B1 (en) * 2000-12-22 2005-03-04 Frederic Cabaud SOFTWARE OBJECT MANAGEMENT SOFTWARE THAT CAN BE USED, ESPECIALLY AS A CHIP CARD EXPLORER
US7530076B2 (en) * 2001-03-23 2009-05-05 S2 Technologies, Inc. Dynamic interception of calls by a target device
WO2002077813A2 (en) * 2001-03-23 2002-10-03 S2 Technologies, Inc. Development and testing system and method
WO2002081252A1 (en) * 2001-04-09 2002-10-17 Siemens Aktiengesellschaft Data storage system for a motor vehicle and method for storing data in a motor vehicle
US20030028503A1 (en) * 2001-04-13 2003-02-06 Giovanni Giuffrida Method and apparatus for automatically extracting metadata from electronic documents using spatial rules
US6427119B1 (en) * 2001-04-16 2002-07-30 General Motors Corporation Method and system for providing multiple entry points to a vehicle navigation route
US6691128B2 (en) * 2001-04-19 2004-02-10 Navigation Technologies Corp. Navigation system with distributed computing architecture
US7031955B1 (en) * 2001-04-27 2006-04-18 I2 Technologies Us, Inc. Optimization using a multi-dimensional data model
US7002579B2 (en) * 2001-05-09 2006-02-21 Cadec Corporation Split screen GPS and electronic tachograph
US7149625B2 (en) * 2001-05-31 2006-12-12 Mathews Michael B Method and system for distributed navigation and automated guidance
US7676224B1 (en) * 2001-07-06 2010-03-09 At&T Mobility Ii Llc Enhanced communication service for predicting and handling communication interruption
US7813741B2 (en) * 2001-07-18 2010-10-12 Decarta Inc. System and method for initiating responses to location-based events
US7028024B1 (en) * 2001-07-20 2006-04-11 Vignette Corporation Information retrieval from a collection of information objects tagged with hierarchical keywords
US7441007B1 (en) 2001-07-30 2008-10-21 At&T Intellectual Property I, L.P. System and method for allowing applications to retrieve properties and configuration information from a persistent store
US7353248B1 (en) * 2001-07-30 2008-04-01 At&T Delaware Intellectual Property, Inc. Application server and method to perform hierarchical configurable data validation
US7191209B1 (en) * 2001-07-30 2007-03-13 Bellsouth Intellectual Property Corp. Application server and method to perform hierarchical configurable data manipulation
US7493210B2 (en) * 2001-08-09 2009-02-17 International Business Machines Corporation Vehicle navigation method
US6583716B2 (en) * 2001-08-15 2003-06-24 Motorola, Inc. System and method for providing location-relevant services using stored location information
US20030059743A1 (en) 2001-08-29 2003-03-27 The Boeing Company Method and apparatus for automatically generating a terrain model for display during flight simulation
US20030061062A1 (en) * 2001-09-26 2003-03-27 Tucker Timothy J. XML data switch
US6424912B1 (en) * 2001-11-09 2002-07-23 General Motors Corporation Method for providing vehicle navigation instructions
US6574554B1 (en) * 2001-12-11 2003-06-03 Garmin Ltd. System and method for calculating a navigation route based on non-contiguous cartographic map databases
US6704645B1 (en) * 2001-12-11 2004-03-09 Garmin Ltd. System and method for estimating impedance time through a road network
US7283905B1 (en) 2001-12-11 2007-10-16 Garmin Ltd. System and method for estimating impedance time through a road network
US6581003B1 (en) * 2001-12-20 2003-06-17 Garmin Ltd. Systems and methods for a navigational device with forced layer switching based on memory constraints
US6545637B1 (en) 2001-12-20 2003-04-08 Garmin, Ltd. Systems and methods for a navigational device with improved route calculation capabilities
US6650996B1 (en) * 2001-12-20 2003-11-18 Garmin Ltd. System and method for compressing data
US6892135B1 (en) 2001-12-21 2005-05-10 Garmin Ltd. Navigation system, method and device with automatic next turn page
US7277794B1 (en) 2001-12-21 2007-10-02 Garmin Ltd. Guidance with feature accounting for insignificant roads
US6847890B1 (en) 2001-12-21 2005-01-25 Garmin Ltd. Guidance with feature accounting for insignificant roads
US7184886B1 (en) 2001-12-21 2007-02-27 Garmin Ltd. Navigation system, method and device with detour algorithm
US6975940B1 (en) 2001-12-21 2005-12-13 Garmin Ltd. Systems, functional data, and methods for generating a route
US6999873B1 (en) 2001-12-21 2006-02-14 Garmin Ltd. Navigation system, method and device with detour algorithm
US7533214B2 (en) * 2002-02-27 2009-05-12 Microsoft Corporation Open architecture flash driver
US6901499B2 (en) * 2002-02-27 2005-05-31 Microsoft Corp. System and method for tracking data stored in a flash memory device
US6978206B1 (en) * 2002-06-21 2005-12-20 Infogation Corporation Distributed navigation system
US7082443B1 (en) 2002-07-23 2006-07-25 Navteq North America, Llc Method and system for updating geographic databases
US20040083465A1 (en) * 2002-10-28 2004-04-29 Weijia Zhang Method and system for connecting to an application programming interface
US7069279B1 (en) * 2002-11-04 2006-06-27 Savaje Technologies, Inc. Timely finalization of system resources
US7430747B2 (en) 2002-12-04 2008-09-30 Microsoft Corporation Peer-to peer graphing interfaces and methods
US7603371B1 (en) * 2002-12-17 2009-10-13 Vignette Corporation Object based system and method for managing information
US7305396B2 (en) * 2002-12-31 2007-12-04 Robert Bosch Gmbh Hierarchical system and method for on-demand loading of data in a navigation system
US7080060B2 (en) * 2003-01-08 2006-07-18 Sbc Properties, L.P. System and method for intelligent data caching
US7239962B2 (en) * 2003-02-21 2007-07-03 Sony Corporation Method and apparatus for a routing agent
US7895065B2 (en) * 2003-02-26 2011-02-22 Sony Corporation Method and apparatus for an itinerary planner
US20060212185A1 (en) * 2003-02-27 2006-09-21 Philp Joseph W Method and apparatus for automatic selection of train activity locations
US20040205394A1 (en) * 2003-03-17 2004-10-14 Plutowski Mark Earl Method and apparatus to implement an errands engine
US7099882B2 (en) * 2003-04-29 2006-08-29 Navteq North America, Llc Method and system for forming, updating, and using a geographic database
DE10335602A1 (en) * 2003-08-04 2005-03-03 Robert Bosch Gmbh Method for updating map data present in a navigable data format
US7293253B1 (en) * 2003-09-12 2007-11-06 Nortel Networks Limited Transparent interface migration using a computer-readable mapping between a first interface and a second interface to auto-generate an interface wrapper
JP2005140676A (en) * 2003-11-07 2005-06-02 Mitsubishi Electric Corp Navigation system
US7251659B1 (en) * 2003-12-04 2007-07-31 Sprint Communications Company L.P. Method and system for managing resource indexes in a networking environment
US20050171685A1 (en) * 2004-02-02 2005-08-04 Terry Leung Navigation apparatus, navigation system, and navigation method
US7984089B2 (en) * 2004-02-13 2011-07-19 Microsoft Corporation User-defined indexing of multimedia content
US7668845B1 (en) * 2004-02-18 2010-02-23 Microsoft Corporation C-tree for multi-attribute indexing
US7970749B2 (en) * 2004-03-11 2011-06-28 Navteq North America, Llc Method and system for using geographic data in computer game development
US7828655B2 (en) * 2004-03-11 2010-11-09 Navteq North America, Llc Application programming interface for geographic data in computer games
US8562439B2 (en) * 2004-03-11 2013-10-22 Navteq B.V. Geographic area templates for computer games
US7967678B2 (en) * 2004-03-11 2011-06-28 Navteq North America, Llc Computer game development factory system and method
US8688803B2 (en) * 2004-03-26 2014-04-01 Microsoft Corporation Method for efficient content distribution using a peer-to-peer networking infrastructure
WO2006020229A1 (en) * 2004-07-17 2006-02-23 Shahriar Sarkeshik Navigation interface system
US20060058953A1 (en) 2004-09-07 2006-03-16 Cooper Clive W System and method of wireless downloads of map and geographic based data to portable computing devices
EP1647960A1 (en) * 2004-10-15 2006-04-19 Leadtek Research Europe B. V. Integrated traffic and position data receiver
US7890492B2 (en) * 2004-11-15 2011-02-15 Zi Corporation Of Canada, Inc. Organizing pointers to objects in an array to improve the speed of object retrieval
JP4334464B2 (en) * 2004-12-02 2009-09-30 パイオニア株式会社 Information update device, information distribution device, information processing system, method thereof, program thereof, and recording medium recording the program
US8205058B2 (en) 2004-12-10 2012-06-19 International Business Machines Corporation Resource management for data storage services
DE102005014273B4 (en) * 2005-03-24 2012-04-05 Dspace Digital Signal Processing And Control Engineering Gmbh Comparison of interfaces between software components
JP4851726B2 (en) * 2005-03-30 2012-01-11 クラリオン株式会社 In-vehicle device
JP4581896B2 (en) * 2005-08-02 2010-11-17 株式会社デンソー Navigation device and program
US8255640B2 (en) * 2006-01-03 2012-08-28 Apple Inc. Media device with intelligent cache utilization
US7925320B2 (en) 2006-03-06 2011-04-12 Garmin Switzerland Gmbh Electronic device mount
US8376857B1 (en) 2006-04-28 2013-02-19 Navteq B.V. Multi-player online game player proximity feature
US7792864B1 (en) * 2006-06-14 2010-09-07 TransUnion Teledata, L.L.C. Entity identification and/or association using multiple data elements
US7628704B1 (en) 2006-06-15 2009-12-08 Navteq North America, Llc Geographic data collection using game play
US7693068B2 (en) * 2006-11-07 2010-04-06 Tekelec Systems, methods, and computer program products for providing a distributed hardware platform interface (HPI) architecture
JP4900725B2 (en) * 2008-03-31 2012-03-21 アイシン・エィ・ダブリュ株式会社 Map update system and map update program
KR100898263B1 (en) * 2008-04-24 2009-05-18 팅크웨어(주) Quick-search method and apparatus of path displaying terminal
US8719812B1 (en) * 2008-06-30 2014-05-06 Emc Corporation Methods, systems, and computer readable media for dynamically modifying and utilizing a software package description for software installation
US8725474B2 (en) * 2008-10-01 2014-05-13 Navteq B.V. Bezier curves for advanced driver assistance system applications
US20100082564A1 (en) * 2008-10-01 2010-04-01 Navteq North America, Llc Spatial Index for Locating Geographic Data Parcels Stored on Physical Storage Media
US8762046B2 (en) * 2008-10-01 2014-06-24 Navteq B.V. Creating geometry for advanced driver assistance systems
US8990004B2 (en) * 2008-12-17 2015-03-24 Telenav, Inc. Navigation system with query mechanism and method of operation thereof
KR20100085564A (en) * 2009-01-21 2010-07-29 삼성전자주식회사 Data processing system and data processing method thereof
US8812475B2 (en) * 2009-04-20 2014-08-19 International Business Machines Corporation Facilitating object searches in virtual worlds
US8301364B2 (en) * 2010-01-27 2012-10-30 Navteq B.V. Method of operating a navigation system to provide geographic location information
JP5355784B2 (en) * 2010-04-16 2013-11-27 三菱電機株式会社 Data access method and data access apparatus
DE102010017478A1 (en) * 2010-06-21 2011-12-22 Krauss-Maffei Wegmann Gmbh & Co. Kg Method for extracting data from a view database for constructing a simulation database
US8990181B2 (en) * 2010-09-16 2015-03-24 Standard Microsystems Corporation Method and system for transferring data between a host device and an external device
JP5353926B2 (en) * 2011-03-09 2013-11-27 株式会社デンソー Navigation device
US8364725B2 (en) 2011-03-24 2013-01-29 International Business Machines Corporation Bidirectional navigation between mapped model objects
US8392408B1 (en) 2011-05-04 2013-03-05 Google Inc. Coordinating successive search queries using a query cursor
US20120303750A1 (en) * 2011-05-26 2012-11-29 Mike Anderson Cloud-assisted network device integration
US9237183B2 (en) 2011-05-26 2016-01-12 Candi Controls, Inc. Updating a domain based on device configuration within the domain and remote of the domain
US9542241B2 (en) 2011-07-12 2017-01-10 Harman International Industries, Incorporated Navigation application interface
CN102279808A (en) * 2011-09-06 2011-12-14 晨星软件研发(深圳)有限公司 Method and device for managing video memory of embedded equipment
US8280414B1 (en) 2011-09-26 2012-10-02 Google Inc. Map tile data pre-fetching based on mobile device generated event analysis
US9110933B1 (en) 2011-11-04 2015-08-18 Google Inc. Processing data triggers in an untrusted environment based on information stored in a trusted environment
US8886715B1 (en) * 2011-11-16 2014-11-11 Google Inc. Dynamically determining a tile budget when pre-fetching data in a client device
US9148329B1 (en) * 2011-11-30 2015-09-29 Google Inc. Resource constraints for request processing
US9305107B2 (en) 2011-12-08 2016-04-05 Google Inc. Method and apparatus for pre-fetching place page data for subsequent display on a mobile computing device
US9197713B2 (en) 2011-12-09 2015-11-24 Google Inc. Method and apparatus for pre-fetching remote resources for subsequent display on a mobile computing device
US9235607B1 (en) 2012-03-29 2016-01-12 Google Inc. Specifying a predetermined degree of inconsistency for test data
US10037623B2 (en) * 2013-03-15 2018-07-31 Bwise B.V. Dynamic risk structure creation systems and/or methods of making the same
US10169370B2 (en) * 2013-06-14 2019-01-01 Here Global B.V. Navigation database customization
KR102117511B1 (en) * 2013-07-30 2020-06-02 삼성전자주식회사 Processor and method for controling memory
DE102013225497A1 (en) * 2013-12-10 2015-06-11 Bayerische Motoren Werke Aktiengesellschaft Data communication between a computing device of a vehicle and a service server
EP3170100A4 (en) 2014-07-15 2017-12-06 Microsoft Technology Licensing, LLC Data model change management
WO2016008086A1 (en) 2014-07-15 2016-01-21 Microsoft Technology Licensing, Llc Data model indexing for model queries
WO2016008087A1 (en) 2014-07-15 2016-01-21 Microsoft Technology Licensing, Llc Managing multiple data models over data storage system
CN105518672B (en) 2014-07-15 2019-04-30 微软技术许可有限责任公司 Data retrieval across multiple models
US9811559B2 (en) * 2014-09-01 2017-11-07 Mapquest, Inc. Computerized systems and methods for identifying points-of-interest using customized query prediction
US9686357B1 (en) 2016-08-02 2017-06-20 Palantir Technologies Inc. Mapping content delivery
US9674278B1 (en) * 2016-08-03 2017-06-06 Palantir Technologies Inc. Geographic data management server
US11054971B2 (en) * 2017-05-23 2021-07-06 Salesforce.Com., Inc. Modular runtime environment
WO2020177074A1 (en) * 2019-03-05 2020-09-10 深圳市天软科技开发有限公司 Data extraction method, terminal device and computer readable storage medium
CN112414409B (en) * 2020-11-16 2022-08-02 天津航天中为数据系统科技有限公司 Autonomous inspection path planning method based on string structure and aircraft
USD959552S1 (en) 2021-07-21 2022-08-02 Speedfind, Inc Display sign
DE102022208227A1 (en) 2022-08-08 2024-02-08 Volkswagen Aktiengesellschaft Method for compressed storage of movement data of a vehicle, method for recording compressed movement data for a map of at least one vehicle and corresponding devices

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4086632A (en) * 1976-09-27 1978-04-25 The Boeing Company Area navigation system including a map display unit for establishing and modifying navigation routes
JPS585611A (en) * 1981-07-01 1983-01-13 Toyota Motor Corp Device for guiding running operation
JPS61250671A (en) * 1985-04-27 1986-11-07 株式会社デンソー Map display unit
CA1277043C (en) * 1985-07-25 1990-11-27 Marvin S. White, Jr. Apparatus storing a representation of topological structures and methods of building and searching the representation
NL8602654A (en) * 1986-10-23 1988-05-16 Philips Nv METHOD FOR DIVIDING IN LOTS AND STORING BITCH IN A MASSAGE MEMORY A DATA FILE, AND FOR ADDRESSING A LOT, AND APPARATUS FOR PERFORMING THE METHOD
US4972319A (en) * 1987-09-25 1990-11-20 Delorme David M Electronic global map generating system
US5191532A (en) * 1987-12-05 1993-03-02 Aisin Aw Co., Ltd. Navigation apparatus
EP0346492B1 (en) * 1987-12-28 1995-05-03 Aisin Aw Co., Ltd. Route search method for navigation system
JPH023900A (en) * 1988-06-16 1990-01-09 Nissan Motor Co Ltd Present place displaying device for moving body
US5170353A (en) * 1988-11-17 1992-12-08 U.S. Philips Corporation Bucket-oriented route planning method, and navigation system comprising a route planner for carrying out such a method
US5036471A (en) * 1989-04-18 1991-07-30 Sanyo Electric Co., Ltd. Apparatus for road path searching applicable to car navigation system and operation method thereof
US5150295A (en) * 1990-05-22 1992-09-22 Teledyne Industries, Inc. Computerized system for joining individual maps into a single map product
US5295261A (en) * 1990-07-27 1994-03-15 Pacific Bell Corporation Hybrid database structure linking navigational fields having a hierarchial database structure to informational fields having a relational database structure
US5235701A (en) * 1990-08-28 1993-08-10 Teknekron Communications Systems, Inc. Method of generating and accessing a database independent of its structure and syntax
US5327529A (en) 1990-09-24 1994-07-05 Geoworks Process of designing user's interfaces for application programs
DE69131270T2 (en) * 1990-10-01 1999-12-02 Mannesmann Vdo Ag Methods of storing a topological network and methods and devices to identify a row of 1 cells
JP2570500B2 (en) * 1990-12-19 1997-01-08 三菱電機株式会社 Car navigation system
EP0514972B1 (en) * 1991-05-22 1996-03-27 Koninklijke Philips Electronics N.V. Multinode distributed data processing system for use in a surface vehicle
US5285391A (en) * 1991-08-05 1994-02-08 Motorola, Inc. Multiple layer road memory storage device and route planning system
JP2848061B2 (en) * 1991-11-06 1999-01-20 三菱電機株式会社 Navigation device
EP0559355B1 (en) * 1992-02-18 1997-08-20 Pioneer Electronic Corporation Navigation apparatus with enhanced positional display function
US5412573A (en) * 1993-05-20 1995-05-02 Motorola Inc. Multi-mode route guidance system and method therefor
US5544087A (en) 1993-06-04 1996-08-06 Sumitomo Electric Industries, Ltd. Navigation system
US5517419A (en) * 1993-07-22 1996-05-14 Synectics Corporation Advanced terrain mapping system
DE69331741T2 (en) * 1993-10-04 2002-10-02 Siemens Ag Method and device for quick access to data units of a sorted list and database carrier for this method and / or this device
KR960705190A (en) 1994-08-08 1996-10-09 요트.게.아. 롤페즈 A navigation device for a land vehicle with means for generating a multi-element anticipatory speech message, and a vehicle comprising such device
JPH0886660A (en) * 1994-09-16 1996-04-02 Alpine Electron Inc Car navigation system
US5528518A (en) 1994-10-25 1996-06-18 Laser Technology, Inc. System and method for collecting data used to form a geographic information system database
JP3042341B2 (en) * 1994-11-30 2000-05-15 日本電気株式会社 Local I / O Control Method for Cluster-Coupled Multiprocessor System
US5590331A (en) 1994-12-23 1996-12-31 Sun Microsystems, Inc. Method and apparatus for generating platform-standard object files containing machine-independent code
US5731978A (en) 1995-06-07 1998-03-24 Zexel Corporation Method and apparatus for enhancing vehicle navigation through recognition of geographical region types
JP3386816B2 (en) * 1995-06-16 2003-03-17 マネスマン ファウデーオー アクチェンゲゼルシャフト A system that combines elements into complex junctions and links in a road network representation for vehicles.
US5953722A (en) * 1996-10-25 1999-09-14 Navigation Technologies Corporation Method and system for forming and using geographic data
US5968109A (en) * 1996-10-25 1999-10-19 Navigation Technologies Corporation System and method for use and storage of geographic data on physical media
US6047280A (en) * 1996-10-25 2000-04-04 Navigation Technologies Corporation Interface layer for navigation system

Also Published As

Publication number Publication date
JPH10253367A (en) 1998-09-25
EP0838771A2 (en) 1998-04-29
DE69732755T2 (en) 2006-04-06
US6173277B1 (en) 2001-01-09
EP0838771B1 (en) 2005-03-16
US6047280A (en) 2000-04-04
DE69732755D1 (en) 2005-04-21
US6370539B1 (en) 2002-04-09
EP0838771A3 (en) 1999-12-01
CA2219037A1 (en) 1998-04-25

Similar Documents

Publication Publication Date Title
CA2219037C (en) Interface layer for navigation system
US6073076A (en) Memory management for navigation system
US6601073B1 (en) Deductive database architecture for geographic data
US6362779B1 (en) Method and system for providing navigation systems with updated geographic data
US6600841B1 (en) Method and system for compressing data and a geographic database formed therewith and methods for use thereof in a navigation application program
US6460046B1 (en) Method and system for forming, storing and using sets of data values
EP1473543B1 (en) Method, apparatus and computer program for merging, and using multiple map databases.
US7082443B1 (en) Method and system for updating geographic databases
US5829053A (en) Block storage memory management system and method utilizing independent partition managers and device drivers
JP4079489B2 (en) System and method for using and storing geographic data in physical media
US6961828B2 (en) Cluster system, memory access control method, and recording medium
US5543788A (en) Map management system in geographic information management system
WO2002097726A1 (en) System and method for geocoding diverse address formats
EP2267618A3 (en) Method and system for forming a keyword database for referencing physical locations
JP2748986B2 (en) Buffer management method
JP2001249834A (en) Information storage system, information storing method and machine readable recording medium having program recorded thereon
IES70671B2 (en) Data processing system
JPH0830501A (en) Data base management system
JPH04120144U (en) Storage device

Legal Events

Date Code Title Description
EEER Examination request
MKEX Expiry

Effective date: 20171023