A method for structuring storage of terrain data based on multi-level grid addressing

By using a multi-level grid addressing method to perform two-level mapping and BLOB field storage within a single database table, the problems of storage complexity and low maintenance efficiency caused by traditional sharding strategies are solved. This achieves efficient data organization and retrieval, supports smooth expansion of multi-resolution data, and reduces system operation and maintenance costs.

CN122332391APending Publication Date: 2026-07-03崂山国家实验室
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
崂山国家实验室
Filing Date
2026-06-02
Publication Date
2026-07-03

AI Technical Summary

Technical Problem

Traditional horizontal sharding strategies result in complex storage structures, low data maintenance and update efficiency, poor multi-resolution scalability, and high system operation and maintenance costs when storing massive amounts of global raster terrain data, and cannot effectively maintain the spatial continuity of data.

Method used

A multi-level grid addressing method is adopted to perform two-level mapping of global regular grid terrain data in a single database table, use BLOB fields for micro-partition storage, and accelerate retrieval through B+ tree index, thereby achieving efficient data organization and retrieval.

Benefits of technology

It enables efficient storage and rapid retrieval of massive, high-resolution global raster terrain data, simplifies the topology, reduces maintenance and update complexity, and supports smooth expansion of multi-source, multi-resolution data, thereby reducing system expansion costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122332391A_ABST
    Figure CN122332391A_ABST
Patent Text Reader

Abstract

This invention belongs to the interdisciplinary field of geographic information systems, spatial databases, and big data storage technology. Specifically, it discloses a structured storage method for terrain data based on multi-level grid addressing. This invention designs an innovative database table structure, mapping the two-dimensional row and column indexes of global regular grid terrain data to the database's primary key index and secondary longitude interval fields, and uses binary large object (BLOB) fields for compressed storage. This method achieves efficient organization of massive, high-resolution global raster terrain data within a single database table, achieving high retrieval efficiency, simple topology, convenient maintenance and updates, and easy integration of multi-source, multi-resolution data, fundamentally overcoming the drawbacks of traditional fragmentation methods.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of Geographic Information System (GIS), spatial database and big data storage technology, and specifically relates to a method for structured storage of terrain data based on multi-level grid addressing. Background Technology

[0002] With advancements in global observation technologies, high-resolution Earth science datasets (such as the GEBCO global seafloor topography data) have reached billions of raster cells (e.g., 3.7 billion cells in GEBCO_2025). In modern web and enterprise application architectures, incorporating such data into relational databases for centralized management helps achieve data access control, transaction consistency, and complex structured queries. Currently, the industry's conventional approach to handling massive raster data imports is to employ a horizontal sharding strategy, which involves distributing the data through database sharding, partitioning, and table partitioning.

[0003] However, this horizontal tiling strategy has the following significant drawbacks when dealing with global regular grid terrain data: 1. Increased storage complexity: Physically dispersed data leads to complex cross-node join query logic, disrupting the spatial continuity of data; 2. Low maintenance and update efficiency: Adding, deleting, and modifying large-scale data requires traversing multiple shards, resulting in long links, difficult concurrency control, and high time consumption; 3. Difficult multi-resolution expansion: Each additional resolution of data requires doubling the sharded storage structure, drastically increasing metadata management and migration costs; 4. High overall operation and maintenance costs: Dispersed models and complex update mechanisms significantly increase the difficulty and cost of development, testing, operation and maintenance, and full lifecycle management.

[0004] It is evident that traditional horizontal sharding strategies, when storing massive amounts of global raster terrain data (especially raster datasets with billions of data points such as GEBCO_2025) in relational databases, can easily lead to problems such as complex storage structures, low data maintenance and update efficiency, poor scalability of multi-resolution data, and high overall system operation and maintenance costs. The root cause is that traditional horizontal sharding disrupts the inherent logic of the spatial continuity of global grid data and cannot efficiently map its regular two-dimensional matrix structure at the database level.

[0005] Therefore, there is an urgent need for a terrain database storage method that can maintain a simple data spatial topology, support efficient retrieval and convenient maintenance, and can be smoothly expanded to meet the needs of multi-source and multi-resolution data.

[0006] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art. Summary of the Invention

[0007] The purpose of this invention is to propose a structured storage method for terrain data based on multi-level grid addressing, which aims to achieve efficient organization and storage of massive, high-resolution global raster terrain data within a single database table. It features high retrieval efficiency, simple topology, convenient maintenance and updates, and easy integration of multi-source and multi-resolution data.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: A method for structured storage of terrain data based on multi-level grid addressing includes the following steps: Step 1. Create a database table and set indexes and data fields; Let the dimension of the global regular grid terrain data be . ,in represents the number of rows, Represents the number of columns; The table fields are designed as follows: Define an Index field to store the latitude row index, with an index range from 1 to... And serve as a first-level addressing index; The longitude interval [-180, 180] is divided into... There are 10 equal fields, each corresponding to a longitude interval, used to store all terrain data of the latitude row within the corresponding longitude interval, and as a secondary addressing structure; The topographic data includes water depth or elevation values; Step 2. Data writing and organization; Step 2.1. Data preparation; Read global regular grid terrain data; Step 2.2. Row direction mapping; Traverse each latitude row from the global regular grid terrain data, with the Index field directly recording the latitude row number; Step 2.3. Column-to-column reorganization; For each latitude row, the corresponding... The topographic data is divided into sections from -180° to 180° in longitude order. A series of consecutive blocks, each containing One data point; Step 2.4. Binary storage; The system uses BLOB fields for storage, with each BLOB field storing the longitude range within its corresponding interval. A continuous binary stream of terrain data to enable micro-partitioning of data within the database record; Step 2.5. Index creation; After the data is written, a primary key and a B+ tree index are created on the Index field to accelerate retrieval based on latitude rows.

[0009] Furthermore, based on the aforementioned structured storage method for terrain data based on multi-level grid addressing, this invention also proposes a database that includes multiple database tables.

[0010] Each database table was obtained using the aforementioned terrain data structured storage method based on multi-level grid addressing.

[0011] Furthermore, based on the aforementioned database, this invention also proposes a terrain data query method based on multi-level grid addressing, which adopts the following technical solution: A terrain data query method based on multi-level grid addressing includes the following steps: Step 3.1. Receive a latitude and longitude coordinate point input by the user to query terrain data; this latitude and longitude coordinate point is used as the target data point, and its coordinates are (Lon, Lat), where Lon represents the longitude coordinate and Lat represents the latitude coordinate; Step 3.2. Perform primary and secondary addressing from the database table based on the latitude and longitude coordinates of the target data points; Step 3.2.1. Level 1 addressing, used to determine the row; Based on the latitude Lat, the corresponding row record is located in the Index using a formula; Step 3.2.2. Second-level addressing, used to determine the field and offset; First, determine the longitude interval to which the longitude Lon belongs, and then select the corresponding BLOB field; Then, within the longitude interval corresponding to the longitude Lon, calculate the offset ratio of Lon relative to the starting point of its longitude interval, and determine the byte offset of the target data point in the BLOB field by direct calculation. Step 3.3. Data Extraction; From the selected BLOB field, a fixed length of bytes is read according to the byte offset from the start position of the BLOB field to the target data point, and after decoding, the terrain data of the target data point is obtained.

[0012] Furthermore, based on the aforementioned method for structured storage of terrain data based on multi-level grid addressing, this invention also proposes a computer device comprising a memory and one or more processors.

[0013] Executable code is stored in memory. When the processor executes the executable code, it implements the steps of the above-described method for structuring and storing terrain data based on multi-level grid addressing.

[0014] Furthermore, based on the above-mentioned terrain data structured storage method based on multi-level grid addressing, this invention also proposes a computer-readable storage medium storing a program thereon, which, when executed by a processor, is used to implement the steps of the above-mentioned terrain data structured storage method based on multi-level grid addressing.

[0015] The present invention has the following advantages: As described above, this invention proposes a method for efficient, structured storage and fast retrieval of massive, high-resolution global raster terrain data (such as seabed topography and land elevation data) in a relational database. This method employs an innovative database table structure, mapping the two-dimensional row and column indexes of the global regular grid terrain data to the database's primary key index and secondary longitude interval fields, and utilizing binary large object (BLOB) fields for compressed storage. This method achieves efficient organization of massive, high-resolution global raster terrain data within a single database table, achieving high retrieval efficiency, simple topology, convenient maintenance and updates, and easy integration of multi-source, multi-resolution data, fundamentally overcoming the drawbacks of traditional sharding methods. Specifically, in terms of retrieval efficiency, B+ tree indexes are used to quickly locate rows, and then data within BLOBs is searched in memory, avoiding complex join queries across multiple tables / shards, resulting in shorter query paths and faster response times. Regarding topology, the entire global dataset is stored in a single table, with a clear table structure. Spatial adjacency relationships between data are preserved through row and column mapping, greatly simplifying the data model and access logic. Regarding maintenance and updates, only a single record needs to be operated on when updating or inserting a row of data. Batch updates can also be processed row by row, simplifying the logic, facilitating transaction control, and significantly improving maintenance efficiency. For easy expansion with multi-source data, when adding terrain data from different sources or at different resolutions, only a new database table with the same structure needs to be created. Metadata management is simple, and it does not cause entropy increase in the original system structure, reducing the complexity and cost of system expansion. Furthermore, this invention also optimizes storage overhead. By using BLOBs to store continuous data, compared to creating a record for each raster point, table metadata overhead is significantly reduced, effectively improving storage density. Attached Figure Description

[0016] Figure 1 This is a flowchart of the terrain data structured storage method based on multi-level grid addressing in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of database table mapping in Embodiment 1 of the present invention; Figure 3 This is a flowchart of the terrain data query method based on multi-level grid addressing in Embodiment 3 of the present invention. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: Example 1 This embodiment describes a structured storage method for terrain data based on multi-level grid addressing, which is used to perform two-level mapping and reorganization of global regular grid terrain data and store it in a single database table.

[0018] like Figure 1 As shown, the structured storage method for terrain data based on multi-level grid addressing includes the following steps: Step 1. Database table structure design First, create the database table, then set the indexes and data fields.

[0019] Let the dimension of the global regular grid terrain data be . ,in represents the number of rows, This represents the number of columns. A detailed explanation is provided using GEBCO_2025 data (43200 rows × 86400 columns). , ,like Figure 2 As shown.

[0020] First, create a database table, for example, named Gebco_2025_15arc_second.

[0021] The table field design is as follows (using MySQL as an example): Define an Index field to store the latitude row index, with an index range from 1 to... And it serves as the first-level addressing index.

[0022] The longitude interval [-180, 180] is divided into... There are 10 equal fields, each corresponding to a longitude interval, used to store all terrain data of the latitude row within the corresponding longitude interval, and used as a secondary addressing structure.

[0023] In this embodiment, the terrain data specifically refers to water depth or elevation values.

[0024] In this embodiment, the number of fields divided It is a factor of 360 degrees, and .

[0025] by Taking this as an example, the longitude range of [-180°, 180°] will be divided into 9 equal fields, each field corresponding to a longitude range of 40 degrees, covering a total longitude of -180 to 180 degrees.

[0026] The nine longitude intervals corresponding to each field are: [-180°, -140°), [-140°, -100°), [-100°, -60°), [-60°, -20°), [-20°, -20°), [20°, 60°), [60°, 100°), [100°, 140°), [140°, 180°).

[0027] Each field corresponds to storing all terrain data within a given longitude interval.

[0028] Step 2. Data writing and organization.

[0029] Step 2.1. Data preparation.

[0030] Read global regular grid terrain data, in formats such as NetCDF.

[0031] Step 2.2. Row mapping.

[0032] Traverse each latitude row from the global regular grid terrain data (total) (Row), the Index field directly records the latitude row number.

[0033] Step 2.3. Column-to-column reorganization.

[0034] For each latitude row, the corresponding... The topographic data is divided into sections from -180° to 180° in longitude order. A series of consecutive blocks, each containing Data points.

[0035] Taking the GEBCO_2025 data as an example, for each latitude row, its 86,400 columns of data are divided into 9 consecutive blocks in longitude order, with each block containing 9,600 data points.

[0036] The data of the first block (longitude range [-180°, -140°)) is serialized and stored in the first field, the data of the second block (longitude range [-140°, -100°)) is serialized and stored in the second field, and so on.

[0037] Step 2.4. Binary storage.

[0038] The system uses BLOB fields for storage, with each BLOB field storing the longitude range within its corresponding interval. A continuous binary stream of 9600 water depth values ​​is used to achieve micro-partitioning of data within the database record.

[0039] Step 2.5. Index creation.

[0040] After the data is written, a primary key and a B+ tree index are created on the Index field to accelerate retrieval based on latitude rows.

[0041] The above scheme divides longitude into nine 40-degree intervals. Of course, the granularity of the longitude interval division can be replaced.

[0042] For example, based on the distribution of data access hotspots or performance tests, the granularity of the division can be adjusted to finer (e.g., 24 15-degree intervals) or coarser (e.g., 4 90-degree intervals) to optimize the balance between single-field BLOB size and query efficiency.

[0043] This invention targets multi-source, multi-resolution data. For each resolution data under each data source, a new database table is created separately. Steps 1 and 2 above are repeated to achieve separate storage of terrain data under various resolution data.

[0044] The above design facilitates the expansion of multi-source, multi-resolution data.

[0045] For data with different resolutions, a new database table (such as Gebco_2025_30arc_second) can be created using the same principle.

[0046] Because each database table has a clear and independent structure, managing multi-resolution data only requires increasing the number of database tables, without complicating the original database table structure or causing an explosive increase in the number of shards, resulting in excellent scalability.

[0047] Compared with traditional fragmentation methods, the present invention has at least the following advantages: (1) A two-level mapping model of "row index + longitude interval field": The continuous spatial structure of a global two-dimensional grid is innovatively mapped to a one-dimensional primary key index and a limited number of secondary BLOB fields in a relational database, achieving logical data partitioning while maintaining a simple single-table structure.

[0048] (2) Micro-partitioning storage based on BLOB fields: By storing massive amounts of data points within the same latitude row and continuous longitude range as a whole into a single BLOB, and using the database's native types to manage large data blocks, the huge overhead and performance bottlenecks caused by creating a record for each data point are avoided.

[0049] (3) Linear scaling architecture for multi-resolution data: Each resolution of data corresponds to an independent but structurally identical database table. This means that when the system expands to new resolution data, only the database table entity is added, without increasing the architectural complexity, and the operation and maintenance costs increase linearly.

[0050] Example 2 This embodiment 2 describes a database comprising multiple database tables. Each database table only needs to store global regular grid terrain data of a specific resolution.

[0051] Because each database table has a clear and independent structure, managing multi-resolution data only requires increasing the number of database tables, without complicating the original database table structure or causing an explosive increase in the number of shards, resulting in excellent scalability.

[0052] Each database table was obtained using the aforementioned terrain data structured storage method based on multi-level grid addressing.

[0053] Example 3 This embodiment 3 describes a terrain data query method based on multi-level grid addressing, which is used to query the water depth value at the corresponding latitude and longitude coordinate point from the database table in the above embodiment 2.

[0054] like Figure 3 As shown, the terrain data query method based on multi-level grid addressing in this embodiment includes the following steps: Step 3.1. Receive a latitude and longitude coordinate point from the user to query the water depth value; this latitude and longitude coordinate point is used as the target data point, and its coordinates are (Lon, Lat), where Lon represents the longitude coordinate and Lat represents the latitude coordinate.

[0055] Step 3.2. Perform primary and secondary addressing from the database table based on the latitude and longitude coordinates of the target data point.

[0056] Step 3.2.1. Level 1 addressing, used to determine the row.

[0057] Based on the latitude (Lat), the corresponding row record is located in the Index using a formula.

[0058] The first-level addressing process is as follows: According to latitude The following methods can be used to quickly locate the corresponding row record on the Index.

[0059] Let the latitudinal range of the global regular grid terrain data be... The number of rows in the global regular grid terrain data is The formula for calculating the row index is: .

[0060] in, The floor function is the function that rounds down to the nearest integer. This is the row index value corresponding to this latitude. Indicates the lower limit of the latitude range. This indicates the upper limit of the latitude range.

[0061] Taking GEBCO_2025 data as an example, assuming the latitude range is... ,Right now Total number of lines Query latitude ,but: .

[0062] That is, the query dimension This corresponds to record number 28920.

[0063] Step 3.2.2. Second-level addressing, used to determine the field and offset.

[0064] First, determine the longitude interval (e.g., [100, 140)) based on the longitude Lon, and then select the corresponding BLOB field.

[0065] Then, within the longitude interval corresponding to the longitude Lon (e.g., [100, 140)), calculate the offset ratio of Lon relative to the starting point of its longitude interval, and directly calculate and determine the byte offset of the target data point in the BLOB field.

[0066] The two-level addressing process is as follows: First, determine the longitude interval to which the longitude Lon belongs. This longitude interval corresponds one-to-one with the defined BLOB field. Each longitude interval corresponds to one BLOB field, thus selecting the corresponding BLOB field.

[0067] For example, the 8th field stores all terrain data within the longitude range of [100°, 140°).

[0068] Then, within the longitude interval [100°, 140°), the offset ratio of longitude Lon relative to the starting point of its longitude interval is calculated, thereby determining the byte offset of the target data point in the BLOB field.

[0069] Set longitude The longitude range is The total number of data points within the interval is The offset ratio is: .

[0070] in This is the offset ratio. , They are respectively The start and end points of the longitude interval; based on the offset ratio. The formula for calculating the byte offset of the target data point in the BLOB field is as follows: .

[0071] in This is the byte offset from the start of the BLOB field to the target data point. The number of bytes occupied by a single water depth value. .

[0072] The final calculated result, i.e., the byte offset, is an integer, and the unit is bytes.

[0073] Assuming the longitude interval is Total number of data points within the interval A single water depth value occupies 4 characters ( ), query longitude ,but: .

[0074] That is, the byte offset of the target data point in the BLOB binary stream is 14400 bytes.

[0075] Step 3.3. Data extraction.

[0076] From the selected BLOB field, a fixed length of bytes is read according to the byte offset from the start position of the BLOB field to the target data point, and after decoding, the water depth value of the target data point is obtained.

[0077] Specifically, offset from the starting position of the selected BLOB field. Starting from the position, the reading length is... The byte sequence is decoded into a floating-point number or an integer to obtain the water depth value of the target data point.

[0078] During a query, this invention applies formulas to calculate the water depth value from latitude and longitude coordinates in both the row index (B+ tree) and the internal data stream of the BLOB (ordered array), achieving sub-second-level rapid positioning.

[0079] Example 4 This embodiment 4 describes a computer device including a memory and one or more processors. Executable code is stored in the memory. When the processor executes the executable code, it implements the steps of the terrain data structured storage method based on multi-level grid addressing described in embodiment 1 above.

[0080] In this embodiment, the computer device can be any device or apparatus with data processing capabilities, and will not be described in detail here.

[0081] Example 5 This embodiment 5 describes a computer-readable storage medium storing a program thereon, which, when executed by a processor, is used to implement the steps of the terrain data structured storage method based on multi-level grid addressing in embodiment 1 above.

[0082] The computer-readable storage medium can be an internal storage unit of any device or apparatus with data processing capabilities, such as a hard disk or memory, or an external storage device of any device with data processing capabilities, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc.

[0083] Of course, the above description is only a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. It should be noted that any equivalent substitutions or obvious modifications made by those skilled in the art under the guidance of this specification fall within the scope of this specification and should be protected by the present invention.

Claims

1. A method for structuring storage of terrain data based on multi-level grid addressing, characterized by, Includes the following steps: Step 1. Create a database table and set indexes and data fields; Let the dimension of the global rule grid terrain data be wherein represents the number of rows, represents the number of columns; The table fields are designed as follows: Define Index field to store the latitude row index, whose index range is from 1 to and as a primary addressing index; The longitude interval of [-180, 180] is divided into equal fields, each field corresponding to a longitude interval, for storing all terrain data of the latitude row in the corresponding longitude interval, and serving as a secondary addressing structure; The topographic data includes water depth or elevation values; Step 2. Data writing and organization; Step 2.

1. Data preparation; Read global regular grid terrain data; Step 2.

2. Row direction mapping; Traverse each latitude row from the global regular grid terrain data, with the Index field directly recording the latitude row number; Step 2.

3. Column-to-column reorganization; For each latitude row, the corresponding... The topographic data is divided into sections from -180° to 180° in longitude order. A series of consecutive blocks, each containing One data point; Step 2.

4. Binary storage; The system uses BLOB fields for storage, with each BLOB field storing the longitude range within its corresponding interval. A continuous binary stream of terrain data to enable micro-partitioning of data within the database record; Step 2.

5. Index creation; After the data is written, a primary key and a B+ tree index are created on the Index field to accelerate retrieval based on latitude rows.

2. The method for structured storage of terrain data based on multi-level grid addressing according to claim 1, characterized in that, In step 1, the number of fields divided It is a factor of 360 degrees, and .

3. The method for structured storage of terrain data based on multi-level grid addressing according to claim 1, characterized in that, For multi-source, multi-resolution data, a new database table is created for each resolution data under each data source. Steps 1 and 2 above are repeated to achieve separate storage of terrain data under various resolution data.

4. A database comprising multiple database tables, characterized in that, Each database table is obtained using the terrain data structured storage method based on multi-level grid addressing as described in any one of claims 1 to 3.

5. A terrain data query method based on multi-level grid addressing, wherein the query is performed on the database as described in claim 4; characterized in that, The terrain data query method based on multi-level grid addressing includes the following steps: Step 3.

1. Receive a latitude and longitude coordinate point input by the user to query terrain data; this latitude and longitude coordinate point is used as the target data point, and its coordinates are (Lon, Lat), where Lon represents the longitude coordinate and Lat represents the latitude coordinate; Step 3.

2. Perform primary and secondary addressing from the database table based on the latitude and longitude coordinates of the target data points; Step 3.2.

1. Level 1 addressing, used to determine the row; Based on the latitude Lat, the corresponding row record is located in the Index using a formula; Step 3.2.

2. Second-level addressing, used to determine the field and offset; First, determine the longitude interval to which the longitude Lon belongs, and then select the corresponding BLOB field; Then, within the longitude interval corresponding to the longitude Lon, calculate the offset ratio of Lon relative to the starting point of its longitude interval, and determine the byte offset of the target data point in the BLOB field by direct calculation. Step 3.

3. Data extraction; From the selected BLOB field, a fixed length of bytes is read according to the byte offset from the start position of the BLOB field to the target data point, and after decoding, the terrain data of the target data point is obtained.

6. The terrain data query method based on multi-level grid addressing according to claim 5, characterized in that, In step 3.2.1, the first-level addressing process is as follows: According to latitude The corresponding row record can be quickly located on the Index using the following methods; Let the latitudinal range of the global regular grid terrain data be... The number of rows in the global regular grid terrain data is The formula for calculating the row index is: ; in, The floor function is the function that rounds down to the nearest integer. This is the row index value corresponding to this latitude. Indicates the lower limit of the latitude range. This indicates the upper limit of the latitude range.

7. The terrain data query method based on multi-level grid addressing according to claim 5, characterized in that, In step 3.2.2, the second-level addressing process is as follows: First, determine the longitude interval to which it belongs based on the longitude Lon. This longitude interval corresponds one-to-one with the defined BLOB field. Each longitude interval corresponds to one BLOB field, thereby selecting the corresponding BLOB field. Then, within this longitude interval, the offset ratio of longitude Lon relative to the starting point of its longitude interval is calculated, thereby determining the byte offset of the target data point in the BLOB field; Set longitude The longitude range is The total number of data points within the interval is The offset ratio is: ; in This is the offset ratio. , They are respectively The start and end points of the longitude interval; based on the offset ratio. The formula for calculating the byte offset of the target data point in the BLOB field is as follows: ; in This is the byte offset from the start of the BLOB field to the target data point. The number of bytes occupied by a single terrain data point. .

8. The terrain data query method based on multi-level grid addressing according to claim 5, characterized in that, In step 3.3, the data extraction process is as follows: Offset from the start position of the selected BLOB field Starting from the position, the reading length is... The byte sequence is decoded into a floating-point number or an integer to obtain the terrain data of the target data point.

9. A computer device, comprising a memory and one or more processors; characterized in that, The memory stores executable code, which, when executed by the processor, is used to implement the terrain data structured storage method based on multi-level grid addressing as described in any one of claims 1 to 3.

10. A computer-readable storage medium having a program stored thereon; characterized in that, When executed by a processor, the program is used to implement the terrain data structured storage method based on multi-level grid addressing as described in any one of claims 1 to 3.