An offline map data processing method and system

Abstract

The present application relates to a kind of offline map data processing method and system, belong to data processing technical field, including obtaining original geographic data file and converting standard map file, by determining minimum compressed data unit, standard map file is split, the unit data corresponding to each minimum compressed data unit is extracted, records its first byte length, each unit data is compressed respectively, compressed data is obtained, and records its second byte length, two byte lengths are compared, target storage data is selected, and after adding flag bit, write in newly created map file, reconstruct offset index in newly created map file, corresponding target storage data and flag bit are extracted based on offset index, and load to continuous memory, target storage data is decompressed based on flag bit, and decompression data is obtained to map rendering, efficient storage and on-demand loading of offline map data on code table and other resource limited equipment are realized.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to an offline map data processing method and system. Background Technology

[0002] With the increasing popularity of embedded devices such as cycling computers and fitness trackers, users' demand for offline map navigation functions is growing. However, these devices are at a relatively low level in terms of storage memory, RAM, and chip computing power. Achieving efficient map data storage and loading under limited hardware resources has become an urgent technical problem to be solved.

[0003] Currently, existing methods typically involve compressing the standard map format file as a whole, storing the entire map file as a single compressed package, and then obtaining the map data by decompressing the entire file. Alternatively, lossy compression of the map data can be used to reduce the amount of data. When reading map data, the entire map file or large data segments need to be loaded into memory for processing.

[0004] In the aforementioned existing technologies, the overall compression method requires loading the entire map file into memory and completing full decompression at once, which places extremely high demands on device memory and computing power, making it difficult to implement on resource-constrained embedded devices. Although lossy compression methods can further reduce the amount of data, they reduce the accuracy of map data, resulting in visual defects such as cracks during rendering, which cannot meet the requirements for navigation accuracy. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide an offline map data processing method and system to solve the technical problems in the prior art, such as the excessive memory and computing power requirements of embedded devices during decompression due to the compression of the entire map file at once, which prevents map loading, and the lossy compression leading to reduced map accuracy and inability to meet navigation requirements.

[0006] This invention provides an offline map data processing method, comprising: Data acquisition steps: Obtain the raw geographic data file and convert the raw geographic data file into a standard map file; Data splitting steps: Determine the smallest compressed data unit, split the standard map file based on the smallest compressed data unit, and extract the unit data corresponding to each smallest compressed data unit; Data compression steps: Compress each of the unit data separately to obtain compressed data, and record the length of the first byte of each of the unit data and the length of the second byte of the compressed data; Data reconstruction steps: Compare the length of the first byte with the length of the second byte to obtain a comparison result. Based on the comparison result, select target storage data from the unit data and the compressed data, add a flag bit to the target storage data, write each target storage data and the corresponding flag bit into a new map file, and reconstruct the offset index in the new map file. Data loading steps: Obtain latitude and longitude information; extract corresponding target storage data and flag bits from the newly created map file based on the latitude and longitude information and the offset index; load the extracted target storage data into contiguous memory; decompress the target storage data in the contiguous memory based on the flag bits to obtain decompressed data; and perform map rendering based on the decompressed data.

[0007] By splitting standard map files into the smallest compressed data units and compressing them separately, and selecting the smaller data as the target storage data based on the comparison of byte length before and after compression, the overall size of the map file is minimized while maintaining data integrity. Meanwhile, by adding flag bits and establishing offset indexes to the target stored data during reconstruction, and extracting corresponding unit data on demand for decompression and rendering based on latitude and longitude information during loading, the code table does not need to load or decompress the entire map file at once. This significantly reduces the device's storage memory and running memory usage while improving the loading speed and rendering smoothness of map data, enabling resource-constrained embedded devices such as code tables to use offline maps efficiently.

[0008] In some embodiments of the present invention, the data reconstruction step specifically includes: If the length of the second byte is less than the length of the first byte, then the comparison result indicates that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result. If the length of the second byte is greater than or equal to the length of the first byte, the comparison result indicates that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

[0009] By comparing the compressed byte length with the uncompressed byte length, the smaller data is selected as the target storage data based on the comparison result. This avoids the situation where compressing data blocks with poor compression results would actually increase the data volume, ensuring that each data unit is stored with the minimum size, thereby further optimizing the overall compression efficiency of map files.

[0010] In some embodiments of the present invention, the data reconstruction step further includes: Based on the comparison results, a data type for each of the target stored data is generated, and a flag bit is generated based on the data type and the byte length of the target stored data. Each of the aforementioned flag bits is added to the corresponding target storage data, and the target storage data after adding the flag bits is written sequentially into the new map file; Based on the writing order and byte length of each target stored data, a file offset address for each target stored data is generated in the newly created map file, and the offset index is constructed based on each of the file offset addresses.

[0011] By adding flag bits containing data type and byte length information to the target stored data, each unit of data carries identifiable attribute information, which facilitates quick identification of data type and corresponding decompression processing during subsequent loading. At the same time, a file offset address is generated based on the writing order and byte length, and an offset index is constructed, providing a precise record of the position of each unit of data in the file, thereby improving the efficiency of data location.

[0012] In some embodiments of the present invention, the data loading step specifically includes: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and the map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file.

[0013] By obtaining the latitude and longitude information of the current display area and calculating the map tile row and column numbers required to cover the current display area based on the map zoom level, and then using the row and column numbers to find the offset index to obtain the file offset address, the code table only needs to extract the target storage data within the current field of view for decompression and rendering, without loading map data from irrelevant areas. This reduces the amount of data loading and IO operation time, and improves the map's response speed.

[0014] In some embodiments of the present invention, the calculation model for the map tile row and column numbers is specifically as follows:

[0015] in, The x-coordinate of the map tile's row and column number; The current longitude in the latitude and longitude information; Adjust the map scaling levels.

[0016] By mathematically mapping longitude to the horizontal coordinates of map tiles, any longitude position can be accurately converted into the corresponding horizontal coordinates of tiles, thereby accurately locking the range of tiles covered by the current field of view in the horizontal direction. This provides a computational basis for accurately locating and extracting the corresponding target storage data from the offset index.

[0017] In some embodiments of the present invention, the calculation model for the map tile row and column numbers further includes:

[0018] in, The vertical coordinate of the map tile row and column number; The latitude is the current latitude in the latitude and longitude information.

[0019] By mathematically mapping latitude to the vertical coordinates of map tiles, any latitude position can be accurately converted into the corresponding vertical coordinates of tiles. This allows for precise identification of the tile range covered by the current field of view in the vertical direction. Combined with the horizontal coordinates, the set of tiles required to be loaded for the current display area is determined, ensuring that only data within the field of view is extracted, thus avoiding memory waste caused by loading irrelevant data.

[0020] Some embodiments of the present invention further provide an offline map data processing system, comprising: The data acquisition module acquires the raw geographic data file and converts the raw geographic data file into a standard map file. The data splitting module determines the smallest compressed data unit, splits the standard map file based on the smallest compressed data unit, and extracts the unit data corresponding to each smallest compressed data unit. The data compression module compresses each of the unit data separately to obtain compressed data, and records the length of the first byte of each of the unit data and the length of the second byte of the compressed data. The data reconstruction module compares the length of the first byte with the length of the second byte to obtain a comparison result. Based on the comparison result, it selects target storage data from the unit data and the compressed data, adds a flag bit to the target storage data, writes each target storage data and the corresponding flag bit into a new map file, and reconstructs the offset index in the new map file. The data loading module acquires latitude and longitude information, extracts corresponding target storage data and flag bits from the newly created map file based on the latitude and longitude information and the offset index, loads the extracted target storage data into contiguous memory, decompresses the target storage data in the contiguous memory based on the flag bits to obtain decompressed data, and performs map rendering based on the decompressed data.

[0021] In some embodiments of the present invention, the data reconstruction module is specifically used for: If the length of the second byte is less than the length of the first byte, then the comparison result indicates that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result. If the length of the second byte is greater than or equal to the length of the first byte, the comparison result indicates that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

[0022] In some embodiments of the present invention, the data reconstruction module is further configured to: Based on the comparison results, a data type for each of the target stored data is generated, and a flag bit is generated based on the data type and the byte length of the target stored data. Each of the aforementioned flag bits is added to the corresponding target storage data, and the target storage data after adding the flag bits is written sequentially into the new map file; Based on the writing order and byte length of each target stored data, a file offset address for each target stored data is generated in the newly created map file, and the offset index is constructed based on each of the file offset addresses.

[0023] In some embodiments of the present invention, the data loading module is specifically used for: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and the map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart of an offline map data processing method provided in an embodiment of the present invention; Figure 2 A flowchart of a data reconstruction step provided in an embodiment of the present invention; Figure 3 A flowchart of a data loading step provided in an embodiment of the present invention; Figure 4 This is a structural diagram of an offline map data processing system provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0027] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations according to this application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. Furthermore, it should be understood that the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0028] Unlike large computer platforms, current mainstream cycling computers, fitness trackers, and other similar devices are at a relatively low level in terms of storage memory, RAM, and chip computing power. When running offline map functionality on such devices, efficient data storage and retrieval are required based on a compact map data format; However, although existing standard map formats have been optimized for embedded scenarios, their file size is still large. Storing them directly in the codebook device will occupy a lot of storage space. At the same time, due to the limited IO speed and running memory of the device, the loading and rendering efficiency of map data is low, which affects the user experience. In the existing technology, the compression method of offline map data usually adopts the strategy of compressing the entire map file at once. The map file is compressed into a single compressed package for storage using a high compression ratio algorithm, and the entire compressed package is fully decompressed to restore the map data when used. In addition, some solutions further reduce the amount of data through lossy compression technology, or improve the expressiveness of the map by optimizing map rendering details and functions; However, the above-mentioned existing technical solutions have the following shortcomings: First, the strategy of one-time overall compression means that the entire map file must be loaded into memory and fully decompressed at once during decompression, which places extremely high demands on the device's memory capacity and processor performance. In embedded devices with limited resources such as code tables, the decompression operation is often impossible to complete. Even if it can be completed, the decompression speed is extremely slow and cannot meet the needs of real-time map display. Secondly, although lossy compression can further reduce the amount of data, it will reduce the accuracy of map data, resulting in visual defects such as cracks and misalignments in the rendered map, and the error distribution is inconsistent, making it difficult to meet the map accuracy requirements of navigation scenarios. Furthermore, existing solutions often focus on enriching the details of the map and expanding its functions, while neglecting the matching relationship between the amount of map data and the limited performance of embedded devices, and lacking a comprehensive consideration of both.

[0029] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0030] The technical solution of the present invention will be described in detail below with reference to specific embodiments and accompanying drawings.

[0031] like Figure 1 As shown, the present invention provides an offline map data processing method, including: Data acquisition step S1: Obtain the raw geographic data file and convert it into a standard map file; Furthermore, combined Figure 2 As shown, the raw geographic data file is obtained from an open-source geographic data platform. The raw geographic data file is an OpenStreetMap .osm.pbf format file. OpenStreetMap is a world geographic database that can obtain geographic data information files in .osm.pbf format. This format file contains complete vector geographic information such as roads, points of interest, and building boundaries, which is used for subsequent map data production. Subsequently, the acquired raw geographic data files are converted to a new format. Specifically, the Osmosis tool is used to call the Mapsforge map processing library to convert the raw geographic data files in .osm.pbf format into standard map files in Mapsforge binary map format. Mapsforge binary map format is a compact, high-performance storage format specifically designed for offline vector map rendering. Through a carefully designed binary layout and efficient encoding method, it achieves the goals of small size, fast parsing, and strong random access capability, making it especially suitable for running on mobile devices with limited memory and storage resources. Its map file format is as follows: #meta data file header #sub-files for each sub-file #tile index segment tile index header tile index entries #tile data segment for each tile tile header for each POI POI data for each way way propertirs way data; Standard map files are used to provide the basic data support for subsequent data splitting and compression.

[0032] Data splitting step S2: Determine the smallest compressed data unit, split the standard map file based on the smallest compressed data unit, and extract the cell data corresponding to each smallest compressed data unit; Furthermore, it is necessary to determine the granularity of the smallest compressed data unit, which directly affects the balance between subsequent compression efficiency and loading performance. Specifically, taking into account the total amount of offline map data and the hardware parameters of the target code table device, such as storage capacity, running memory size and processor performance, the minimum compressed data unit is determined. This minimum compressed data unit has the characteristic of being independently split and read, that is, each unit of data is independent of each other and can be extracted and processed separately without relying on other unit data. In practical applications, the smallest compressed data unit can be each map tile, all road information in each map tile, or all point of interest information in each map tile. For ease of understanding and description, this embodiment uses map tiles as the smallest compressed data unit for illustration; After determining the smallest compressed data unit, the standard map file is split according to this division granularity. The tile data segments in the standard map file are traversed, and the unit data corresponding to each smallest compressed data unit is extracted in turn to obtain several independent unit data for use in subsequent compression steps. By appropriately selecting the granularity of the smallest compressed data unit, it is possible to adapt to the hardware performance of the target device and achieve a balance between saving storage space and decompression speed. Meanwhile, the finer-grained division of unit data means that the codebook only needs to extract a small amount of unit data covered by the current field of view when loading the map, which effectively reduces the amount of data loaded at one time and reduces the operating load of the codebook device.

[0033] Data compression step S3: Compress each unit of data separately to obtain compressed data, and record the length of the first byte of each unit of data and the length of the second byte of the compressed data; Furthermore, the binary content of each unit of data is read sequentially, and the compression algorithm is called to compress each unit of data to generate compressed data corresponding to each unit of data; During this process, it is necessary to record the length of the first byte of each unit data before compression and the length of the second byte of each compressed data after compression, so that subsequent steps can determine the optimal storage method based on the relationship between the two. The compression method can be flexibly selected according to the actual performance requirements of the target device; For devices such as road meters that have high requirements for real-time map display, the core performance bottleneck is usually the decompression speed rather than the compression ratio. Therefore, a lightweight compression algorithm with a relatively low compression ratio but extremely fast decompression speed can be selected to ensure that the map data can be quickly decompressed and rendered during loading to meet real-time requirements. For scenarios with extremely limited storage space and relatively low requirements for real-time decompression, algorithms with high compression ratios such as Gzip can be selected to minimize the storage space occupied by map files. In addition, the selected compression algorithm is preferably a lossless compression algorithm to ensure that the decompressed unit data is completely consistent with the unit data before compression, thereby ensuring the accuracy and integrity of map rendering and avoiding visual defects such as cracks in the rendered image due to loss of data accuracy. The compression operations described above can effectively reduce the amount of data in each unit, thereby reducing the storage space occupied by the entire map file. At the same time, by selecting a reasonable compression algorithm, a balance can be achieved between saving storage space and decompression speed.

[0034] Data reconstruction step S4: Compare the length of the first byte with the length of the second byte to obtain the comparison result. Based on the comparison result, select the target storage data from the unit data and compressed data, add a flag bit to the target storage data, write each target storage data and the corresponding flag bit into the new map file, and rebuild the offset index in the new map file. In some embodiments, the data reconstruction step S4 specifically includes: If the length of the second byte is less than the length of the first byte, the comparison result is that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result; If the length of the second byte is greater than or equal to the length of the first byte, the comparison result is that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

[0035] By comparing the compressed byte length with the uncompressed byte length, the smaller data is selected as the target storage data based on the comparison result. This avoids the situation where compressing data blocks with poor compression results would actually increase the data volume, ensuring that each data unit is stored with the minimum size, thereby further optimizing the overall compression efficiency of map files.

[0036] Furthermore, after compressing each unit of data and recording the byte lengths of each unit of data before and after compression, the offline map file needs to be reconstructed. Iterate through each data unit and compare the length of the first byte with the length of the second byte corresponding to each data unit. If the length of the second byte is less than the length of the first byte, it indicates that the compressed data is smaller, and the compressed data is selected as the target storage data for this unit of data. If the length of the second byte is greater than or equal to the length of the first byte, it indicates that the compression has failed to effectively reduce the data size or has even increased it. In this case, the original unit data is selected as the target storage data for that unit data. This comparison and selection process ensures that each data unit is ultimately stored in a smaller format.

[0037] In some embodiments, the data reconstruction step S4 further includes: The data type of each target storage data is generated based on the comparison results, and a flag bit is generated based on the data type and the byte length of the target storage data. Each flag is added to the corresponding target storage data, and the target storage data after adding the flags is written to the new map file in sequence. Based on the writing order and byte length of each target storage data, the file offset address of each target storage data in the newly created map file is generated, and an offset index is constructed based on each file offset address.

[0038] By adding flag bits containing data type and byte length information to the target stored data, each unit of data carries identifiable attribute information, which facilitates quick identification of data type and corresponding decompression processing during subsequent loading. At the same time, a file offset address is generated based on the writing order and byte length, and an offset index is constructed, providing a precise record of the position of each unit of data in the file, thereby improving the efficiency of data location.

[0039] Furthermore, a flag bit is added to each target stored data. This flag bit is used to identify the data type and byte length of the corresponding target stored data. Specifically, the data type is used to indicate whether the target stored data is compressed data or uncompressed raw unit data, so that it can be determined whether a decompression operation needs to be performed during subsequent loading. The byte length is used to indicate the actual amount of data stored in the target so that the data content of the appropriate length can be read accurately when loading.

[0040] After selecting the target storage data and adding the flags, it is also necessary to rebuild the index structure of the map file; Because the data stored in each target is compressed, its byte length has changed compared to the original unit data. This change causes the starting storage position of subsequent tile data in the file to be offset. To ensure that the corresponding data can be quickly located based on the tile coordinates during subsequent loading, the original offset index must be updated and rebuilt.

[0041] Specifically, referring to the Mapsforge map format specification, the header of a standard map file contains the starting position of each zoom level sub-file, and the index segment of each sub-file sequentially stores the starting position of each tile in that layer, i.e., the file offset address. In the original map file, these file offset addresses are calculated based on the length and order of the original cell data; When compressed data with a changed length is written back to a new map file, the file offset addresses of all subsequent tiles will be affected. If the compressed data is shorter, the starting position of subsequent tiles needs to be moved forward; if the data is longer, the starting position of subsequent tiles needs to be moved backward. To solve this problem, the data blocks corresponding to each map tile are processed sequentially from front to back, according to the writing order of the target storage data in the newly created map file. Whenever target stored data is written to a new map file, an offset increment is calculated based on the difference between the actual byte length of the target stored data and the first byte length of the corresponding original cell data. This offset increment reflects the impact of the current tile data being written on the starting position of subsequent tiles. Subsequently, this offset increment is added to the file offset address of all subsequent tiles, that is, the offset of each subsequent tile that has not yet been written is updated; Similarly, after each tile is processed, its offset increment is recorded and accumulated, and the file offset address of all subsequent tiles is updated synchronously until all tiles have been processed. By processing each tile individually, accumulating offset increments, and synchronously updating subsequent offset addresses, the correct offset index is finally reconstructed at the header of the newly created map file. This offset index records the latest file offset address corresponding to each tile, ensuring that when the subsequent code table loads map data, it can accurately obtain the corresponding file offset address from the offset index based on the tile coordinates, thereby locating and extracting the target stored data.

[0042] Data loading step S5: Obtain latitude and longitude information, extract the corresponding target storage data and marker bits from the newly created map file based on the latitude and longitude information and offset index, load the extracted target storage data into contiguous memory, decompress the target storage data in contiguous memory based on the marker bits to obtain decompressed data, and perform map rendering based on the decompressed data.

[0043] In some embodiments, the data loading step S5 specifically includes: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file.

[0044] By obtaining the latitude and longitude information of the current display area and calculating the map tile row and column numbers required to cover the current display area based on the map zoom level, and then using the row and column numbers to find the offset index to obtain the file offset address, the code table only needs to extract the target storage data within the current field of view for decompression and rendering, without loading map data from irrelevant areas. This reduces the amount of data loading and IO operation time, and improves the map's response speed.

[0045] In some embodiments, the calculation model for map tile row and column numbers is specifically as follows:

[0046] in, The x-coordinate of the map tile's row and column number; The current longitude in the latitude and longitude information; Adjust the map scaling levels.

[0047] By mathematically mapping longitude to the horizontal coordinates of map tiles, any longitude position can be accurately converted into the corresponding horizontal coordinates of tiles, thereby accurately locking the range of tiles covered by the current field of view in the horizontal direction. This provides a computational basis for accurately locating and extracting the corresponding target storage data from the offset index.

[0048] In some embodiments, the calculation model for map tile row and column numbers further includes:

[0049] in, The vertical coordinate of the map tile row and column number; This refers to the current latitude in the latitude and longitude information.

[0050] By mathematically mapping latitude to the vertical coordinates of map tiles, any latitude position can be accurately converted into the corresponding vertical coordinates of tiles. This allows for precise identification of the tile range covered by the current field of view in the vertical direction. Combined with the horizontal coordinates, the set of tiles required to be loaded for the current display area is determined, ensuring that only data within the field of view is extracted, thus avoiding memory waste caused by loading irrelevant data.

[0051] Furthermore, such as Figure 3 As shown, when loading map data at the code table, the range of data to be loaded must first be determined based on the current display status of the device. Specifically, the latitude and longitude information of the target device's current display area and the current map zoom level are obtained. The latitude and longitude information limits the geographical area covered by the screen, and the map zoom level determines the level of detail of the map. in, and These are the longitude and latitude of a corner point in the current display area, such as the top left corner, or the northwest corner. Adjust the map zoom levels; The expression is:

[0052] The expression is:

[0053] Based on the two parameters mentioned above, the row and column numbers of the map tiles required to cover the current display area are calculated using the Mercator projection formula. The (x, y, z) calculated using the Mercator projection formula can uniquely identify a map tile. Since the current display area usually covers multiple tiles, it is necessary to calculate the four corner points of the display area separately to determine the row and column numbers of all tiles required to cover the entire display area.

[0054] After determining the row and column numbers of the map tiles to be loaded, the offset index can be found based on these row and column numbers. This offset index is pre-built during the data reconstruction stage and stores the correspondence between each map tile row and column number and its file offset address in the newly created map file. Using the map tile row and column numbers as indexes, a matching query is performed in the offset index to obtain the corresponding file offset address; then, the corresponding target storage data and its flag bits are extracted from the newly created map file based on the file offset address; With the above on-demand positioning method, the code meter only needs to extract a few tile data covered by the current field of view, without loading the entire map file, thus realizing on-demand loading of map data and effectively reducing the amount of data loaded per load and IO operation time; After extracting the target storage data and flag bits corresponding to the current field of view, the code table needs to decompress the data; Specifically, the extracted target storage data is loaded into the device's contiguous memory space at once, and then the flag bit corresponding to the target storage data is used to determine whether it has been compressed. If the flag indicates that the data is compressed, then the corresponding decompression operation is performed in contiguous memory to restore the original decompressed data. If the flag indicates that the data is uncompressed raw data, then there is no need to perform decompression; it can be used directly as decompressed data. Since data is loaded into contiguous memory for processing, memory addressing speed is much higher than file I / O operations, thus significantly improving data reading and processing efficiency; After decompression is complete, immediately release the memory space occupied by the target stored data during the loading process to free up limited device memory resources and avoid excessive memory usage that could cause the device to run slowly or crash. After obtaining the decompressed raw unit data, the code table can then perform map rendering. Since the decompressed data is completely consistent with the original unit data before compression, maintaining the complete map accuracy, map elements such as roads and points of interest can be directly extracted and drawn into the current display area according to their vector information to complete the rendering and display of the map. Thanks to fast addressing in contiguous memory, the map rendering process can be executed more efficiently, resulting in smoother map visuals and an improved user experience.

[0055] Based on the above offline map data processing method, the standard map file is split into the smallest compressed data unit and compressed separately. The smaller data is selected as the target storage data based on the comparison of the byte length before and after compression, so that the map file can minimize its overall size while maintaining data integrity. Meanwhile, by adding flag bits and establishing offset indexes to the target stored data during reconstruction, and extracting corresponding unit data on demand for decompression and rendering based on latitude and longitude information during loading, the code table does not need to load or decompress the entire map file at once. This significantly reduces the device's storage memory and running memory usage while improving the loading speed and rendering smoothness of map data, enabling resource-constrained embedded devices such as code tables to use offline maps efficiently.

[0056] like Figure 4 As shown, this embodiment of the invention also provides an offline map data processing system, including: The data acquisition module acquires raw geographic data files and converts them into standard map files. The data splitting module determines the smallest compressed data unit, splits the standard map file based on the smallest compressed data unit, and extracts the unit data corresponding to each smallest compressed data unit. The data compression module compresses each unit of data separately to obtain compressed data, and records the length of the first byte of each unit of data and the length of the second byte of the compressed data. The data reconstruction module compares the length of the first byte with the length of the second byte to obtain the comparison result. Based on the comparison result, it selects the target storage data from the unit data and compressed data, adds a flag bit to the target storage data, writes each target storage data and the corresponding flag bit into the new map file, and reconstructs the offset index in the new map file. The data loading module acquires latitude and longitude information, extracts the corresponding target storage data and marker bits from the newly created map file based on the latitude and longitude information and offset index, loads the extracted target storage data into contiguous memory, decompresses the target storage data in contiguous memory based on the marker bits to obtain decompressed data, and performs map rendering based on the decompressed data.

[0057] In some embodiments, the data reconstruction module is specifically used for: If the length of the second byte is less than the length of the first byte, the comparison result is that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result; If the length of the second byte is greater than or equal to the length of the first byte, the comparison result is that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

[0058] In some embodiments, the data reconstruction module is further configured to: The data type of each target storage data is generated based on the comparison results, and a flag bit is generated based on the data type and the byte length of the target storage data. Add each flag to the corresponding target storage data, and then write the target storage data after adding the flags into the new map file in sequence. Based on the writing order and byte length of each target storage data, the file offset address of each target storage data in the newly created map file is generated, and an offset index is constructed based on each file offset address.

[0059] In some embodiments, the data loading module is specifically used for: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file.

[0060] It should be noted that the above is a reference method and system for offline map data processing, and the present invention is not limited thereto.

[0061] This invention addresses the challenges of splitting standard map files into their smallest compressed data units and compressing them separately. Based on a comparison of byte lengths before and after compression, smaller data units are selected as the target storage data and flagged. Simultaneously, an offset index is established during reconstruction. This allows the codebook to extract the target storage data corresponding to the current viewpoint on demand, based on latitude and longitude information and map zoom level, when loading the map. Only the currently needed data is loaded into contiguous memory for decompression and rendering. This achieves efficient storage and on-demand loading of offline map data on resource-constrained devices such as codebooks. It solves the technical problems in existing technologies where compressing and decompressing the entire map file at once leads to insufficient device memory and computing power, and lossy compression results in decreased map accuracy, thus failing to meet navigation requirements.

[0062] Finally, it should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0063] The above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them; although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications can still be made to the specific implementation of the present invention or equivalent substitutions can be made to some technical features without departing from the spirit of the technical solutions of the present invention, and all such modifications and substitutions should be covered within the scope of the technical solutions claimed in the present invention.

Claims

1. An offline map data processing method, characterized by, include: Data acquisition steps: Obtain the raw geographic data file and convert the raw geographic data file into a standard map file; Data splitting steps: Determine the smallest compressed data unit, split the standard map file based on the smallest compressed data unit, and extract the unit data corresponding to each smallest compressed data unit; Data compression steps: Compress each of the unit data separately to obtain compressed data, and record the length of the first byte of each of the unit data and the length of the second byte of the compressed data; Data reconstruction steps: Compare the length of the first byte with the length of the second byte to obtain a comparison result. Based on the comparison result, select target storage data from the unit data and the compressed data, add a flag bit to the target storage data, write each target storage data and the corresponding flag bit into a new map file, and reconstruct the offset index in the new map file. Data loading steps: Obtain latitude and longitude information; extract corresponding target storage data and flag bits from the newly created map file based on the latitude and longitude information and the offset index; load the extracted target storage data into contiguous memory; decompress the target storage data in the contiguous memory based on the flag bits to obtain decompressed data; and perform map rendering based on the decompressed data.

2. The off-line map data processing method according to claim 1, characterized by, The data reconstruction steps are as follows: If the length of the second byte is less than the length of the first byte, then the comparison result indicates that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result. If the length of the second byte is greater than or equal to the length of the first byte, the comparison result indicates that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

3. The off-line map data processing method according to claim 1, characterized by, The data reconstruction step also includes: Based on the comparison results, a data type for each of the target stored data is generated, and a flag bit is generated based on the data type and the byte length of the target stored data. Each of the aforementioned flag bits is added to the corresponding target storage data, and the target storage data after adding the flag bits is written sequentially into the new map file; Based on the writing order and byte length of each target stored data, a file offset address for each target stored data is generated in the newly created map file, and the offset index is constructed based on each of the file offset addresses.

4. The off-line map data processing method according to claim 3, characterized by, The data loading steps are as follows: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and the map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file.

5. The off-line map data processing method according to claim 4, characterized by, The specific calculation model for the map tile row and column numbers is as follows: wherein, is a horizontal coordinate for a map tile row number; is a current longitude in the longitude and latitude information; is a map zoom level.

6. The offline map data processing method according to claim 5, characterized in that, The calculation model for the map tile row and column numbers also includes: in, The vertical coordinate of the map tile row and column number; The latitude is the current latitude in the latitude and longitude information.

7. An offline map data processing system, characterized in that, include: The data acquisition module acquires the raw geographic data file and converts the raw geographic data file into a standard map file. The data splitting module determines the smallest compressed data unit, splits the standard map file based on the smallest compressed data unit, and extracts the unit data corresponding to each smallest compressed data unit. The data compression module compresses each of the unit data separately to obtain compressed data, and records the length of the first byte of each of the unit data and the length of the second byte of the compressed data. The data reconstruction module compares the length of the first byte with the length of the second byte to obtain a comparison result. Based on the comparison result, it selects target storage data from the unit data and the compressed data, adds a flag bit to the target storage data, writes each target storage data and the corresponding flag bit into a new map file, and reconstructs the offset index in the new map file. The data loading module acquires latitude and longitude information, extracts corresponding target storage data and flag bits from the newly created map file based on the latitude and longitude information and the offset index, loads the extracted target storage data into contiguous memory, decompresses the target storage data in the contiguous memory based on the flag bits to obtain decompressed data, and performs map rendering based on the decompressed data.

8. The offline map data processing system according to claim 7, characterized in that, The data reconstruction module is specifically used for: If the length of the second byte is less than the length of the first byte, then the comparison result indicates that the compression is effective, and the compressed data is selected as the target storage data based on the comparison result. If the length of the second byte is greater than or equal to the length of the first byte, the comparison result indicates that the compression is invalid, and the unit data is selected as the target storage data based on the comparison result.

9. The offline map data processing system according to claim 7, characterized in that, The data reconstruction module is also used for: Based on the comparison results, a data type for each of the target stored data is generated, and a flag bit is generated based on the data type and the byte length of the target stored data. Each of the aforementioned flag bits is added to the corresponding target storage data, and the target storage data after adding the flag bits is written sequentially into the new map file; Based on the writing order and byte length of each target stored data, a file offset address for each target stored data is generated in the newly created map file, and the offset index is constructed based on each of the file offset addresses.

10. The offline map data processing system according to claim 9, characterized in that, The data loading module is specifically used for: Obtain the latitude and longitude information and map zoom level of the current display area of ​​the target device, and calculate the row and column numbers of the map tiles required to cover the current display area based on the latitude and longitude information and the map zoom level; The offset index is found based on the map tile row and column number to obtain the corresponding file offset address. Based on the file offset address, the corresponding target storage data and flag bits are extracted from the newly created map file.

Images