DEM file processing method, electronic equipment and storage medium

Abstract

The invention provides a DEM file processing method, electronic equipment and a storage medium. The method comprises the steps that multiple to-be-processed DEM files are acquired; establishing a first-level index used for searching a target DEM file, and establishing a second-level index used for searching data in the target DEM file; wherein the target DEM file is determined according to one or more DEM files to be processed. According to the method and the device, merging of all the DEM files is avoided, and a double-layer index strategy is adopted, that is, all the DEM files and the elevation data in the files are indexed and managed by establishing the first-level index and the second-level index. In this way, not only can the system overhead be reduced, but also the processing efficiency and maintainability of the data can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a DEM file processing method, electronic device, and storage medium. Background Technology

[0002] Typically, elevation data for a given area is stored in a series of files (usually in GeoTIFF format, a geospatial data file format), often referred to as DEM (Digital Elevation Model) files. Because individual DEM files are quite large (ranging from hundreds of MB to tens of GB), the overall data volume becomes enormous when these DEM files collectively describe a large area. Merging the elevation data of the entire area into a single DEM file could introduce significant challenges in terms of file system complexity, program processing complexity, and compression efficiency. Summary of the Invention

[0003] This application provides a DEM file processing method, an electronic device, and a storage medium to solve one or more of the above-mentioned technical problems.

[0004] In a first aspect, embodiments of this application provide a DEM file processing method, comprising: acquiring a plurality of DEM files to be processed; establishing a primary index for finding a target DEM file, and establishing a secondary index for finding data in the target DEM file; wherein the target DEM file is determined based on one or more of the DEM files to be processed.

[0005] Secondly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method described in any of the above-mentioned embodiments.

[0006] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in any of the above-mentioned embodiments.

[0007] Compared with related technologies, this application has the following advantages: This application provides a DEM file processing method, including: acquiring multiple DEM files to be processed; establishing a primary index for locating a target DEM file, and establishing a secondary index for locating data within the target DEM file; wherein the target DEM file is determined based on one or more of the DEM files to be processed. According to embodiments of this application, instead of merging all DEM files, a two-level indexing strategy is adopted, that is, by establishing a primary index and a secondary index, all DEM files and their elevation data are indexed and managed. This approach not only reduces system overhead but also improves data processing efficiency and maintainability.

[0008] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0009] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0010] Figure 1 A flowchart of a DEM file processing method provided in an embodiment of this application is shown; Figure 2 This illustration shows a schematic diagram of a quadtree splitting process provided in an embodiment of this application; Figure 3 A flowchart illustrating a grid cutting and merging process provided in an embodiment of this application is shown; Figure 4 This illustration shows a schematic diagram of a leaf node logical block division process provided in an embodiment of this application; Figure 5 This illustration shows a schematic representation of a logical block index provided in an embodiment of this application; Figure 6 A schematic diagram illustrating the generation process of a terrain slice provided in an embodiment of this application is shown; Figure 7 A schematic diagram of a rendering result including cracks is shown in an embodiment of this application; Figure 8 This illustration shows a schematic diagram of a data slice region expansion result provided in an embodiment of this application; Figure 9 This illustration shows a process for reading elevation data provided in an embodiment of this application; Figure 10 This illustration shows a schematic diagram of elevation data points provided in an embodiment of this application; Figure 11 This illustration shows a schematic diagram of a region feature point and vertex provided in an embodiment of this application; Figure 12 This illustration shows a boundary point diagram with a missing region provided in an embodiment of this application; Figure 13 A schematic diagram of a triangular mesh constructed using a traditional grid method is shown in an embodiment of this application; Figure 14 This illustration shows a triangular mesh constructed using 13 as the current level height difference threshold, as provided in an embodiment of this application. Figure 15 This illustration shows a triangular mesh constructed using 12 as the current level height difference threshold, as provided in an embodiment of this application. Figure 16 This illustration shows a triangulation diagram constructed using 12 as the current level and a terrain quality factor of 0.1 to calculate the height difference threshold, as provided in an embodiment of this application. Figure 17 This illustration shows a schematic diagram of a terrain triangular mesh generated from DEM data, provided in an embodiment of this application. Figure 18 This application provides an example of a rendering showing an overlay image. Figure 19 This application provides an embodiment of a rendering showing the effect of fusing real-time sliced ​​urban terrain with other types of data under a heatmap effect; Figure 20 This illustration shows a schematic diagram of the request time result of a different method provided in an embodiment of this application; Figure 21 A block diagram of an electronic device used to implement embodiments of this application is shown. Detailed Implementation

[0011] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0012] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0013] First, the terms involved will be explained.

[0014] A Digital Elevation Model (DEM) is a digital simulation of ground topography (i.e., a digital representation of the surface morphology of terrain) achieved through limited terrain elevation data. It is a physical ground model that represents ground elevation using an ordered array of numerical values. It is a branch of Digital Terrain Models (DTMs), from which various other terrain feature values ​​can be derived. Using the Global Positioning System (GPS) in conjunction with radar and laser altimeters, DEM information for fixed areas can be collected. In the aerospace field, large-scale DEM information can also be obtained through photogrammetry.

[0015] Object-based storage is a data storage architecture that manages data as discrete objects, rather than as a collection of files like a file system or as a sequence of bytes within sectors like block storage. Each object includes the data itself, metadata, and a globally unique identifier (often called an object key or object ID). This architecture is designed to simplify data management and improve the efficiency of large-scale distributed systems.

[0016] Triangular meshes (TMMs) are a common method for representing two-dimensional and three-dimensional objects in Geographic Information Systems (GIS), corresponding to the representation of surfaces and volumes in geographic information. When constructing TMMs using DEM information, the following two methods are mostly used: Regular grid DEM: This method treats elevation as pixels and considers the squares constructed from image pixels as rectangular grids. Each grid consists of two right-angled triangles, and N squares form a terrain grid. The amount of data is controlled by adjusting the length and width of each rectangular grid in pixels. This method is simple and easy to implement, but it requires a large amount of data. The more refined the grid, the more data is needed, and selecting points according to rules cannot guarantee the terrain features to the greatest extent.

[0017] Irregular Triangular Network (TIN) Model: To solve the problem of regular grids, it is necessary to adjust the point selection method. A common method is to retain important points.

[0018] The method of retaining important points: The core idea is to remove points that are considered "unimportant" from the grid, and then construct an irregular triangular network with the remaining points.

[0019] DEM files: Digital Elevation Model files, which are single-channel GeoTIFF files unless otherwise specified below.

[0020] Pyramid tiling is a technique widely used in Geographic Information Systems (GIS). It optimizes data storage, transmission, and rendering efficiency by dividing maps or imagery into smaller tiles (tiles, as used hereafter unless otherwise specified) according to different zoom levels. However, it also has limitations, such as high storage requirements, update complexity, and insufficient support for real-time content.

[0021] Pre-tiled: In conventional geographic information services, data requiring pyramid tile display is often generated in advance due to the generation principle and the sheer volume of data. This process, where tiles are retrieved on demand, is called pre-tiled. Pre-tiled tiles have fixed tile areas, sizes, and resolutions.

[0022] Global slicing: When building pre-slices, due to the large amount of file data and slow reading, each step in the slice building process is performed on the entire file to generate slices in batches, thereby reducing repetitive processes.

[0023] On-demand slicing: Builds a single slice based only on the slice area, size, and precision, and processes only the data required by the target slice.

[0024] Real-time slicing: A real-time slicing solution that builds slices in real time by reading metadata and building them in real time when needed. It has lower storage requirements, higher flexibility, and support for real-time content.

[0025] Regional feature points: When the absolute value of the difference between the elevation value of a point and the average elevation values ​​of the surrounding eight points is greater than the activation threshold of the current level, the point is activated at the current level. The activated point is called a regional feature point.

[0026] Edge-overlapping slices: Each time slice data is acquired, additional pixels from adjacent boundary regions are captured. This extra data is reused in adjacent slices, but only participates in the calculation of region feature points; it does not generate region feature points.

[0027] Hierarchical activation: When activating feature points in an active region, the activation state is also propagated to lower levels of the current level.

[0028] Non-hierarchical activation: When activating feature points in an activation region, activation only occurs at the current level and does not propagate to lower levels.

[0029] With the continuous development of various remote sensing satellite technologies, the quality and scale of remote sensing image data are getting higher and higher, and applications such as digital mapping, land use analysis, and disaster monitoring can be expressed more accurately to a large extent. As the acquisition of digital elevation models (DEMs) becomes simple and accurate, qualified enterprises or local units can obtain massive amounts of ground information.

[0030] Cloud-based services are a widely accepted approach across various industries. By leveraging object storage technology, massive amounts of data are stored in the cloud, enabling cloud access to this data. Rapidly buildable and accessible terrain data cloud services can be used to construct digital surface models on some GIS platforms in conjunction with base maps, offering a wide range of applications. For example, they play a crucial role in rapidly building geographic models of a region, such as railway planning, regional change comparison, and disaster observation. Terrain services typically utilize pre-tiling technology to generate all potentially usable tiles, which are then loaded on demand. This technique loads only the terrain data within the user's current field of view, reducing unnecessary data loading and representing the standard approach to terrain processing today.

[0031] When using pre-tiled maps to build terrain tiles, a significant challenge arises when deploying services to the cloud: the performance pressure of storing and rapidly accessing large amounts of tile data. Traditional tiling methods are limited by data retrieval methods and data volumes. When building the grid, a simple approach of constructing right-angled triangular meshes is used, which cannot effectively handle areas with drastic changes. Furthermore, traditional tiling cannot be updated quickly when data needs to be updated, requiring reprocessing and redeployment.

[0032] In large-scale 2D and 3D data visualization, most data requires pre-slicing to achieve 3D data slicing and LOD (Level of Detail) specifications. When uploading data to the cloud, sliced ​​data requires a significant amount of cloud storage space, approximately three times that of the original data. If the original data is modified, all pre-sliced ​​data needs to be regenerated, which is time-consuming and labor-intensive. In terrain slicing, it is necessary to generate all slices of each DEM data at all scaling levels. After uploading the data to the cloud, terrain data services face the following challenges: 1. Slow data retrieval: DEM data is stored as TIFF images. Even if only data at a specific boundary is needed, the entire image must be read to obtain the corresponding data. On-demand retrieval is impossible; even if many slices are rarely accessed, they still need to be fully read and generated. This process is limited by the size of individual image data and the actual storage method; the larger the data, the slower the access. This is one of the reasons why 3D data is mostly produced by pre-slicing.

[0033] 2. Large amounts of sliced ​​data require significant storage space. Uploading data to the cloud also necessitates data backup and error correction, requiring even more storage. During data retrieval, regardless of whether it's based on a file system or object storage technology, accessing excessive sliced ​​data becomes a performance bottleneck for network access when dealing with large datasets.

[0034] 3. Traditional terrain tiling uses right-angled triangle grids (such as Google Maps) during pre-tiling because this method is simpler to calculate and is beneficial for processing large amounts of data, but it is not flexible enough in representing terrain.

[0035] Due to data splicing or data resampling, cracks may appear at the slice boundaries. Traditional methods use interpolation algorithms or smoothing of boundary points to handle this, which can cause some drastically changing areas to become slopes and lose their original shape.

[0036] Based on this, this application provides a DEM file processing method, electronic device, and storage medium. This application can perform real-time terrain tiling, avoiding the generation of a large number of tiles while simultaneously meeting the need for real-time access, thereby replacing traditional terrain services and solving the above pain points. Based on the DEM file processing method provided in this application, real-time tiling is used instead of pre-tiling, avoiding the production of a large number of tiles, reducing data production steps, eliminating the need for large amounts of space to store tiles, and eliminating the need to consider how to quickly access a large number of tiles. The quadtree structure designed in this application can quickly update the original data, suitable for terrain services that require frequent data updates. In this application, the Delaunay triangular terrain mesh expresses the same number of regional feature points with fewer triangles, reducing resource consumption during page rendering, lowering hardware requirements, and reducing the pressure on the overlay rendering of multiple data sets.

[0037] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0038] This application provides a method for processing DEM files. For example... Figure 1 The diagram shown is a flowchart of a DEM file processing method according to an embodiment of this application. The method may include: Step S101: Obtain multiple DEM files to be processed.

[0039] In this embodiment, the DEM file to be processed is a DEM file saved in GeoTIFF format. The DEM saved in GeoTIFF can be single-channel data. Multiple DEM files to be processed are acquired, and the size of the geographic coordinate range corresponding to each DEM file can be different, as can the resolution of each DEM file. The DEM file may include, but is not limited to, three dimensions: the longitude and latitude of pixels, and the elevation represented by the pixel values.

[0040] Step S102: Establish a primary index for finding target DEM files and establish a secondary index for finding data in the target DEM files; wherein the target DEM files are determined based on one or more of the DEM files to be processed.

[0041] In this embodiment, considering that elevation is the target value in terrain generation, latitude and longitude can be indexed. Therefore, at least based on the geographic coordinate range corresponding to the DEM file to be processed, a first-level index for finding the target DEM file is established. The target DEM file is determined based on one or more of the DEM files to be processed; that is, the target DEM file may include all information from one or more of the DEM files to be processed, or it may include partial information from one or more of the DEM files to be processed. The target DEM file is obtained by combining information from one or more of the DEM files to be processed. Therefore, it can be ensured that DEM files of different sizes and resolutions are adjusted according to the requirements of the first-level index, facilitating the search for the adjusted target DEM file.

[0042] Next, an index is created for the elevation data in each target DEM file in the primary index to facilitate quick and flexible retrieval of data in the target DEM files, i.e., a secondary index is created for retrieval of data in the target DEM files.

[0043] This application provides a DEM file processing method, including: acquiring multiple DEM files to be processed; establishing a primary index for locating a target DEM file, and establishing a secondary index for locating data within the target DEM file; wherein the target DEM file is determined based on one or more of the DEM files to be processed. According to this application, instead of merging all DEM files, a two-level indexing strategy is adopted, that is, by establishing a primary index and a secondary index, all DEM files and their elevation data are indexed and managed. This approach not only reduces system overhead but also improves data processing efficiency and maintainability.

[0044] To balance the complexity and efficiency of index construction, a first-level index can be built using a quadtree. In one possible implementation, building a first-level index for finding target DEM files can be performed as follows: determining the root node encompassing the geographic coordinate range corresponding to the multiple DEM files to be processed; constructing a quadtree based on the root node, and using the quadtree as the first-level index; wherein the leaf nodes of the quadtree correspond one-to-one with the target DEM files.

[0045] In this possible implementation, firstly, the range of the root node and the size of the smallest node of the quadtree can be determined. The range of the root node can be determined by determining the geographic coordinate range corresponding to the multiple DEM files to be processed. To simplify the calculation, the root node of the quadtree can be constructed based on the range of the entire DEM data. However, considering that the actual range of the DEM file may not be a regular rectangle (e.g., an irregular boundary or polygonal coverage area), in this embodiment, a positive bounding box (a smallest rectangle that can completely contain the target range, whose boundary is parallel to the coordinate system axis) is taken as the range of the root node to ensure complete coverage of the effective data range of the DEM file to be processed. The specific formula for the range of the root node is as follows: in Indicates the first One DEM, Indicates the first The first in the DEM Each point, data point of each DEM .

[0046] In this embodiment, when establishing an index for finding target DEM files (i.e., a first-level index), each leaf node of the quadtree corresponds to a target DEM file. These target DEM files are the data that needs to be actually read and processed later. The minimum range of a leaf node in the quadtree is determined by the geographic coordinate range of a single target DEM file. It should be noted that the geographic coordinate range corresponding to a target DEM file may not fill the entire preset leaf node range. Therefore, the minimum range of a leaf node is determined by the geographic coordinate range of the target DEM file contained in the leaf node. The size of the leaf node, i.e., the minimum node, of the quadtree can be determined by presetting the size of a single target DEM file. The leaf nodes of the quadtree correspond one-to-one with the target DEM files; that is, obtaining data from a leaf node yields data from a target DEM file.

[0047] To ensure good performance in DEM file construction, reading, and storage, while also considering the impact of file format on reading efficiency, in one possible implementation, a quadtree is constructed based on the root node, which can be performed according to the following steps: the root node is split multiple times until the pixel value corresponding to the current split result is less than a given pixel threshold, and the geographic coordinate range corresponding to the current split result is less than a given geographic coordinate threshold; the multiple DEM files to be processed are cut and merged to obtain leaf nodes that correspond one-to-one with the previous split results.

[0048] In this possible implementation, based on practical project experience, the size of a single target DEM file is limited as follows: First, minimum pixel size: the length or width of each target DEM file must be greater than ρ pixels to avoid excessively small files leading to decreased indexing and storage efficiency. Second, minimum geographic range: considering that some target DEM files may be too detailed, the latitude and longitude range of each target DEM file is further set to no less than σ (in degrees). This ensures a reasonable distribution of data in geographic space. The specific minimum node constraint formula is as follows: in, Refers to the pixel width and height of the target DEM file; This refers to the longitude and latitude range covered by the target DEM file.

[0049] In this embodiment, a quadtree data structure can be constructed using pixel constraints and geographic range constraints. It should be noted that the pixel resolution (i.e., the geographic range represented by each pixel) should remain consistent within the same batch of DEM files. If the pixel resolution is inconsistent, standardization processing using methods such as downsampling or linear interpolation is required to ensure consistent pixel resolution. In this embodiment, the quadtree construction is performed under the condition of uniform pixel resolution.

[0050] See Figure 2 The diagram illustrates a quadtree splitting process. Due to the consistent pixel resolution, the minimum node constraint (i.e., the range of a single leaf node) remains consistent across the entire DEM region. Therefore, this quadtree is a regular quadtree where each non-leaf node is uniformly split into four child nodes, as shown in the diagram. Figure 2 As shown.

[0051] exist Figure 2 In the diagram, the largest rectangle represents the root node. The root node splits for the first time, resulting in four child nodes. Each of these four child nodes then splits further, resulting in four child nodes each. At each split, the pixel value of the most recently obtained child node is calculated to be less than a given pixel threshold, and the geographic coordinate range of the most recently obtained child node is calculated to be less than a given geographic coordinate threshold. If both are less than the given thresholds, the child node from the previous split is designated as a leaf node. It should be noted that in this embodiment, the geographic coordinate threshold may include a longitude threshold and a latitude threshold. A geographic coordinate range less than a given geographic coordinate threshold can mean that the difference between the maximum and minimum longitude values ​​is less than a given longitude threshold, and the difference between the maximum and minimum latitude values ​​is less than a given latitude threshold.

[0052] After obtaining the extent of each leaf node, a DEM file for each leaf node is generated. However, the extent of each leaf node may not match the extent of the DEM file to be processed. Therefore, the DEM file needs to be adjusted by raster cutting and merging. The adjusted target DEM file is then mapped one-to-one with the leaf nodes of the quadtree. For example... Figure 3 The diagram illustrates a raster cutting and merging process: the brown solid lines represent the range of the leaf nodes, and the light-colored small squares represent the data in the DEM file to be processed. The DEM file to be processed is cut and merged to obtain the target DEM file corresponding to the leaf nodes. Cutting the DEM file to be processed means cutting the data in the DEM according to the range corresponding to the leaf nodes, and merging the DEM file to be processed means combining the cut results according to the range corresponding to the leaf nodes. Figure 3 In the diagram, the range within the brown solid line box belongs to the range corresponding to the leaf node, and the range within each light-colored cell in the brown solid line box belongs to the data in the DEM file to be processed.

[0053] After the above steps, a complete quadtree index and the corresponding DEM data for each leaf node can be obtained. This is the complete first-level index.

[0054] To avoid excessive fragmentation of the DEM file system, which could negatively impact file system read efficiency, the leaf nodes of the quadtree in the primary index are typically not very small. Each DEM file is generally set between 1GB and 10GB in size, as random reading of files of this size remains highly inefficient. Traditional methods require reading the entire file to retrieve the required data when reading GeoTIFF files, which is inflexible. Therefore, in one possible implementation, a secondary index is created for locating data in the target DEM file. This can be achieved by: dividing the target DEM file into multiple logical blocks and recording the block size and starting position of each logical block; determining the index number of each logical block; and establishing a logical block index table based on the block size, starting position, and index number; and using the logical block index table as the secondary index.

[0055] In this possible implementation, DEM files are typically stored row-by-row. To improve the efficiency of random access to DEM files, considering that random access is always a range read, this embodiment of the application, without changing the original storage structure of the DEM file, uses a logical block approach to logically transform the DEM file into block storage, thereby improving data access speed. See also Figure 4 The diagram illustrates a logical block partitioning process for leaf nodes. The following are the steps for logically partitioning a single DEM data point: exist Figure 4In the diagram, the rectangle containing GeoTIFF represents a leaf node, corresponding to a target DEM file. Logical partitioning is performed on the leaf nodes, dividing the target DEM file into multiple logical blocks. The partitioning process includes: starting from the top left corner, dividing the DEM file into several smaller blocks with sides of α elevation data points. Each smaller block contains α×α elevation data points, forming a logical storage unit. For the right and bottom boundaries of the DEM file, if the remaining elevation data is insufficient to form a complete α×α block, these remaining data are retained, forming an incomplete smaller block. This ensures that all elevation data in the DEM file is contained within logical blocks, preventing data loss.

[0056] Each logic block is assigned a number, i.e., an index number. The logic blocks are distributed in two dimensions, and each logic block uses... express, For line numbers, The column number is used, starting from the top left corner. Preferably, the row and column numbers increment from 0. The primary function of a logic block is to represent the actual position of each block; therefore, a logic block needs to record its block size (length and width) and starting position. Let... For line numbers, For column number, The width of the DEM data, and the formula for calculating the block start position (logical block offset) are as follows: When reading a logical block, the logical block offset is used ( ), logic block width ( ) and logic block height ( These three data points can be used to extract elevation data within a logical block, line by line, and combined into a complete two-dimensional array to represent the elevation data of that logical block. Each block needs to be read. The data is in rows, and the starting position of each row is: in This is the row index within the current logical block (incrementing from 0). The range of each row of data is: .

[0057] After the logical blocks are constructed, a method is needed to quickly access them. In this embodiment, a logical block index table is constructed to meet the requirement of quick location during use. The above steps describe how to read logical blocks using three data points: logical block offset, logical block width, and logical block height. Therefore, the logical block index table only needs to record these three attributes to meet the requirements for accessing logical blocks.

[0058] In the implementation, the logical block index table is represented as an array. The number (index number), offset, and size of each logical block are written into the entries of the logical block index table, supporting fast random access, and the actual storage location can be quickly located. For example... Figure 5 As shown. In Figure 5 In the diagram, (x, y) represents the index number of the logical block, indicating that the logical block is located in the x-th row and y-th column of the target DEM file. The logical block offset is the starting position of the block, used to specifically locate the logical block. The logical block width and logical block height can be used to quickly read the data belonging to the logical block.

[0059] In this embodiment of the application, after constructing the logical block index, when data needs to be read, the geographic coordinates of the user-given area are first converted into elevation data coordinates through the positional relationship, and then the required logical block is located through the logical block index table. The data of a specific area within the logical block is read and merged, so that the required data can be obtained quickly.

[0060] It should be noted that in terrain services that require LOD (Level of Detail), in order to reduce data processing time during subsequent tiling, DEM files of nodes in the primary index at different resolutions can be generated in advance, and secondary indexes can be built.

[0061] In this possible implementation, an index is built for elevation data without altering the primary index of the DEM file. This application embodiment employs a logical block indexing approach, indexing the elevation data within the target DEM file by constructing a logical block index for each leaf node. This application embodiment, combining the steps of quadtrees and logical block decomposition, designs a two-level index-based elevation data search structure, solving the problems of slow and inflexible data reading in existing technologies.

[0062] In one possible implementation, the method may further perform the following steps: in response to receiving an instruction to find data corresponding to a given geographic coordinate range, determining the target DEM file to be queried based on the given geographic coordinate range and the primary index, and obtaining the data in the target DEM file to be queried according to the secondary index.

[0063] In this possible implementation, see Figure 6 The diagram shows a process for generating terrain slices. Figure 6 The leftmost image represents a complete terrain feature. The red rectangle shown is the terrain area of ​​interest to the user, i.e., the slice area. This slice area can be determined by a given geographic coordinate range. Based on the given geographic coordinate range and the primary index, the target DEM file to be queried is determined, i.e., the DEM data slice of the slice area is obtained. Figure 6(The second image from the left in the image), then, according to the secondary index, the data in the target DEM file to be queried can be obtained, and the elevation data of the slice area can be read ( Figure 6 (The third figure from the left in the middle).

[0064] In this step, real-time slicing can be achieved based on the primary and secondary indexes, thereby enabling real-time access and obtaining elevation data at a faster speed.

[0065] During real-time access, the actual geographical area represented by the required slice is calculated based on the slice specification. Data is then read according to the actual geographical area of ​​the slice. However, directly reading data based on the slice area can lead to gaps in the boundary data due to missing adjacent points in subsequent steps. For example... Figure 7 As shown, the left slice has regional feature points on its boundary, while the right slice does not. Figure 7 The grid-like area shown on the right is actually the gap in the final rendered result. Based on this, in one possible implementation, determining the target DEM file to be queried based on the given geographic coordinate range and the primary index can be performed as follows: converting the given geographic coordinate range to an elevation data coordinate range; expanding the elevation data coordinate range along a specified elevation data coordinate direction to obtain an updated elevation data coordinate range; determining the target DEM file that intersects with the updated elevation data coordinate range based on the primary index, thus obtaining the target DEM file to be queried.

[0066] In this possible implementation, the DEM data is organized using a two-level index structure, which makes data retrieval of a specified area more efficient and convenient. Based on this, when determining the target DEM file to be queried according to the given geographic coordinate range and the first-level index, firstly, the given geographic coordinate range is converted into an elevation data coordinate range. The given geographic coordinate conversion range can be used to determine the geographic area of ​​interest to the user, and the elevation data coordinate range can be used to determine the DEM data corresponding to the geographic area of ​​interest to the user within the DEM file.

[0067] This application proposes a two-layer index-based elevation data search structure, which solves the problems of large data reading volume, slow reading speed, and inflexible reading during pre-tiling. It provides a prerequisite for subsequent tiling. Subsequently, a real-time terrain tiling method is provided, which can replace the pre-tiling method used in traditional terrain services.

[0068] To avoid gaps in the boundary data due to missing adjacent points, the elevation data coordinate range can be expanded along a specified elevation data coordinate direction to obtain an updated elevation data coordinate range. This updated range includes the boundary data, ensuring that adjacent points in the boundary data are not missed. The specified elevation data coordinate direction can be set according to actual needs; for example, it can expand outwards in four directions: up, down, left, and right. Figure 8 As shown in the figure, the dashed rectangles represent the coordinate range of elevation data, and the solid rectangles represent the coordinate range of updated elevation data. The solid rectangles are expanded by one data point in each of the four directions (up, down, left, and right) from the dashed rectangles. H in the figure represents one elevation data point. The specific expansion length depends on the amount of data required in that direction when calculating regional feature points at the boundary of the range; in this embodiment, it is one data point. The expansion length can be modified accordingly if the method for calculating regional feature points differs.

[0069] Figure 8 The black solid line box in the middle and Figure 9 The black solid-line box in the leftmost image is the same solid-line box. Figure 8 For example, Figure 8 The rectangles containing the four groups of H can each be used to represent a portion of the data in a leaf node. The leaf node can be determined based on the first-level index, thus determining... Figure 8 After the four leaf nodes, there is an intersection between the leaf nodes and the updated elevation data coordinate range indicated by the black solid line box. Therefore, the target DEM files corresponding to these four leaf nodes are all taken as the target DEM files to be queried.

[0070] like Figure 8 As shown, the dashed box represents the actual slice area, and the solid box represents the overlapping slice area containing the overlapping portion. The area between the two is the overlapping portion. It's important to note that the overlapping portion is only used as auxiliary data for boundary point calculation and does not participate in the calculation of regional feature points. This method effectively ensures the consistency of the elevation values ​​and related calculation results of boundary points in different slices, improving the accuracy and reliability of boundary processing. The data slice area is then expanded using the above method to form a new data slice area.

[0071] In this embodiment, an edge-overlapping tiling method is used instead of traditional interpolation to solve the problem of cracked slice boundaries. This method introduces overlapping portions by taking an additional elevation data point in each of the four directions of the target area when constructing terrain slice region data. These overlapping data points may come from the current file, adjacent files, or invalid data areas. The overlapping portions provide necessary references for calculating the boundary data of the actual slice region, thus ensuring the accuracy of the calculation results. This embodiment uses edge-overlapping tiling instead of traditional interpolation to solve the problem of cracked slice boundaries, which can preserve more terrain information and eliminates the need to repair the current slice boundary from other slices.

[0072] In one possible implementation, retrieving data from the target DEM file to be queried according to the secondary index can be performed by the following steps: retrieving data from the target DEM file to be queried that falls within the range of the elevation data coordinates according to the secondary index.

[0073] In this possible implementation, data within the elevation data coordinate range of the target DEM file to be queried is obtained according to the secondary index. Then, the read data can be merged. In this step, only data within the elevation data coordinate range is read; see [link to relevant documentation]. Figure 8 This allows you to see the black dots within the dashed box (representing data), as well as the black dots covered by the dashed box, preventing data omissions.

[0074] After determining the coordinate range for updating elevation data (i.e., the new data tile area), the required elevation data needs to be retrieved from the elevation data search structure. Specific steps are detailed below. Figure 9 The following explanation is provided: a) Target Node Query: Query the nodes in the quadtree that intersect with the data slice region. b) Read Data Slice: The data slice region may intersect with multiple nodes. Read the intersecting portions from each node using the logical block index table and merge them into a single DEM data set. For example... Figure 9 As shown. c) Read the elevation data of the first channel of the DEM data.

[0075] In one possible implementation, the following steps may also be performed: determining the active feature points of the current level within the elevation data coordinate range; the active feature points include at least regional feature points and regional vertices; and constructing a triangulation network corresponding to the elevation data coordinates based on the active feature points.

[0076] In this possible implementation, determining the active feature points of the current level within the elevation data coordinate range can be performed according to the following steps, in conjunction with... Figure 10 Please provide an explanation.

[0077] like Figure 10 As shown, arrive Indicates Three × three elevation data points centered on the center were used for calculation. Is it a regional feature point? Let's assume... The formula for calculating the regional mean is as follows: set up The height difference threshold for the current level is calculated as follows: Where R is the Earth's radius in meters; q is the terrain quality factor, representing the quality or accuracy of the terrain data. This represents the slice width in pixels. z is the number of slices at scaling level 0; z is the current level.

[0078] It should be noted that the elevation difference threshold is a key parameter determining terrain quality. Multiple reference values ​​can be used, and a more comprehensive approach can be employed to determine it. Factors such as slope, altitude, terrain type, and whether it is an urban or mountainous area can all contribute to its determination.

[0079] By calculating the regional mean and The absolute value of the difference is compared with the height difference threshold, i.e. At that time, it is considered Activated at the current level, also known as a region feature point. In other words, when When the following conditions are met, Activated as regional feature points.

[0080] .

[0081] It should be noted that, in order to improve speed, only eight points around the current point are considered when calculating the mean of the region. In actual implementation, a new definition method can also be considered from the entire data slice area, for example, considering fewer or more points around the current point. This application does not make specific limitations on this.

[0082] In this possible implementation, the activated feature points include at least region feature points and region vertices, see [link to relevant documentation]. Figure 11 The left side of the image represents the state before activation, where each smaller gray dot can represent an elevation data point. The larger gray dots on the right side represent the identified active feature points, which can be used to construct a triangular mesh. Specifically, the larger gray dots at the four corners of the black solid line box represent region vertices, and the remaining larger gray dots represent region feature points. Figure 11This method extracts only the feature points of the actual sliced ​​area; feature points are not extracted from the overlapping parts in the edge-overlapping slicing method. Because it uses non-hierarchical activation, special points require additional processing. Specifically, the four corner vertices of the non-overlapping area are fixedly activated to ensure that the shape of the triangular mesh is consistent with the sliced ​​area, thus guaranteeing that each slice is a regular shape.

[0083] After obtaining all active feature points, these points need to be constructed into a triangular mesh for rendering the terrain skeleton. It should be noted that, unlike pre-tiling which focuses on the entire file's data, real-time tiling in this embodiment is an on-demand tiling method, allowing for the selection of more complex triangulation techniques. In this embodiment, a Delaunay triangular terrain mesh is used. All active feature points are sequentially inserted into the region to ultimately construct the Delaunay triangular terrain mesh. When activating these feature points, the four vertices and points without valid data boundaries are activated as special points, ensuring that the final Delaunay triangular terrain mesh boundary is consistent with the original tile.

[0084] In this possible implementation, the empty circle characteristic and minimum angle maximization characteristic of the Delaunay triangular terrain mesh make the triangular mesh more reasonable, and after comprehensively considering the calculation speed and mesh quality, it is suitable for real-time tiling. In this embodiment, the Delaunay triangular terrain mesh is used instead of the right-angled triangle mesh, making the triangles more flexible. Only triangles constructed from regional feature points are retained, and fewer triangles can be used to represent the same number of regional feature points. This approach is more in line with the characteristics of real-time tiling. When dealing with pre-tiling, processing a large number of regional feature points at once would reduce the efficiency of this approach. Using the Delaunay triangular terrain mesh to construct the mesh reduces the number of triangles and lowers the rendering pressure. In this embodiment, other triangulation methods can also be considered to achieve different meshes, and this embodiment does not specifically limit them.

[0085] In this possible implementation, after obtaining the elevation data for the required data slice range, regional feature points are activated from the data slice based on the elevation data. Unlike the hierarchical activation method of pre-slicing, this embodiment of the application adopts non-hierarchical activation, where the activation state is only valid at the current level. This method can obtain the regional feature points required at the current level while reducing computational complexity.

[0086] Figures 13-16 It displays individual slices in real time. Figures 13 to 16 All data are from the same slice, and the current level is adjusted to achieve LOD (Level of Detail). Figure 13 Constructing a triangular network using traditional grid methods, Figure 14 Using 13 as the current level, calculate the height difference threshold and construct a triangular mesh. Figure 15Using 12 as the current level, calculate the height difference threshold and construct a triangular mesh. Figure 16 Using 12 as the current level and a terrain quality factor of 0.1, calculate the height difference threshold and construct a triangular mesh.

[0087] Figures 17-19 It displays real-time sliced ​​areas. Figure 17 This demonstrates the generation of terrain triangular meshes from DEM data. Figure 18 The effect of overlaying images is shown. Figure 19 This demonstrates the effect of real-time sliced ​​urban terrain under heatmap effect after being fused with other types of data.

[0088] Figure 20 The average request time for 1,000 terrain tile requests under different scenarios is shown. In real-world projects, users will perceive a noticeable performance delay within 200 milliseconds, without any sense of lag. In this embodiment, both high-level and low-level tiling can meet the requirements for real-time loading. During a request, the pre-tiling method only needs to read the pre-generated terrain file, making it faster; the real-time tiling method calculates and constructs the triangulation network in real time. When constructing high-level tiles, a tile will contain the area covered by multiple DEM data, requiring the reading and merging of multiple DEM data, which increases the time consumption. However, with a specially designed elevation data search structure, even at high-level tiling, the time consumption is within an acceptable range for users. Traditional high-level on-demand tiling methods may exceed the request wait time, leading to request timeout errors.

[0089] In one possible implementation, if there is a region without valid data in the target DEM file to be queried, the active feature point of the current level is determined within the elevation data coordinate range. This can be done by the following steps: determining the boundary point of the region without valid data and using the boundary point as the active feature point of the current level.

[0090] In this possible implementation, if there are areas without valid data in the target DEM file to be queried, points among the surrounding points that also have areas without valid data are fixedly activated to preserve the shape of the missing areas. Specifically, the areas without valid data (i.e., Figure 12 The boundary points of the blank area (within the black solid line box on the right) are used as the active feature points of the current level. It should be noted that in the DEM file, areas without valid data will be filled with special values. The values ​​of the special values ​​used can be set according to actual needs, and this application embodiment does not impose specific limitations on this.

[0091] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a DEM file processing apparatus. This apparatus may include: The acquisition module is used to acquire multiple DEM files to be processed; the indexing module is used to establish a primary index for finding target DEM files and a secondary index for finding data in the target DEM files; wherein, the target DEM file is determined based on one or more of the DEM files to be processed.

[0092] This application provides a DEM file processing apparatus, which includes an acquisition module for acquiring multiple DEM files to be processed; and an indexing module for establishing a primary index for finding target DEM files and a secondary index for finding data within the target DEM files; wherein the target DEM file is determined based on one or more of the DEM files to be processed. According to embodiments of this application, instead of merging all DEM files, a two-level indexing strategy is adopted, that is, by establishing primary and secondary indexes, all DEM files and their elevation data are indexed and managed. This approach not only reduces system overhead but also improves data processing efficiency and maintainability.

[0093] In one possible implementation, the indexing module is configured to: determine a root node encompassing the geographic coordinate range corresponding to the plurality of DEM files to be processed; construct a quadtree based on the root node, and use the quadtree as the first-level index; wherein the leaf nodes of the quadtree correspond one-to-one with the target DEM files.

[0094] In one possible implementation, the indexing module is configured to: split the root node multiple times until the pixel value corresponding to the current split result is less than a given pixel threshold, and the geographic coordinate range corresponding to the current split result is less than a given geographic coordinate threshold; and cut and merge the multiple DEM files to be processed to obtain leaf nodes that correspond one-to-one with the previous split result.

[0095] In one possible implementation, the indexing module is configured to: divide the target DEM file into multiple logical blocks, record the block size and starting position of the logical blocks; determine the index number of the logical blocks, determine a logical block index table based on the block size, the starting position of the blocks and the index number; and use the logical block index table as the secondary index.

[0096] In one possible implementation, the device further includes a data module configured to: in response to receiving an instruction to search for data corresponding to a given geographic coordinate range, determine the target DEM file to be queried based on the given geographic coordinate range and the primary index, and obtain the data in the target DEM file to be queried according to the secondary index.

[0097] In one possible implementation, the data module is specifically used to: convert the given geographic coordinate range into an elevation data coordinate range; expand the elevation data coordinate range along a specified elevation data coordinate direction to obtain an updated elevation data coordinate range; and determine, based on the primary index, a target DEM file that intersects with the updated elevation data coordinate range to obtain the target DEM file to be queried.

[0098] In one possible implementation, the data module is specifically used to: retrieve data from the target DEM file to be queried that falls within the range of the elevation data coordinates, according to the secondary index.

[0099] In one possible implementation, the device further includes a construction module for: determining active feature points of the current level within the elevation data coordinate range; the active feature points include at least regional feature points and regional vertices; Based on the activated feature points, construct a triangulation network corresponding to the elevation data coordinates.

[0100] In one possible implementation, if there are regions without valid data in the target DEM file to be queried, the construction module is specifically used to: determine the boundary points of the regions without valid data, and use the boundary points as the active feature points of the current level.

[0101] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0102] Figure 21 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 21 As shown, the electronic device includes a memory 2101 and a processor 2102. The memory 2101 stores a computer program that can run on the processor 2102. When the processor 2102 executes the computer program, it implements the method described in the above embodiments. The number of memories 2101 and processors 2102 can be one or more.

[0103] The electronic device also includes: The communication interface 2103 is used to communicate with external devices and perform data exchange and transmission.

[0104] If the memory 2101, processor 2102, and communication interface 2103 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 21 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0105] Optionally, in a specific implementation, if the memory 2101, processor 2102, and communication interface 2103 are integrated on a single chip, then the memory 2101, processor 2102, and communication interface 2103 can communicate with each other through an internal interface.

[0106] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0107] This application provides a computer program product, wherein the computer program product includes a computer program, which, when executed by a processor, implements the method provided in this application embodiment.

[0108] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0109] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0110] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Computing Machines (ARM) architecture.

[0111] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0112] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0113] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0114] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0115] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0116] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0117] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0118] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0119] Furthermore, the functional units in the various embodiments of this application can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0120] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A DEM file processing method, comprising: Get multiple DEM files to be processed; A primary index for searching a target DEM file is established, and a secondary index for searching data in the target DEM file is established; wherein the target DEM file is determined according to one or more of the DEM files to be processed.

2. The method according to claim 1, wherein: Establish a primary index for finding the target DEM file, including: Determine a root node that includes a geographic coordinate range corresponding to the plurality of DEM files to be processed; A quadtree is constructed based on the root node, and the quadtree is used as the primary index; wherein the leaf nodes of the quadtree correspond one-to-one to the target DEM file.

3. The method according to claim 2, wherein: Constructing a quadtree based on the root node, including: The root node is split multiple times until the pixel value corresponding to the current split result is less than a given pixel threshold, and the geographic coordinate range corresponding to the current split result is less than a given geographic coordinate threshold; The multiple DEM files to be processed are cut and merged to obtain leaf nodes corresponding to the previous splitting results.

4. The method according to claim 1, wherein: Establish a secondary index for searching the data in the target DEM file, including: Divide the target DEM file into a plurality of logical blocks, and record the block size and block start position of the logical blocks; Determine the index number of the logic block, and determine a logic block index table according to the block size, the block start position and the index number; The logic block index table is used as the secondary index.

5. The method according to claim 1, wherein: Also includes: In response to receiving an instruction to search for data corresponding to a given geographic coordinate range, a target DEM file to be queried is determined according to the given geographic coordinate range and the primary index, and data in the target DEM file to be queried is acquired according to the secondary index.

6. The method according to claim 5, wherein: Determining the target DEM file to be queried according to the given geographic coordinate range and the primary index includes: Convert the given geographic coordinates to elevation data coordinates. Expanding the elevation data coordinate range along the specified elevation data coordinate direction to obtain an updated elevation data coordinate range; A target DEM file having an intersection with the updated elevation data coordinate range is determined according to the primary index to obtain a target DEM file to be queried.

7. The method according to claim 6, wherein: Acquiring the data in the target DEM file to be queried according to the secondary index includes: According to the secondary index, the data in the target DEM file to be queried, which is within the coordinate range of the elevation data, is obtained.

8. The method according to claim 6, wherein: Also includes: Determine the activated feature points of the current level within the coordinate range of the elevation data; the activated feature points include at least regional feature points and regional vertices; A triangulated network corresponding to the elevation data coordinates is constructed according to the activated feature points.

9. The method according to claim 8, wherein: When there is an area without valid data in the target DEM file to be queried, determining the activated feature points of the current level within the elevation data coordinate range includes: Determine the boundary points of the area without valid data, and use the boundary points as activation feature points of the current level.

10. An electronic device comprising a memory, a processor and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 9 when executing the computer program.

11. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images