The present disclosure relates to a data format to represent location coordinates for a motor vehicle. More specifically, the present disclosure relates to a compact map based on parent-child relations for a motor vehicle.
In many motor vehicles, the motor vehicle is equipped with a navigation system, or an occupant of the motor vehicle has a portable navigation application on a mobile device to determine the location of the motor vehicle on a map. The database for the map, especially a high definition map, typically includes a multitude of location coordinates, such as latitude and longitude.
The databases for these maps, however, require a tremendous amount of memory. Thus, while current databases for maps achieve their intended purpose, there is a need for a new and improved system and process to generate and store location coordinates to reduce the map data size.
According to several aspects, a method to produce data of a series of location coordinates of a motor vehicle includes one or more of the following: receiving a location point on a map of the motor vehicle, each location being treated as a child with a specific character; grouping multiple children who reside in a common area, the grouping sharing a same parent; and identifying the parent as a common zone factor, wherein the common zone factor is a constant value common to all location points of a particular zone.
In an additional aspect of the present disclosure, the location point has latitude and longitude coordinates.
In another aspect of the present disclosure, identifying the common zone factor compresses the data.
In another aspect of the present disclosure, the compression of the data reduces storage requirements of the data.
In another aspect of the present disclosure, the reduction of the storage requirement is about 60% less than the storage requirement without the compression of the data.
In another aspect of the present disclosure, a first set of digits of multiple digits of the coordinates determines an outer zone.
In another aspect of the present disclosure, a second set of digits of the multiple digits determines an inner zone.
In another aspect of the present disclosure, a remaining set of digits of the multiple digits is converted to Cartesian coordinates of the location points.
According to several aspects, a system to produce data of a series of location coordinates of a motor vehicle includes a controller that receives a location point on a map of the motor vehicle, each location being treated as a child with a specific character, the controller implemented with an algorithm that groups multiple children who reside in a common area, the grouping sharing a same parent, and identifies the parent as a common zone factor, wherein the common zone factor is a constant value common to all location points of a particular zone.
In another aspect of the present disclosure, the location point is obtained from over the air database.
In another aspect of the present disclosure, the location point has latitude and longitude coordinates.
In another aspect of the present disclosure, identifying the common zone factor compresses the data.
In another aspect of the present disclosure, a first set of digits of multiple digits of the coordinates determines an outer zone.
In another aspect of the present disclosure, a second set of digits of the multiple digits determines an inner zone.
In another aspect of the present disclosure, a remaining set of digits multiple digits is converted to Cartesian coordinates.
According to several aspects, a method to produce data of a series of location coordinates of a motor vehicle includes one or more of the following: receiving a location point on a map of the motor vehicle, each location having a latitude and a longitude coordinate, each location being treated as a child with a specific character; grouping multiple children who reside in a common area, the grouping sharing a same parent; identifying the parent as a common zone factor, wherein the common zone factor is a constant value common to all location points of a particular zone; and calculating multiple digits from the location points in the common zone, a first set of digits of the multiple digits determining an outer zone; a second set of digits of the multiple digits determining an inner zone, and a remaining set of digits of the multiple digits is converted to Cartesian coordinates of the location points.
In another aspect of the present disclosure, identifying the common zone factor compresses the data to reduce storage requirements of the data by about 60% as compared to the storage requirement without the compression of the data.
In another aspect of the present disclosure, the parent-child format is compresses the location data without jeopardizing the accuracy of the original location points.
In another aspect of the present disclosure, the flexibility of choosing a range for the common zone and the number of outer and inner zones provide different applications with arbitrary accuracies and storage requirements.
Further areas of applicability will become apparent from the description provided herein. It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.
The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses.
Referring to
The block 20, in some arrangements, is implemented in the controller 52 of a motor vehicle 50, as shown in
Accordingly, location points conversion and compression occur on either a cloud-based backend server or a single computer processor instead of inside any controller in the vehicle. As such, the map database is pre-processed, including compressing and extracting common features, significantly before sending this database to the motor vehicle. Hence, the process 10 reduces the storage requirements for an in-vehicle electronic module and eliminates the conversion process from an in-vehicle electronic module since it can be accomplished during the map database pre-processing state.
The controller 52 which is a non-generalized, electronic control device having a preprogrammed digital computer or processor, memory or non-transitory computer readable medium used to store data such as control logic, software applications, instructions, computer code, data, lookup tables, etc., and a transceiver (or input/output ports). Computer readable medium includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device. Computer code includes any type of program code, including source code, object code, and executable code. The processor 10 is configured to execute the code or instructions. Where the controller 52 is an infotainment control module that communicates with an interface 54 that enables an occupant of the motor vehicle to interact with infotainment control module.
The controller 52 further includes one or more applications, such as, a software program configured to perform a specific function or set of functions. The applications may include one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The applications may be stored within the memory or in additional or separate memory.
In various arrangements, the block 20 receives latitude and longitude coordinates (flat1,flon1) . . . (flatn,flonn) from the master database 18 or the OTA database 14. All the location points in the OTA database 14 are treated as children with different characteristics. More specifically, each child dataset is associated with a common zone factor (CZF), where the CZF is a constant value (factor) common to all points in a particular zone. The block 20 then applies the CZF to the latitude and longitude coordinates (flat1,flon1) . . . (flatn,flonn) and generates compact parent-child format coordinates from the relation (Latn,Lonn)=CZF*(flat1,flon1).
The typical size of CZF is 2 Bytes, and the memory reduction is by a factor 2*2*n, where n is the number of points in the zone. Results from the process 10 provides a reduction in memory requirements by more than about 60% without compromising the accuracy of the map data. Note that the higher the density of the points, the higher the reduction in memory requirements.
Hence, the process 10 provides a unique data format to represent a series of location coordinates such as the latitude and longitude in a high definition map, while reducing the storage requirements at the same time, based on a parent-child relationship. Each location point that the map uses to represent, for example, a road edge or a road sign location is treated as a child with its specific character. And a group of children who resides in a common area will share the same parent referred to as the common zone factor (CZF).
If this format is utilized to store the map into a database, the data is stored as a parent and its children instead of non-related latitude and longitude coordinates. This database with the parent-child relationship enables an efficient searching mechanism because the data relationship has been pre-processed when creating the in-vehicle map database. When the vehicle gets the current location while driving, the same mechanism is utilized to find the parent also known as the common zone factor of the current location and grab all the children who are under the same parent from the database. Since the parent-child relationship can also be expressed as a grandparent, parent and child or great-grand-parent, this format provides an arbitrary level of relationship so that can be flexibly implemented based on the accuracy, data complexity and required common zone size, which can also be utilized for map comparisons.
Turning now to
Accordingly, the process 10 selects a parent, which in this case is in a zone 30, that provides a CZF valve. All the points that belong to this common zone are extracted. A conversion calculation is performed to get a list of (x, y) local Cartesian coordinates (
More specifically, to ensure that relational location data meets the high definition map and localization requirements, common zones can be defined as outer and inner zones. Each zone is represented by three digits of the GeoHash value of a location point. (A zone can be defined with different number of digits of the GeoHash for arbitrary accuracy.)
As an example, a 11-digits GeoHash value is calculated from latitude and longitude locations points. The first three digits identify an outer zone, for example, 156 km by 156 km. The second three digits identify an inner zone, for example, 1.22 km by 0.61 km. And the remaining five digits are utilized to convert to Cartesian coordinates.
In this example, the local Cartesian coordinates of the inner zone includes a multitude of 4096 by 4096 grids (
Accordingly, the example described above shows that random location data points of a road can be compressed for in-vehicle data (
Shown below are the formulas that are employed to perform the conversion from GeoHash to Cartesian in parent-child format:
Shown below are the formulas that are employed to perform the conversion from Cartesian in parent-child format to GeoHash
Shown in
In summary, the algorithm in the process 10 provides a high quality map data set while employing less storage. The process 10 enables sending large high definition map data sets in real time by splitting the data into smaller common zone areas without compromising the precision of the data. Accordingly, the process 10 provides a low cost solution for high definition map storage in real time.
The description of the present disclosure is merely exemplary in nature and variations that do not depart from the gist of the present disclosure are intended to be within the scope of the present disclosure. Such variations are not to be regarded as a departure from the spirit and scope of the present disclosure.