Obstacle data file storage and reading method
By dividing obstacle data files into geographic blocks and adopting a file header, index area, and data area structure, the problems of complex data storage and slow reading in existing technologies are solved, achieving efficient and complete data reading and verification, and improving the data acquisition capabilities of flight safety systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-16
- Publication Date
- 2026-04-03
AI Technical Summary
Existing obstacle data storage formats are complex in structure, have high space occupancy, low read speed, and lack data integrity verification, resulting in untimely and inaccurate acquisition of obstacle data in flight safety systems.
Each obstacle data file adopts a 15′×10′ geographic block structure, which is divided into a file header, an index area, and a data area. The file header contains the creation time, version number, and CRC checksum. The index area describes the size and location of the obstacle, and the data area stores detailed information. Obstacle data is read efficiently through CRC checksum and location information.
It simplifies the data storage structure, improves data retrieval efficiency and reading speed, and ensures the integrity and accuracy of obstacle data.
Smart Images
Figure HDA0005741656000000011 
Figure HDA0005741656000000012 
Figure HDA0005741656000000013
Abstract
Description
Technical Field
[0001] This invention relates to the field of geographic information service technology, specifically to an efficient storage format and reading method for obstacle data files. Background Technology
[0002] As is well known, flight safety is a paramount concern in the aviation industry. Analysis of past flight accidents reveals that insufficient pilot awareness of their surroundings is a major contributing factor, such as controlled flight impacts (CFAs). To improve pilots' environmental awareness and reduce CFA accidents, various solutions have been proposed both domestically and internationally. Among these, environmental awareness and warning systems, runway incursion prevention systems, and ground proximity warning systems have been successfully implemented in various aircraft models with positive results. The application of these technologies relies heavily on obstacle data; therefore, obstacle data is crucial for enhancing aircraft flight safety.
[0003] Both environmental perception and alarm systems and near-field alarm systems require the rapid and accurate acquisition of obstacle data within a designated area. However, existing obstacle data storage formats and reading methods generally suffer from problems such as complex structures, high space consumption, low reading speeds, and a lack of data integrity verification. Therefore, it is necessary to redesign an efficient obstacle data storage format and reading method to improve data reading speeds and ensure data integrity. Summary of the Invention
[0004] The purpose of this invention is to provide a method for storing and retrieving obstacle data files, thereby improving the reading speed of obstacle data and ensuring the integrity and accuracy of the data.
[0005] The objective of this invention is achieved through the following technical solution:
[0006] A method for storing and retrieving obstacle data files, wherein the obstacle data files are stored according to the following structure:
[0007] Each obstacle data file is a 15′ (longitude) × 10′ (latitude) geographic block. The obstacle data file consists of a file header, an index area, and a data area. The file header describes the file creation time, version number, total number of obstacles, and CRC checksum. The index area consists of one or more CELL_HDRs, each describing the size of an obstacle data point and its location within the file. The data area consists of one or more CELL_DATAs, each describing the specific information of an obstacle.
[0008] The method for reading obstacle data files is as follows:
[0009] 1) Read the file header to obtain the file creation time, version number, total number of obstacles, and CRC32 checksum, and verify the data integrity based on the CRC32 checksum;
[0010] 2) Read the index area to obtain the size of each obstacle data in the obstacle data file and its position information in the file;
[0011] 3) Based on the position information read in the previous step, move the file pointer to the corresponding position in the data area, read the corresponding obstacle data, and obtain detailed obstacle information.
[0012] The beneficial effects of this invention are as follows:
[0013] This invention addresses the problems of existing obstacle data storage formats, such as complex structures, high space consumption, low retrieval efficiency, and lack of integrity verification. It designs a simple and efficient obstacle data storage and retrieval method, greatly simplifying the data storage structure and effectively improving data retrieval efficiency and retrieval speed. Furthermore, this invention adds a data verification function, effectively ensuring the integrity and correctness of the obstacle data. Attached Figure Description
[0014] Figure 1 The storage structure of the obstacle data file of the present invention;
[0015] Figure 2 The header format of the obstacle data file of this invention;
[0016] Figure 3 The obstacle data file of this invention is in CELL_HDR format;
[0017] Figure 4 The obstacle data file of this invention is in CELL_DATA format; Detailed Implementation
[0018] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.
[0019] This embodiment illustrates a method for storing and retrieving obstacle data files. See also... Figure 1 As shown, this obstacle data file uses the concept of CELL. One CELL represents one obstacle data within the obstacle data file. An obstacle data file contains one or more CELLs, and the obstacle data is stored in the following structure:
[0020] Each obstacle data file is a 15′ (longitude) × 10′ (latitude) geographic block; each obstacle data file can contain one or more obstacle data, each obstacle data is represented by a data area and stored in binary format;
[0021] The obstacle data file consists of a file header, an index area, and a data area. The file header mainly describes the file creation time, version number, total number of obstacles, and CRC checksum, etc. The index area consists of CELL_HDR (one or more), which mainly describes the size of each obstacle data and its position in the file. The data area consists of CELL_DATA (one or more), which describes the specific information of each obstacle in the file.
[0022] The following sections provide a detailed description of the file header, CELL_HDR, and CELL_DATA contents.
[0023] I. File Header Format Definition
[0024] The file header provides general information about the obstacle file, and its format definition is as follows: Figure 2 As shown, the data file includes five fields: header verification information, data creation date, data version number, number of obstacles, and CRC32 checksum. The header verification information field is of type unsigned int, occupies 4 bytes, and has a fixed constant value used for initial verification. The data creation date field is of type unsigned int, occupies 4 bytes, and describes the specific time (year, month, day) when the data file was created. The data version number field is of type char, occupies 4 bytes, and describes the version of the data file. The number of obstacles field is of type unsigned int, occupies 4 bytes, and describes the total number of obstacles contained in the data file. The CRC32 checksum field is of type unsigned int, occupies 4 bytes, and its value is equal to the CRC32 checksum result of all data except the header information, used to reflect the checksum results of the index area and the data area.
[0025] II. CELL_HDR Format Definition
[0026] CELL_HDR is used to describe the size of each cell data and its location in the file. Its format definition is as follows: Figure 3 As shown, the file includes three fields: Segment ID, Obstacle Data Offset, and Obstacle Data Size. The Segment ID field is of type unsigned long long, occupies 8 bytes, and represents the segment number of the file. The Obstacle Data Size field is of type unsigned int, occupies 4 bytes, and represents the size of the corresponding obstacle information. The Obstacle Data Offset field is of type unsigned long long, occupies 8 bytes, and represents the specific location of the corresponding obstacle data within the file.
[0027] III. CELL_DATA Format Definition
[0028] CELL_DATA is used to describe detailed information about obstacle data, and its format definition is as follows: Figure 4 As shown, the field includes nine fields: obstacle type, obstacle ID, latitude and longitude, highest point altitude, highest point height above ground, length, width, and radius. The obstacle type field is of type unsigned char, occupies 1 byte, and represents the type of obstacle, such as a bridge, windmill, or chimney. The obstacle ID field is of type unsigned int, occupies 4 bytes, and represents the obstacle's code ID. The longitude field is of type double, occupies 8 bytes, and represents the longitude of the obstacle's center point. The latitude field is of type double, occupies 8 bytes, and represents the latitude of the obstacle's center point. The highest point altitude field is of type unsigned int, occupies 4 bytes, and represents the height of the obstacle's highest point. The highest point height above ground field is of type unsigned int, occupies 4 bytes, and represents the height of the obstacle's highest point above the ground. The length field is of type unsigned int, occupies 4 bytes, and represents the length of the obstacle when its outline is rectangular; otherwise, its value is 0. The width field is of type unsigned int and occupies 4 bytes. It represents the width of the obstacle when the obstacle outline is rectangular, and its value is 0 when the outline is not rectangular. The radius field is of type unsigned int and occupies 4 bytes. It represents the radius of the obstacle when the obstacle outline is cylindrical or sphere, and its value is 0 when the outline is not cylindrical or sphere.
[0029] The method for reading obstacle data files is as follows:
[0030] 1) Read the file header to obtain relevant information such as file creation time, version number, total number of obstacles, and CRC32 checksum.
[0031] 2) Read the index area to obtain information such as the size of each obstacle data in the obstacle data file and its specific location in the file.
[0032] 3) Read obstacle data: Based on the position information read in the previous step, move the file pointer to the corresponding position, read the corresponding obstacle data, and obtain detailed obstacle information.
[0033] The obstacle data file structure shown in this embodiment is simple, easy to manage, and easy to implement; it has high data retrieval efficiency and can be read efficiently.
[0034] It is understood that those skilled in the art can make equivalent substitutions or modifications to the technical solution and inventive concept of the present invention, and all such substitutions or modifications should fall within the protection scope of the appended claims.
Claims
1. A method for storing and retrieving obstacle data files, characterized in that the obstacles... Data files are stored in the following structure: Each obstacle data file is a 15′ (longitude) × 10′ (latitude) geographic block. The obstacle data file consists of a file header, an index area, and a data area. The file header describes the file creation time, version number, total number of obstacles, and CRC checksum. The index area consists of one or more CELL_HDRs, each describing the size of an obstacle data point and its location within the file. The data area consists of one or more CELL_DATAs, each describing the specific information of an obstacle. The method for reading obstacle data files is as follows: 1) Read the file header to obtain the file creation time, version number, total number of obstacles, and CRC32 checksum, and verify the data integrity based on the CRC32 checksum; 2) Read the index area to obtain the size of each obstacle data in the obstacle data file and its position information in the file; 3) Based on the position information read in the previous step, move the file pointer to the corresponding position in the data area, read the corresponding obstacle data, and obtain detailed obstacle information.
2. The method for storing and retrieving obstacle data files according to claim 1, characterized in that... The file header includes five fields: header verification information, data creation date, data version number, number of obstacles, and CRC32 checksum. The header verification information field is of type unsigned int, occupies 4 bytes, and has a fixed constant value for initial verification. The data creation date field is of type unsigned int, occupies 4 bytes, and describes the specific time when the data file was created. The data version number field is of type char, occupies 4 bytes, and describes the version of the obstacle data file. The obstacle count field is of type unsigned int, occupies 4 bytes, and is used to describe the total number of obstacles contained in the obstacle data file; the CRC32 checksum field is of type unsigned int, occupies 4 bytes, and its value is equal to the CRC32 checksum result of all data except the file header information, and is used to reflect the checksum results of the index area and the data area.
3. The method for storing and retrieving obstacle data files according to claim 1, characterized in that... CELL_HDR includes three fields: Segment ID, Obstacle Data Offset, and Obstacle Data Size. The Segment ID field is of type unsigned long long, occupies 8 bytes, and represents the segment number of the obstacle data file. The Obstacle Data Size field is of type unsigned int, occupies 4 bytes, and represents the size of the space occupied by the corresponding obstacle information. The Obstacle Data Offset field is of type unsigned long long, occupies 8 bytes, and represents the specific location of the corresponding obstacle data in the file.
4. The method for storing and retrieving obstacle data files according to claim 1, characterized in that... CELL_DATA includes nine fields: obstacle type, obstacle ID, latitude and longitude, highest point altitude, highest point height above ground, length, width, and radius. The obstacle type field is of type unsigned char, occupies 1 byte, and represents the type of obstacle; The obstacle ID field is of type unsigned int, occupies 4 bytes, and represents the obstacle code ID; the longitude field is of type double, occupies 8 bytes, and represents the longitude of the obstacle's center point; the latitude field is of type double, occupies 8 bytes, and represents the latitude of the obstacle's center point; the highest point altitude field is of type unsigned int, occupies 4 bytes, and represents the height value of the highest point of the obstacle; the highest point height above ground field is of type unsigned int, occupies 4 bytes, and represents the height value of the highest point of the obstacle above the ground; the length field is of type unsigned int, occupies 4 bytes, and represents the length of the obstacle when the obstacle outline is rectangular, and has a value of 0 when the outline is not rectangular; the width field is of type unsigned int, occupies 4 bytes, and represents the width of the obstacle when the obstacle outline is rectangular, and has a value of 0 when the outline is not rectangular; the radius field is of type unsigned int, occupies 4 bytes, and represents the radius of the obstacle when the outline is cylindrical or sphere, and has a value of 0 when the outline is not cylindrical or sphere.