Vector map data processing method and system in resource-constrained environment

Abstract

The application discloses a kind of resource-restricted environment under vector map data processing method and system, method includes obtaining road network data, the road geometry point in road network data is carried out offline preprocessing;According to the same preset plane projection model with offline preprocessing, the position coordinates in terminal current pose information are projected and transformed;According to terminal current plane position, plane coordinate boundary and grid step, the index address corresponding to target grid is determined, and the road geometry data block corresponding to target grid is read according to index address;The road geometry data block read out is decoded, and the integer displacement coordinates are restored in combination with central reference coordinates, screen coordinate transformation and flow drawing processing are executed, and the to-be-displayed graph element is obtained;The visibility of to-be-displayed graph element is cut, and the target display graph element after cutting is output to augmented reality display interface.The application can realize the quick access and display of road network graph element under resource-restricted environment.

Description

Technical Field

[0001] This invention relates to the technical field of vector map data processing, and in particular to a method, system, computer equipment, and storage medium for vector map data processing under resource-constrained environments. Background Technology

[0002] When displaying road network information overlays, augmented reality (AR) terminals typically require the storage, retrieval, coordinate transformation, and primitive rendering of map data. Existing vector map processing solutions are mostly designed for general-purpose platforms with ample computing resources. In the processes of data organization, data retrieval, and display processing, they often rely on large-scale data loading, complex data parsing processes, and high runtime memory and computing resources. For resource-constrained terminals with limited runtime memory, storage and retrieval capabilities, and processing power, existing solutions are prone to inefficient road network data access, untimely display processing, and unstable display effects in practical applications, making it difficult to meet the real-time and stability requirements of augmented reality scenarios. Summary of the Invention

[0003] The purpose of this application is to propose a vector map data processing method, system, computer device, and storage medium under resource-constrained environments, in order to solve the technical problem of how to achieve efficient access, fast processing, and stable display of vector map data in resource-constrained environments with limited running memory, limited storage and retrieval capabilities, and weak processing capabilities, so as to meet the application requirements of road network element overlay display in augmented reality scenarios.

[0004] To address the aforementioned technical problems, this application provides a vector map data processing method under resource-constrained environments, employing the following technical solution: The system acquires road network data, performs offline preprocessing on the road geometry points in the road network data, converts the road geometry points into planar coordinates according to a preset planar projection model, determines the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and converts the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometry data blocks. Obtain the current pose information of the terminal, and perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing to obtain the current planar position of the terminal; Based on the current planar position of the terminal, the planar coordinate boundary, and the grid step size, determine the index address corresponding to the target grid, and read the road geometry data block corresponding to the target grid according to the index address; The read road geometry data block is decoded, and the integer displacement coordinates are restored by combining the center reference coordinates. Screen coordinate transformation and streaming drawing are performed without object heap allocation to obtain the primitives to be displayed. The visibility of the graphic elements to be displayed is clipped, and the clipped target graphic elements are output to the augmented reality display interface.

[0005] To address the aforementioned technical problems, this application also provides a vector map data processing system for resource-constrained environments, employing the following technical solution: The first acquisition module is used to acquire road network data, perform offline preprocessing on the road geometric points in the road network data, convert the road geometric points into planar coordinates according to a preset planar projection model, determine the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and convert the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks. The second acquisition module is used to acquire the current pose information of the terminal, and to perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing, so as to obtain the current planar position of the terminal. The determination module is used to determine the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary and the grid step size, and to read the road geometry data block corresponding to the target grid based on the index address; The restoration module is used to decode the read road geometry data block, restore the integer displacement coordinates by combining the center reference coordinates, and perform screen coordinate transformation and streaming drawing processing without object heap allocation to obtain the primitives to be displayed. The output module is used to perform visibility cropping on the graphic elements to be displayed and output the cropped target graphic elements to the augmented reality display interface.

[0006] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution: A computer device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the vector map data processing method under resource-constrained environment as described above.

[0007] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below: A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the vector map data processing method under resource-constrained conditions as described above.

[0008] Compared with the prior art, the embodiments of this application have the following main advantages: The vector map data processing method disclosed in this application for resource-constrained environments pre-constructs road network data into a vector map data package containing grid index information and road geometric data blocks. On the terminal side, based on the current pose information, the method directly locates the target grid, reads the corresponding data blocks, completes coordinate reconstruction, screen coordinate transformation, streaming rendering, and visibility clipping. This creates a closed-loop processing chain that is consistent between the map data organization and the terminal-side processing. Therefore, without loading complete road network data or constructing complex spatial index structures on the terminal side, it enables rapid access and display of road network primitives in resource-constrained environments. This reduces data reading overhead, lowers runtime memory usage, improves rendering real-time performance, and enhances the stability of augmented reality displays. Attached Figure Description

[0009] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart of an embodiment of the vector map data processing method under resource-constrained environment according to this application; Figure 2 This is a schematic diagram of a structure of an embodiment of a vector map data processing system under resource-constrained conditions according to this application; Figure 3 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with 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.

[0012] This embodiment provides a vector map data processing method under resource-constrained environments, applicable to augmented reality display terminals. The augmented reality display terminal can be smart glasses, head-mounted display devices, vehicle-mounted head-up displays, or other display devices that require overlaying road network map elements. The resource-constrained environment refers to an operating environment where the terminal has limited RAM, limited storage medium read / write throughput, limited processor computing power, and in some embodiments, does not have a floating-point unit or is unsuitable for large-scale dynamic memory allocation.

[0013] In the aforementioned operating environment, directly loading complete road network vector data and establishing complex object structures on the terminal side can easily lead to excessive data reading, high runtime memory consumption, frequent dynamic allocation, and increased rendering latency, thereby affecting the real-time performance and stability of augmented reality displays. Therefore, this implementation method combines offline preprocessing with on-terminal processing to pre-organize the road network data. On the terminal side, road geometry data within the target area is quickly located using a regular grid. Decoding, coordinate restoration, screen coordinate transformation, and streaming rendering are completed without object stack allocation, thus enabling rapid display of road network primitives in resource-constrained environments.

[0014] refer to Figure 1 The diagram illustrates a flowchart of an embodiment of a vector map data processing method for resource-constrained environments according to this application. The method includes the following steps: Step S101: Obtain road network data, perform offline preprocessing on the road geometric points in the road network data, convert the road geometric points into planar coordinates according to a preset planar projection model, determine the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and convert the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks.

[0015] Step S102: Obtain the current pose information of the terminal, and perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing to obtain the current planar position of the terminal.

[0016] Step S103: Determine the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary and the grid step size, and read the road geometry data block corresponding to the target grid based on the index address.

[0017] Step S104: Decode the read road geometry data block, and restore the integer displacement coordinates by combining the center reference coordinates. Perform screen coordinate transformation and streaming drawing processing without object heap allocation to obtain the primitives to be displayed.

[0018] Step S105: The visibility of the graphic element to be displayed is clipped, and the clipped target graphic element is output to the augmented reality display interface.

[0019] In this embodiment, road network data is first acquired. This road network data may include road centerline data, lane boundary data, navigation guide line data, or other linear map element data used for augmented reality display. Each road element in the road network data typically consists of multiple sequentially arranged road geometric points, each of which can be described using latitude and longitude coordinates.

[0020] During the offline processing phase, the road geometric points in the road network data are preprocessed. Specifically, the latitude and longitude coordinates of the road geometric points are first converted into planar coordinates according to a preset planar projection model, so that the original geographic coordinates are incorporated into a unified planar coordinate system. The preset planar projection model preferably adopts a Mercator-type planar projection model suitable for map display; in one specific embodiment, the Web Mercator projection model can be used. After the projection transformation, each road geometric point corresponds to a planar abscissa and a planar ordinate.

[0021] After obtaining the planar coordinates of all road geometric points, the planar coordinates of all road geometric points within the target area are statistically analyzed to determine the central reference coordinates, planar coordinate boundaries, and grid step size corresponding to the target area. The central reference coordinates can be the center point of the planar coordinate range of all road geometric points in the target area, or a preset reference point within the target area, as long as it can serve as a unified reference origin for the road geometric points within that target area. The planar coordinate boundaries are used to define the minimum envelope range of the target area and can include the minimum lateral coordinate, maximum lateral coordinate, minimum longitudinal coordinate, and maximum longitudinal coordinate. The grid step size represents the side length of a single grid cell when the target area is regularly divided in planar coordinate space; its value can be preset based on road density, terminal display ratio, and resource constraints.

[0022] After determining the central reference coordinates, the planar coordinates of each road geometric point are converted into integer displacement coordinates relative to the central reference coordinates. Specifically, for any road geometric point, its integer displacement x-coordinate can be obtained by subtracting the central reference x-coordinate from its planar x-coordinate, and then quantizing and rounding it to a predetermined precision; its integer displacement y-coordinate can be obtained by subtracting the central reference y-coordinate from its planar y-coordinate, and then quantizing and rounding it to a predetermined precision. In this way, road geometric points no longer store absolute planar coordinates in the data packet, but instead store integer displacement coordinates relative to the central reference coordinates, thereby reducing the range of coordinate values, lowering storage overhead, and facilitating fast decoding and coordinate reconstruction on the terminal side.

[0023] The converted integer displacement coordinates are written into the corresponding road geometry data blocks according to their respective grids, and combined with the index information described later to generate a vector map data package containing grid index information and road geometry data blocks. The generated vector map data package is stored in a terminal-accessible storage medium, such as Flash memory, read-only memory, or other non-volatile storage media.

[0024] During the online operation phase of the terminal, the current pose information of the terminal is acquired. This current pose information includes at least the terminal's current position coordinates; in some embodiments, it also includes heading angle, pitch angle, roll angle, display scale parameters, or field of view parameters. After acquiring the current position coordinates, the terminal performs a projection transformation on the current position coordinates according to the same preset planar projection model as the offline preprocessing, to obtain the terminal's current planar position. Since the projection model used when processing road geometry points offline is the same as the projection model used when processing the current position coordinates on the terminal side, the planar coordinate system of the road geometry points is consistent with the coordinate system of the terminal's current planar position, which can avoid the overlay and offset of road network primitives due to inconsistencies in the coordinate models.

[0025] After obtaining its current planar position, the terminal determines the index address corresponding to the target grid based on its current planar position, planar coordinate boundaries, and grid step size. The terminal can first determine the grid column number and grid row number based on its horizontal and vertical positions within the target area's planar coordinate range. Then, based on the number of grid columns recorded in the file header and the index item length, it calculates the position of the corresponding index item within the grid index area, i.e., the index address. The terminal reads the index item corresponding to the target grid based on this index address, and then obtains the offset address and data length of the corresponding road geometry data block within the road geometry data area from this index item, thereby reading the road geometry data block.

[0026] After reading the road geometry data block, the terminal decodes the integer displacement coordinates and restores them by combining them with the center reference coordinates. Specifically, the terminal combines the integer displacement x-coordinates with the center reference x-coordinates to recover the planar x-coordinates of the road geometry points; it also combines the integer displacement y-coordinates with the center reference y-coordinates to recover the planar y-coordinates of the road geometry points. Then, based on the terminal's current planar position, display scale, display center, and heading parameters, a screen coordinate transformation is performed to convert the restored planar coordinates into screen coordinates.

[0027] Throughout the process, the terminal does not construct independent heap objects for road geometry points. Instead, it loads the read road geometry data blocks into a preset fixed-length buffer, parses each integer displacement coordinate sequentially according to the storage order, and after completing the screen coordinate transformation of the current road geometry point or the current road segment, it directly calls the drawing callback to perform streaming drawing, generating the primitives to be displayed. This processing method avoids large-scale object heap allocation and reclamation, reducing runtime memory consumption and the risk of memory fragmentation.

[0028] Finally, the visibility of the graphic elements to be displayed is clipped. The terminal determines the display of the graphic elements based on the current viewport boundary and the logical buffer set outside the viewport. Graphic elements located within the viewport or within the logical buffer are retained for output display; graphic elements outside the logical buffer are no longer output. The clipped target graphic elements are output to the augmented reality display interface, completing the overlay display of the road network graphic elements.

[0029] This application pre-constructs road network data into a vector map data package containing grid index information and road geometric data blocks. On the terminal side, based on the current pose information, it directly locates the target grid, reads the corresponding data blocks, completes coordinate reconstruction, screen coordinate transformation, streaming rendering, and visibility clipping. This creates a closed-loop processing chain that is consistent between the map data organization and the terminal-side processing. Therefore, without loading complete road network data or constructing complex spatial index structures on the terminal side, it enables rapid access and display of road network primitives in resource-constrained environments. This reduces data reading overhead, lowers runtime memory usage, improves rendering real-time performance, and enhances the stability of augmented reality displays.

[0030] In some optional implementations of this embodiment, the steps of acquiring road network data, performing offline preprocessing on road geometric points in the road network data, converting the road geometric points into planar coordinates according to a preset planar projection model, determining the central reference coordinates, planar coordinate boundaries, and grid step size corresponding to the target area, and converting the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks include: The road geometric points are converted into planar coordinates according to the preset planar projection model, and the central reference coordinates, planar coordinate boundaries and grid step size are determined according to the distribution of road geometric points in the target area. The planar coordinates of each road geometric point are converted into integer displacement coordinates relative to the central reference coordinates, and the integer displacement coordinates are written into the corresponding road geometric data block.

[0031] In this embodiment, firstly, all road geometric points in the original road network data are uniformly transformed to a preset planar projection model. Taking any road element as an example, this road element can be composed of a point sequence P1, P2, P3...Pn, where each point in the point sequence corresponds to latitude and longitude coordinates. The offline processing program performs projection transformation on each point to obtain the corresponding planar coordinate sequence. In this way, all road geometric points in the original road network data are mapped to the same planar coordinate system.

[0032] Secondly, the planar coordinates of all road geometric points are statistically analyzed to obtain the planar coordinate range of the target area. The minimum lateral value of all points can be used as the minimum lateral coordinate within the planar coordinate boundary, the maximum lateral value as the maximum lateral coordinate, the minimum vertical value as the minimum vertical coordinate, and the maximum vertical value as the maximum vertical coordinate. The central reference coordinate can be selected as the midpoint of the aforementioned lateral and vertical ranges, or it can be selected as a preset anchor point of the target area according to specific project needs. The grid step size can be determined based on the terminal display range, road density, and desired retrieval granularity. For example, the number of road points within a single grid should be within a predetermined range to balance index granularity and data block size.

[0033] Subsequently, the planar coordinates of each road geometry point are converted into integer displacement coordinates relative to the central reference coordinates. For the lateral coordinates, quantization can be performed as follows: Subtract the central reference x-coordinate from the planar x-coordinate of the road geometry point to obtain the relative lateral displacement; then scale and round according to the preset accuracy coefficient to obtain the integer displacement x-coordinate.

[0034] For the vertical coordinate, the integer displacement vertical coordinate can be obtained in the same way.

[0035] The preset accuracy coefficient can be set according to the display accuracy requirements. For example, it can make a minimum integer unit correspond to a certain number of millimeters, centimeters, or decimeters of actual planar distance. By setting the accuracy coefficient, both the compression accuracy and the positioning accuracy requirements of the subsequent display can be met.

[0036] For each road feature, integer displacement coordinate pairs can be written into the road geometry data block in a point sequence order. To improve data organization efficiency, road feature identifiers, road point counts, road type, or line segment separators can also be written into the road geometry data block. The internal organization of the data block can be determined according to system needs, as long as the terminal can parse it in a predetermined format.

[0037] In some optional implementations of this embodiment, the aforementioned vector map data package includes a file header area, a grid index area, and a road geometry data area; The file header area records the central reference coordinates, the planar coordinate boundaries, the grid step size, and the number of grid columns; The grid index area records the offset address and data length of the corresponding road geometry data block for each grid, so that the terminal can read the corresponding road geometry data block based on the grid position.

[0038] In this embodiment, the file header area is located at the beginning of the data packet and is used to record the basic parameters required by the terminal to perform grid positioning, index reading, and coordinate reconstruction. The file header area records at least the center reference coordinates, plane coordinate boundaries, grid step size, and number of grid columns. In some embodiments, the file header area may also record additional parameters such as the number of grid rows, index item length, data packet version number, projection model identifier, and coordinate quantization precision coefficient.

[0039] Among them, the central reference coordinates are used for the terminal to restore the coordinates; the planar coordinate boundary is used to determine which grid the current position of the terminal falls into; the grid step size is used to divide the target area into regular grids; the number of grid columns is used to convert the two-dimensional grid position into a linear index position; and the index item length is used to calculate the number of bytes occupied by a single index item in the index area.

[0040] The grid index area, located after the file header, stores the index entry for each grid. Each index entry can correspond to a regular grid cell. The index entry must at least record the offset address and data length of the road geometry data block corresponding to that grid.

[0041] The offset address represents the starting position of the target road geometry data block within the road geometry data region; the data length represents the number of bytes occupied by the road geometry data block.

[0042] It's important to note that the index address and offset address have different meanings. The index address refers to the position of the index item itself within the grid index area; the offset address refers to the position of the data block corresponding to that index item within the road geometry data area. The terminal first obtains the index address through grid calculation, then reads the offset address and data length from the index item based on that index address, and finally locates and reads the target road geometry data block based on the offset address and data length.

[0043] The road geometry data region, located after the grid index region, is used to continuously store road geometry data blocks corresponding to each grid. Each road geometry data block can record the integer displacement coordinates of one or more road features within the grid's coverage area. When reading data from a specific grid, the terminal does not need to traverse the entire road geometry data region; instead, it directly reads the target data block using the offset address and data length recorded in the corresponding index entry.

[0044] Therefore, the file header area provides global parsing parameters, the grid index area provides the mapping relationship from grid to data blocks, and the road geometry data area provides the actual road geometry data. Together, these three constitute a complete data organization and reading structure. The terminal only needs to read the file header first, and then access the grid index area and road geometry data area as needed to quickly obtain the road network map metadata for the current area.

[0045] In some optional implementations of this embodiment, the step of determining the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary, and the grid step size includes: Based on the coordinate difference between the current planar position of the terminal and the planar coordinate boundary, the row number and column number corresponding to the target grid are determined respectively; Based on the row number, column number, number of grid columns, and preset index item length, the index address corresponding to the target grid is directly generated through arithmetic operations, and the offset address and data length of the road geometry data block corresponding to the target grid are read based on the index address.

[0046] In this embodiment, when determining the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary, and the grid step size, the direct arithmetic addressing method can be used.

[0047] Assuming the planar coordinate boundaries recorded in the file header include the minimum horizontal planar coordinate xmin and the minimum vertical planar coordinate ymin, the current terminal plane position is (x, y), and the grid step size is grid_step, then the terminal can determine the target grid column number and row number in the following way: The target grid column number can be obtained from the integer part of (x-xmin) / grid_step; The target grid row number can be obtained from the integer part of (y-ymin) / grid_step.

[0048] In boundary cases, range restrictions can also be applied to the calculation results to ensure that the column number is within the range of 0 to the number of grid columns minus 1, and the row number is within the range of 0 to the number of grid rows minus 1.

[0049] After obtaining the row and column numbers of the target grid, the index address is calculated based on the number of grid columns recorded in the file header and the preset index item length. If the file header area length is header_size and the length of a single index item is item_size, the index address of the corresponding index item of the target grid can be determined in the following way: Index address = header_size + ((row number × number of grid columns) + column number) × item_size.

[0050] The terminal reads the corresponding index entry based on the index address, and then obtains the offset address and data length from the index entry.

[0051] Subsequently, the terminal locates the starting position of the target road geometry data block in the road geometry data area based on the offset address, and reads the complete data block content according to the data length.

[0052] The above method uses a regular grid with fixed-length index entries. The terminal does not need to construct R-trees, quadtrees, or other multi-level index structures, nor does it need to perform multi-level traversals to locate the current position within the corresponding grid. For resource-constrained environments, this method reduces the overhead of index structure maintenance and traversal, thus improving real-time positioning and data retrieval efficiency.

[0053] In some implementations, after determining the current target grid, the terminal can further determine multiple candidate grids adjacent to the current target grid by combining the field of view or display area, and calculate their index addresses in the same way, so as to simultaneously read multiple road geometry data blocks required within the current field of view. This extended processing does not change the basic calculation logic of the index address.

[0054] In some optional implementations of this embodiment, the step of obtaining the current pose information of the terminal and performing a projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing to obtain the current planar position of the terminal includes: The location coordinates are projected using the same Web Mercator projection model as the offline preprocessing to obtain the current planar position of the terminal; The projection transformation is performed on the terminal side using a tangent logarithmic approximation method suitable for fixed-point arithmetic environments.

[0055] In this embodiment, for the position coordinates in the terminal's current pose information, the terminal uses the same WebMercator projection model as the offline preprocessing to perform projection transformation to obtain the terminal's current planar position.

[0056] During the offline preprocessing stage, the latitude and longitude coordinates of the road geometry points have been converted into planar coordinates using the WebMercator projection model. Therefore, after projecting the terminal's current position coordinates using the same model, the resulting current planar position of the terminal and the planar coordinates of the road geometry points are in a unified coordinate system. This ensures consistency in the coordinate system between the preceding and following steps when converting the road geometry points into screen coordinates and overlaying them for display, thus reducing display deviations.

[0057] Taking the current location's longitude (lon) and latitude (lat) as an example, the terminal can calculate the horizontal and vertical plane coordinates based on the basic relationships of WebMercator projection. The horizontal plane coordinates can be linearly converted based on the longitude value, and the vertical plane coordinates can be converted based on the tangent logarithmic relationship corresponding to the latitude value.

[0058] Considering the limitations of the terminal's operating environment, and to avoid directly calling high-overhead floating-point arithmetic functions, this embodiment preferably uses the tangent logarithmic approximation method, which is suitable for fixed-point arithmetic environments, to perform the projection transformation.

[0059] Specifically, for the calculation of horizontal plane coordinates, since there is usually a linear correspondence between longitude and Mercator horizontal coordinates, the conversion can be completed through fixed-point multiplication and addition; for the calculation of vertical plane coordinates, since it involves tangent and logarithmic relationships, the following approximation method can be used: First, convert the latitude value into a fixed-point representation; Then select the corresponding approximate parameters based on the latitude value's range; Then, by looking up a table, piecewise linear approximation, low-order polynomial approximation, or iterative calculation with preset coefficients, the approximate vertical plane coordinate values ​​are obtained.

[0060] The above approximation method can pre-establish approximate parameters for the target using a latitude range, thus balancing computational accuracy and efficiency.

[0061] In some implementations, the terminal can pre-store approximate parameter tables corresponding to multiple latitude intervals in its memory. After receiving the current location coordinates, the terminal first determines the interval to which the latitude value belongs, and then calls the parameters of the corresponding interval to perform fixed-point approximation calculations. In this way, the terminal's current planar position that meets the accuracy requirements of augmented reality display can be obtained with lower computational cost.

[0062] It should be noted that the tangent logarithm approximation method is not limited to a single mathematical expression. As long as it can approximate the vertical coordinate conversion in WebMercator projection on the terminal side using fixed-point arithmetic and maintain consistency with the projection results on the offline side, it can fall within the protection scope of this embodiment.

[0063] In some optional implementations of this embodiment, the steps of decoding the read road geometry data block, restoring the integer displacement coordinates by combining the center reference coordinates, and performing screen coordinate transformation and streaming rendering without object heap allocation to obtain the primitives to be displayed include: The road geometry data block is read into a preset fixed-length buffer, and the integer displacement coordinates therein are parsed sequentially. The integer displacement coordinates obtained from the parsing are combined with the central reference coordinates to restore the planar coordinates. Then, based on the current planar position of the terminal and the display ratio, the screen coordinate transformation is performed, and the drawing callback is directly called to perform streaming drawing.

[0064] In this embodiment, when the terminal reads the target road geometry data block, it can perform decoding, coordinate restoration, screen coordinate transformation, and streaming rendering processing on it using a sequential processing method without object heap allocation.

[0065] First, the terminal sets a preset fixed-length buffer. This fixed-length buffer can be allocated once during program initialization and is used to repeatedly hold road geometry data blocks read from the storage medium each time during runtime. The size of the fixed-length buffer can be set according to the upper limit of the data blocks read in a single session, for example, the number of bytes that can hold one or more road geometry data blocks. Because this buffer is reused repeatedly during program execution, it is not necessary to dynamically allocate new heap memory space for each road point or each road feature during the drawing process.

[0066] After loading the target road geometry data block into a fixed-length buffer, the terminal parses the integer displacement coordinates within it in a predetermined data format. Sequential parsing means that the terminal reads information such as the number of road points, road type identifiers, and integer displacement coordinate pairs from beginning to end according to the storage order in the road geometry data block, without needing to first construct a complete intermediate linked list or object set.

[0067] For each integer displacement x-coordinate and y-coordinate obtained from the analysis, the terminal combines them with the central reference coordinates recorded in the file header to reconstruct the coordinates. Specifically, the integer displacement values ​​can be converted back to relative planar displacements according to the precision coefficients used in offline quantization, and then superimposed with the central reference coordinates to restore the planar coordinates of the road geometric points.

[0068] After recovering the planar coordinates of the road geometry point, the terminal performs screen coordinate transformation based on its current planar position, display scale, and display coordinate system. Taking any road geometry point as an example, the terminal can first calculate the planar difference between the road geometry point and its current planar position; then, based on the display scale parameter, it maps this planar difference to a pixel offset on the display plane; if there is a heading rotation, it can further perform a rotation transformation on the planar difference based on the terminal's heading parameter, so that the display direction of the road geometry point on the screen is consistent with the terminal's orientation; finally, the transformation result is superimposed on the display center position to obtain the corresponding screen coordinates.

[0069] After obtaining the screen coordinates of the current road geometry point or the current line segment, the terminal does not cache all points as a complete road object before drawing them all at once. Instead, it directly calls the drawing callback to output the current road point or the current line segment to the drawing module for streaming drawing.

[0070] Streaming rendering refers to the sequential and continuous execution of parsing, coordinate restoration, screen coordinate transformation, and rendering output. The result of the previous process can be directly used as the input for the next process without waiting for the entire data block to be parsed before unified processing.

[0071] For example, once the terminal resolves the geometric points of two adjacent road elements and completes the screen coordinate transformation between them, it can directly call the drawing callback to draw the line segment connecting these two points, without having to store all the coordinates of the road element completely before drawing them all at once.

[0072] In this way, the terminal can control runtime memory usage within a fixed-length buffer and a small number of intermediate variables, thereby adapting to the operating requirements of resource-constrained environments.

[0073] Since the entire process does not require allocating heap objects for each road geometry point, road feature, or display primitive, it effectively avoids the performance loss and memory fragmentation issues caused by frequent malloc and free operations, which is beneficial to improving the real-time performance and stability of the rendering process.

[0074] In some optional implementations of this embodiment, the steps of performing visibility clipping on the primitives to be displayed and outputting the clipped target display primitives to the augmented reality display interface include: A logical buffer with a preset pixel range is set outside the display viewport, and the visibility of primitives is determined based on the logical buffer during the streaming rendering process. Primitives located outside the logical buffer are clipped, and primitives located within the logical buffer are displayed to reduce flickering of primitives in the viewport edge area.

[0075] In this embodiment, when the terminal performs visibility clipping on the graphic elements to be displayed, it can set a logical buffer with a preset pixel range outside the display viewport, and determine the visibility of the graphic elements based on the logical buffer during the streaming rendering process.

[0076] Specifically, assuming the effective display area of ​​the current display viewport in the screen coordinate system is a rectangular area, the terminal extends beyond the upper, lower, left, and right boundaries of this rectangular area by a preset pixel distance, forming a logical buffer larger than the display viewport. The preset pixel range can be set based on the terminal's movement speed, display refresh rate, road display width, or project experience values; for example, it can be set to an extension range of several to tens of pixels.

[0077] After the terminal completes the screen coordinate transformation of the road geometry points, for the point or line segment to be drawn, it first determines whether it is within the logical buffer.

[0078] If the current primitive is completely outside the logical buffer, it is assumed that the primitive will not enter the display viewport in a short time, and it can be clipped directly without continuing to draw.

[0079] If the current graphic element is within the display viewport, or if it is outside the display viewport but has entered the logical buffer range, then the graphic element is retained and allowed to continue participating in the display output.

[0080] For line segment primitives, the terminal can also determine whether any endpoint of the line segment is located within the logical buffer, or whether the line segment intersects with the boundary of the logical buffer, in order to determine whether the line segment needs to be retained.

[0081] The reason for using the above-mentioned logical buffer is that during augmented reality display, the terminal continuously refreshes the viewport range as the user's head moves, position changes, or viewing angle changes. If only the strict display viewport is used as the display judgment boundary, primitives near the edge of the viewport will frequently enter and leave the viewport with slight pose changes, which can easily cause edge flickering or "jumping" phenomena.

[0082] By adding a logical buffer layer outside the display viewport, the graphic element can be reserved in advance before it enters the display area and clipped after it leaves the display area. This provides a transition display range for edge graphics elements and reduces flickering caused by repeated showing and hiding.

[0083] In some implementations, the size of the logical buffer can be dynamically adjusted according to the speed of change in the terminal's pose. When an increase in the terminal's movement speed or the speed of change in the viewing angle is detected, the range of the logical buffer can be appropriately increased to improve display stability in fast-moving scenarios; when the terminal's movement is relatively stable, the range of the logical buffer can be appropriately decreased to reduce invalid rendering.

[0084] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0085] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0086] Further reference Figure 2 As a response to the above Figure 1 The implementation of the method shown in this application provides an embodiment of a vector map data processing system under resource-constrained environments. This system embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0087] like Figure 2 As shown, the vector map data processing system 200 under resource-constrained environment described in this embodiment includes: a first acquisition module 201, a second acquisition module 202, a determination module 203, a restoration module 204, and an output module 205. Wherein: The first acquisition module 201 is used to acquire road network data, perform offline preprocessing on the road geometric points in the road network data, convert the road geometric points into planar coordinates according to a preset planar projection model, determine the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and convert the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks. The second acquisition module 202 is used to acquire the current pose information of the terminal, and to perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing, so as to obtain the current planar position of the terminal. The determination module 203 is used to determine the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary and the grid step size, and to read the road geometry data block corresponding to the target grid based on the index address; The restoration module 204 is used to decode the read road geometry data block, restore the integer displacement coordinates by combining the center reference coordinates, and perform screen coordinate transformation and streaming drawing processing without object heap allocation to obtain the primitives to be displayed. The output module 205 is used to perform visibility cropping on the graphic elements to be displayed and output the cropped target display graphic elements to the augmented reality display interface.

[0088] The vector map data processing system under resource-constrained environment provided in this embodiment of the invention can realize all the processes of the vector map data processing method under resource-constrained environment in the above embodiments. The functions and technical effects of each module in the device are the same as the functions and technical effects of the vector map data processing method under resource-constrained environment in the above embodiments, and will not be repeated here.

[0089] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.

[0090] The computer device 3 includes a memory 31, a processor 32, and a network interface 33 that are interconnected via a system bus. It should be noted that only the computer device 3 with components 31-33 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0091] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0092] The memory 31 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 31 may be an internal storage unit of the computer device 3, such as the hard disk or memory of the computer device 3. In other embodiments, the memory 31 may also be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Of course, the memory 31 may also include both the internal storage unit and its external storage device of the computer device 3. In this embodiment, the memory 31 is typically used to store the operating system and various application software installed on the computer device 3, such as computer-readable instructions for vector map data processing methods in resource-constrained environments. In addition, the memory 31 can also be used to temporarily store various types of data that have been output or will be output.

[0093] In some embodiments, the processor 32 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 32 is typically used to control the overall operation of the computer device 3. In this embodiment, the processor 32 is used to execute computer-readable instructions stored in the memory 31 or to process data, for example, to execute computer-readable instructions for the vector map data processing method under resource-constrained conditions.

[0094] The network interface 33 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 3 and other electronic devices.

[0095] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the vector map data processing method under resource-constrained environment as described above.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0097] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing vector map data under resource-constrained environments, characterized in that, Includes the following steps: The system acquires road network data, performs offline preprocessing on the road geometry points in the road network data, converts the road geometry points into planar coordinates according to a preset planar projection model, determines the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and converts the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometry data blocks. Obtain the current pose information of the terminal, and perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing to obtain the current planar position of the terminal; Based on the current planar position of the terminal, the planar coordinate boundary, and the grid step size, determine the index address corresponding to the target grid, and read the road geometry data block corresponding to the target grid according to the index address; The read road geometry data block is decoded, and the integer displacement coordinates are restored by combining the center reference coordinates. Screen coordinate transformation and streaming drawing are performed without object heap allocation to obtain the primitives to be displayed. The visibility of the graphic elements to be displayed is clipped, and the clipped target graphic elements are output to the augmented reality display interface.

2. The method according to claim 1, characterized in that, The steps of acquiring road network data, performing offline preprocessing on road geometric points in the road network data, converting the road geometric points into planar coordinates according to a preset planar projection model, determining the central reference coordinates, planar coordinate boundaries, and grid step size corresponding to the target area, and converting the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks include: The road geometric points are converted into planar coordinates according to the preset planar projection model, and the central reference coordinates, planar coordinate boundaries and grid step size are determined according to the distribution of road geometric points in the target area. The planar coordinates of each road geometric point are converted into integer displacement coordinates relative to the central reference coordinates, and the integer displacement coordinates are written into the corresponding road geometric data block.

3. The method according to claim 2, characterized in that, The vector map data package includes a file header area, a grid index area, and a road geometry data area; The file header area records the central reference coordinates, the planar coordinate boundaries, the grid step size, and the number of grid columns; The grid index area records the offset address and data length of the corresponding road geometry data block for each grid, so that the terminal can read the corresponding road geometry data block based on the grid position.

4. The method according to claim 1, characterized in that, The step of determining the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary, and the grid step size includes: Based on the coordinate difference between the current planar position of the terminal and the planar coordinate boundary, the row number and column number corresponding to the target grid are determined respectively; Based on the row number, column number, number of grid columns, and preset index item length, the index address corresponding to the target grid is directly generated through arithmetic operations, and the offset address and data length of the road geometry data block corresponding to the target grid are read based on the index address.

5. The method according to claim 1, characterized in that, The step of obtaining the current pose information of the terminal and performing a projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing to obtain the current planar position of the terminal includes: The location coordinates are projected using the same Web Mercator projection model as the offline preprocessing to obtain the current planar position of the terminal; The projection transformation is performed on the terminal side using a tangent logarithmic approximation method suitable for fixed-point arithmetic environments.

6. The method according to claim 1, characterized in that, The steps of decoding the read road geometry data block, restoring the integer displacement coordinates by combining the center reference coordinates, and performing screen coordinate transformation and streaming rendering without object heap allocation to obtain the primitives to be displayed include: The road geometry data block is read into a preset fixed-length buffer, and the integer displacement coordinates therein are parsed sequentially. The integer displacement coordinates obtained from the parsing are combined with the central reference coordinates to restore the planar coordinates. Then, based on the current planar position of the terminal and the display ratio, the screen coordinate transformation is performed, and the drawing callback is directly called to perform streaming drawing.

7. The method according to claim 6, characterized in that, The steps of performing visibility clipping on the primitives to be displayed and outputting the clipped target display primitives to the augmented reality display interface include: A logical buffer with a preset pixel range is set outside the display viewport, and the visibility of primitives is determined based on the logical buffer during the streaming rendering process. Primitives located outside the logical buffer are clipped, and primitives located within the logical buffer are displayed to reduce flickering of primitives in the viewport edge area.

8. A vector map data processing system for resource-constrained environments, characterized in that, include: The first acquisition module is used to acquire road network data, perform offline preprocessing on the road geometric points in the road network data, convert the road geometric points into planar coordinates according to a preset planar projection model, determine the central reference coordinates, planar coordinate boundaries and grid step size corresponding to the target area, and convert the planar coordinates into integer displacement coordinates relative to the central reference coordinates to generate a vector map data package containing grid index information and road geometric data blocks. The second acquisition module is used to acquire the current pose information of the terminal, and to perform projection transformation on the position coordinates in the current pose information of the terminal according to the same preset planar projection model as the offline preprocessing, so as to obtain the current planar position of the terminal. The determination module is used to determine the index address corresponding to the target grid based on the current planar position of the terminal, the planar coordinate boundary and the grid step size, and to read the road geometry data block corresponding to the target grid based on the index address; The restoration module is used to decode the read road geometry data block, restore the integer displacement coordinates by combining the center reference coordinates, and perform screen coordinate transformation and streaming drawing processing without object heap allocation to obtain the primitives to be displayed. The output module is used to perform visibility cropping on the graphic elements to be displayed and output the cropped target graphic elements to the augmented reality display interface.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the vector map data processing method under a resource-constrained environment as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the vector map data processing method under a resource-constrained environment as described in any one of claims 1 to 7.

Images