|Publication number||USRE40466 E1|
|Application number||US 11/006,471|
|Publication date||Aug 26, 2008|
|Filing date||Dec 6, 2004|
|Priority date||Sep 22, 2000|
|Also published as||US6703947, USRE41983|
|Publication number||006471, 11006471, US RE40466 E1, US RE40466E1, US-E1-RE40466, USRE40466 E1, USRE40466E1|
|Inventors||Alfred M. Wallner|
|Original Assignee||Tierravision, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (26), Referenced by (7), Classifications (5), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
This invention relates to the field of optimization of spatial databases for functional purposes, and in particular to optimize spatial data to achieve minimal download data size for use with cartographic applications in a networked environment.
2. Discussion of Prior Art
A spatial database comprises topographic information in the form of shapes, lines and points encoded with geodetic coordinates, as well as sets of attributes further describing each form. Internet-based applications use the spatial database to generate bitmap images based on user input such as zip code or address on a server and transmit the map images to client devices. Bitmap-based solutions have numerous limitations, which are well known in the art. While prior art describe systems, which transfer vector data to client devices instead of bitmaps, bitmap solutions remain more efficient in terms of data transfer overhead. The initial download size of vector data is significant, and unless the user interacts repeatedly with the map, the total data amount of vector data is greater than the total data amount of bitmap images. Even if the user interacts frequently with the map and the total download size requirements for bitmap and vector data were about the same, most users prefer to have a number of shorter download wait times rather than one long download wait time. Therefore, except for a few non-mainstream applications, bitmap-based solutions are widely used in networked applications.
In navigation systems, a navigation application and spatial data are packaged and supplied as a complete system on a non-volatile storage medium. Said navigation systems may be installed in vehicles or in standalone devices. These navigation systems rely on significant computing resources such as powerful processors and large permanent storage capacities. Prior art introduces solutions, which use structuring and segmenting of spatial databases to improve data access times and navigational functionality. Said solutions are not applicable when computing resources are severely limited, as encountered on personal digital assistants and smartphones, on which one would want to have access to navigation capabilities and maps. Even when said resources are made available for car navigation systems, more powerful hardware results in higher cost for the system. More importantly still, since spatial data changes quite frequently, standalone car navigation systems will inevitably start producing out-of-date navigation instructions over time. It is therefore necessary to update the local database from time to time. Improved methods for updating said local databases have been introduced by prior art. Nevertheless, the requirement to repeatedly update data used by navigation systems remains a major inconvenience for both consumers as well as navigation system suppliers. Suppliers face substantial costs for creating and distributing the data in regular intervals, and any errors discovered after storing data sets on non-volatile media are costly to fix. To address the above problems, it is desirable to keep frequently changing spatial data on a central server and use wireless transmission networks to deliver navigation functionality to remote devices. Navigational functions such as route calculation and driving directions are performed on the server, making it also easier to integrate real-time road traffic condition data. Driving directions or maneuver instructions are text-based and relatively small in terms of data size, allowing for fairly quick wireless data transmission. On the other hand, the ability to provide graphical, cartographic map display introduces much larger data size overhead. Given the data transfer rates of wireless networks presently and during several years to come, users would experience unacceptably slow performance for map display functionality on remote devices.
The objective of this invention is to introduce a new spatial database system, which reduces the data size, makes it possible to download data in small increments as needed, and which can be used with applications such as navigation systems, for which vector-based functionality is needed.
The primary object of the invention is to provide a compressed spatial database system, which enables incremental and efficient download of spatial vector data over a network. Another object of the invention is to introduce a location-relevant naming system so that software running on network client devices can efficiently compute data segment file names depending on user interaction with a map or device-supplied location data (e.g. GPS). A third object of the invention is to enable combined online and offline operation capability of a digital map display system. Another object of the invention is to provide server-independent map display capability based on GPS location input. A further object of the invention is to introduce a system allowing updating of dynamic location content without having to retransmit redundant map data. Yet another object of the invention is to enable map centering despite using a segmented data system.
Other objects and advantages of the present invention will become apparent from the following descriptions, taken in connection with the accompanying drawings, wherein, by way of illustration and example, an embodiment of the present invention is disclosed.
In a preferred embodiment of the present invention, a method for organizing and compressing spatial data comprises the steps of parsing a spatial database, separating topographic from attribute information, segmenting the data into rectangles, eliminating subsets of the data points, further reducing the data size by converting the data from a real number format to an integer format, generating location-relevant file names for each of the rectangles and storing the files in permanent storage space. In accordance with a preferred embodiment of the present invention, map display client software computes data file names based on user interactions or device-supplied location information (GPS), fetches the computed file names from a remote server, combines data from several data files to produce an in-memory map image and draws the image on the display screen.
The drawings constitute a part of this specification and include exemplary embodiments to the invention, which may be embodied in various forms. It is to be understood that in some instances various aspects of the invention may be shown exaggerated or enlarged to facilitate an understanding of the invention wherein:
Detailed descriptions of the preferred embodiment are provided herein. It is to be understood, however, that the present invention may be embodied in vanous forms. Therefore, specific details disclosed herein are not to be interpreted as limiting, but rather as a basis for the claims and as a representative basis for teaching one skilled in the art to employ the present invention in virtually any appropriately detailed system, structure or manner.
The parsed data from step 11 is segmented into topographic components and attribute components in step 12. Attribute information is highly redundant and is therefore an obvious compression target. Attribute information is consolidated using a simple attribute pointer or index mechanism. The topographic and attribute components are then further segmented based on location in two steps. In the preferred embodiment, the first segmentation evenly divides the area into an 8×8 grid. Each topographic data entity along with its attributes of each selected feature is assigned to one of the 64 segments. If the data entity is a polygon or a line and falls into several segments, the data entity is decomposed into two or more pieces using mathematical line and polygon splitting algorithms, and each piece is assigned to the correct segment. The resulting data segments are referred to as level 1 segments and are stored in non-volatile memory. Another segmentation is performed on the parsed data from step 11, this time dividing the area into a 64×64 grid. The resulting 4096 data segments are referred to as level 0 data segments, which are also stored in non-volatile memory.
In step 13, reduction algorithms are performed on level 1 and level 2 data. In the preferred embodiment, level 1 data covers a geographic area of ⅛° longitude by 1/16° latitude. When a map picture is generated for such an area, it is neither desirable nor practical to show all the details, especially when the map picture is shown on a small screen. For instance, it is desirable to show only the main roads, while suppressing the smaller roads. The reduction algorithm used in the preferred embodiments takes these facts into consideration. Two types of data reductions are performed. First, some topographic features such as secondary roads are completely eliminated. Second, the resolution of the remaining topographic features is reduced. Many road data entities contain a number of data points, as shown in
Integer conversion as referred to in block 15 of
N=upper limit of valid integer values (50000 in the preferred embodiment)
The formulas for computing level 1 offsets and values are:
K=segment divisor (8 in the preferred embodiment for level 1 segments)
The formulas for computing level 0 offsets and values are the same as for level 1, except that K equals 64 in the preferred embodiment.
The example shown in
Level 2 offsets are shown in 31 and 32, while level 1 offsets are shown in 33 and 34. In the preferred embodiment of this invention, the upper limit N is set to 50000, but it could be a different number. The number should not exceed 65536 or 2^16, allowing it to be stored as a 2 byte integer (a short). The number should not be too low, which would result in a loss of spatial accuracy, because several real numbers would map to the same integer. The loss of accuracy is about 1 meter as implemented in the preferred embodiment of this invention.
Once a data segment has been processed and all real numbers converted to integers, a file name is assigned to the data segment as the last step in block 15 of FIG. 1. Since the computed integer values are only distance values from a given base value or offset, they are not reversible to the original real number value without the offset. A simple and efficient way to supply the necessary offset values is to make them part of a file name. As shown in the example of
In order to simplify computing requirements, a new geodetic coordinate system is introduced. The North Pole of the earth is at coordinate (0,0) and the South Pole is at (360,360). Unlike in the standard coordinate system, no negative values are used. Every latitude degree in the standard coordinate system corresponds to 2 latitude degrees in the new system. The conversion from the standard to the new coordinate system is accomplished as follows:
New latitude=90−old latitude*2
New longitude=old longitude when range is 0° to 180°
In the new coordinate system, moving south and east always results in greater coordinates, while moving west and north always results in smaller coordinates, until the respective end points 0 and 360 are reached. This system significantly reduces the number of exception checking operations required by map display software when compared to the standard coordinate system.
This shows that the file name contains the offset information for the spatial data stored in the file. Thus, map display software can perform a few simple calculations to compute a file name from any geodetic coordinate, which may be supplied by GPS output. It should also be evident that the task of computing file names for data segments adjacent to a given segment is very straightforward using said file-naming system.
The following section describes how a map display program can use said file system and offer desirable functionality such as combined online/offline operation. In a typical embodiment, the map display program is installed on a wireless device such as a smartphone or personal digital assistant. As shown in
The map display engine 46 uses said geodetic coordinates received from the input interface 44 to calculate four file names. The input interface 44 also tells the map display engine 46 which data level is needed, e.g. high-resolution level 0 is appropriate when the user specified an address, while level 1 may be more appropriate when the user specified a city or zip code. As has been shown in detail in a previous section, a geodetic coordinate can be decomposed and produce a unique file name. The map display engine 46 could then request said file name from a server 47 on which all files 49 are stored. However, in the preferred embodiment, the map display engine actually computes a total of four file names. If only one file is fetched, the geodetic coordinate of interest to the user could be located somewhere near the edge of said file. It would look awkward to the user and be less informative if the point of interest is not shown at or near the center of the map display screen. The ability to center the map picture has been lost by segmenting the spatial database. The solution employed by the map display engine 46 is to fetch three additional data segment files, which are most adjacent to said geodetic coordinate. The map display engine simply determines into which area, top-left, top-right, bottom-left or bottom-right, said coordinate falls. If a point falls in the top-left quadrant of a file, as does point 54 in
One objective of the invention is to provide a flexible mapping system in the sense that the map display system can function online as well as offline. Offline functionality is desirable because it offers the highest speed, since the data is accessed from local storage. The map display engine 46 gives users several options to enable offline capability. Users can select a city or zip code and download all data files for said city or zip code. Furthermore, users can reserve a certain amount of local disk space to be allocated for map data caching. When caching is enabled, the map display engine 46 automatically stores downloaded files on the local disk. As the cache fills up, new data files replace the least frequently accessed data files. A different caching algorithm, for instance based on last accessed time stamps, could be used as well. When the user has selected caching or pre-loading of data, the map display engine 46 always first scans the local disk space and, if available, loads data files from local space into memory instead of downloading said files from a remote server. Local caching is very useful when users frequently request the same maps. For instance, a user may want to check road traffic conditions on a daily basis. In this case, only updated traffic information such as traffic incident locations or traffic speed maps (a list of measured traffic speeds at different locations) needs to be downloaded. Said updated traffic information can be displayed on a map, which is generated from the map display engine 46 using local map data. Said offline/online capability offers optimal performance for frequently used maps as well as great flexibility regarding local storage capacities of different devices.
While the invention has been described in connection with a preferred embodiment, it is not intended to limit the scope of the invention to the particular form set forth, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4630209 *||Jun 14, 1982||Dec 16, 1986||Toyota Jidosha Kogyo Kabushiki Kaisha||Audio/visual display system for multiple maps|
|US4888698 *||Oct 19, 1987||Dec 19, 1989||U.S. Philips Corporation||Method for storing a parcelwise divided digital data base as well as of addressing a data parcel in a mass memory, and apparatus for carrying out the method|
|US5202829 *||Jun 10, 1991||Apr 13, 1993||Trimble Navigation Limited||Exploration system and method for high-accuracy and high-confidence level relative position and velocity determinations|
|US5754846 *||Oct 1, 1991||May 19, 1998||U.S. Philips Corporation||Method of storing a topological network, and methods and apparatus for identifying series of 1-cells in a network stored by such a method|
|US5802492||Jun 11, 1996||Sep 1, 1998||Delorme Publishing Company, Inc.||Computer aided routing and positioning system|
|US5848373 *||Jul 18, 1997||Dec 8, 1998||Delorme Publishing Company||Computer aided map location system|
|US5881074||Aug 28, 1997||Mar 9, 1999||Level One Communications, Inc.||1000base-t packetized trellis coder|
|US5953722 *||Sep 5, 1997||Sep 14, 1999||Navigation Technologies Corporation||Method and system for forming and using geographic data|
|US5966135 *||Oct 30, 1996||Oct 12, 1999||Autodesk, Inc.||Vector-based geographic data|
|US5968109 *||Oct 25, 1996||Oct 19, 1999||Navigation Technologies Corporation||System and method for use and storage of geographic data on physical media|
|US5974419 *||Sep 5, 1997||Oct 26, 1999||Navigation Technologies Corporation||Parcelization of geographic data for storage and use in a navigation application|
|US6018695 *||Jun 11, 1999||Jan 25, 2000||Navigation Technologies Corporation||System and method for distributing information for storage media|
|US6038559 *||Mar 16, 1998||Mar 14, 2000||Navigation Technologies Corporation||Segment aggregation in a geographic database and methods for use thereof in a navigation application|
|US6178380||Oct 22, 1998||Jan 23, 2001||Magellan, Dis, Inc.||Street identification for a map zoom of a navigation system|
|US6222483 *||Sep 29, 1998||Apr 24, 2001||Nokia Mobile Phones Limited||GPS location for mobile phones using the internet|
|US6704645||Dec 11, 2001||Mar 9, 2004||Garmin Ltd.||System and method for estimating impedance time through a road network|
|US6708112||Apr 25, 2003||Mar 16, 2004||Garmin Ltd||System and method for calculating a navigation route based on adjacent cartographic map databases|
|US6795450||Sep 28, 2000||Sep 21, 2004||Tdk Semiconductor Corporation||Method and apparatus for supporting physical layer link-suspend operation between network nodes|
|US6868088||Apr 26, 2001||Mar 15, 2005||3Com Corporation||Automatic detector of media interface protocol type|
|US6912596||Aug 2, 2002||Jun 28, 2005||Texas Instruments Incorporated||Automatic resume from suspend for IEEE-1394 PHY|
|US7047428||Jun 14, 2002||May 16, 2006||Broadcom Corporation||Method and apparatus for performing wake on LAN power management|
|US7054947||Sep 4, 2001||May 30, 2006||Samsung Electronics Co., Ltd.||Auto-negotiation method for high speed link in gigabit Ethernet using 1000 Base-T standard and apparatus thereof|
|US7079551||Sep 7, 2001||Jul 18, 2006||Kiribati Wireless Ventures, Llc||Private network link verification procedure in free space optical communication network|
|US20050004945||May 3, 2004||Jan 6, 2005||Cossins Robert N.||Geographic management system|
|US20050125143||Dec 8, 2004||Jun 9, 2005||Garmin Ltd., A Cayman Islands Corporation||System and method for estimating impedance time through a road network|
|US20050135413||Dec 7, 2004||Jun 23, 2005||Kewei Yang||Signaling and coding methods and apparatus for long-range 10 and 100 MBPS Ethernet transmission|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7734412 *||Nov 2, 2006||Jun 8, 2010||Yahoo! Inc.||Method of client side map rendering with tiled vector data|
|US8504393 *||Sep 7, 2011||Aug 6, 2013||State Farm Mutual Automobile Insurance Company||Systems and methods for grid-based insurance rating|
|US8676613 *||Mar 27, 2013||Mar 18, 2014||State Farm Mutual Automobile Insurance Company||Methods for grid-based insurance rating|
|US8738407 *||Mar 27, 2013||May 27, 2014||State Farm Mutual Automobile Insurance Company||Computer readable medium containing a set of computer readable instructions for grid-based insurance rating|
|US8738408 *||Mar 27, 2013||May 27, 2014||State Farm Mutual Automobile Insurance Company||Methods for grid-based rating insurance products using a programmed computer system|
|US20080109159 *||Nov 2, 2006||May 8, 2008||Yahoo! Inc.||Method of client side map rendering with tiled vector data|
|US20120066005 *||Sep 7, 2011||Mar 15, 2012||State Farm Mutual Automobile Insurance Company||Systems and methods for grid-based insurance rating|
|International Classification||H03M7/00, H03M7/30|
|Oct 25, 2013||AS||Assignment|
Owner name: TIERRAVISION, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WALLNER, ALFRED;REEL/FRAME:031483/0138
Effective date: 20030619