Oblique photography model piecewise storage and fast visibility analysis method, system and medium

Abstract

This application relates to the field of geographic information data processing technology, and discloses a method, system, and medium for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models. The method includes: extracting the three-dimensional coordinates of sampling points from oblique photogrammetry model tile files; calculating the spatial grid index of each sampling point based on latitude and longitude, and storing sampling point data belonging to the same index as a segment in a time-series database; obtaining the coordinates of the observation point and the target point and calculating the line segment connecting them, obtaining multiple interpolation points through linear interpolation of the line segment; calculating the spatial grid index of each interpolation point, locating the corresponding data segment in the time-series database, and quickly obtaining the surface elevation of that point; and determining whether the two points are line-of-sight by comparing the elevations of all interpolation points with the corresponding surface elevations. The system and medium correspond to this method. This application achieves efficient management and rapid line-of-sight analysis of oblique photogrammetry models through data reorganization and index optimization.

Description

Technical Field

[0001] This application relates to the field of geographic information data processing technology, specifically a method, system, and medium for oblique photogrammetry model segmentation storage and rapid line-of-sight analysis. Background Technology

[0002] Oblique photogrammetry models serve as a crucial digital foundation for 3D spatial analysis in fields such as smart mines and smart cities. In scenarios like drone inspection route planning, it's often necessary to determine whether waypoints and ground stations are line-of-sight. Currently, this analysis relies on two main methods: one is using specialized desktop GIS software, which requires loading the complete oblique photogrammetry model file locally. This method is complex, dependent on high-performance hardware, and difficult to integrate with web applications. The other is using APIs from web 3D engines (such as Cesium). While easier to integrate, the calculation process still requires loading and processing large-scale 3D tile data in the browser. Limited by client performance, this results in slow response times and interface lag when facing numerous analysis requests. The common bottleneck of these two existing methods is that their line-of-sight analysis process directly reads and calculates data from massive, complete oblique photogrammetry model files. They fail to optimize data storage and retrieval for the core operation of "frequently querying corresponding surface elevations using latitude and longitude coordinates" in line-of-sight analysis, leading to low data I / O efficiency. This becomes a key technical obstacle to achieving real-time, rapid line-of-sight analysis services on the web. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, system, and medium for sliced ​​storage and rapid view-through analysis of oblique photogrammetry models that can improve analysis speed and response efficiency, in order to address the aforementioned technical problems.

[0004] On the one hand, this application provides a method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models, which includes the following steps: Extract the 3D coordinates of sampling points from the tile file of the oblique photogrammetry model; Calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point; Sampling point data belonging to the same spatial grid index are stored as a single piece in the time series database; Obtain the three-dimensional coordinates of observation point A and target point B, and calculate the line segment AB connecting observation point A and target point B based on the three-dimensional coordinates; Linear interpolation is performed on the line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point; For each interpolation point, the spatial grid index to which it belongs is calculated based on its latitude and longitude coordinates. The corresponding data segment in the time series database is located based on the spatial grid index, and the surface elevation corresponding to the interpolation point is obtained by querying the spatial range in the located data segment. The elevation of each interpolation point is compared with its corresponding ground elevation. When the elevation of all interpolation points is greater than their corresponding ground elevation, it is determined that the observation point A and the target point B are in line with each other.

[0005] In one embodiment, calculating the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point includes: Based on the preset origin of the plane coordinate system and the grid side length, calculate the column number and row number corresponding to the latitude and longitude coordinates of the sampling point in the plane coordinate system; The calculated column number and row number are formatted and concatenated to generate the spatial grid index.

[0006] In one embodiment, the step of formatting and concatenating the calculated column number and row number includes: Format the column number and the row number into a fixed-length numeric string; The formatted numeric string is concatenated with a preset prefix string to generate the spatial grid index.

[0007] In one embodiment, obtaining the surface elevation corresponding to the interpolation point by spatial range querying within the located data segment includes: A square query range is constructed with the latitude and longitude coordinates of the interpolation point as the center; Generate and execute a Structured Query Language (SQL) statement to query model sampling points whose latitude and longitude coordinates fall within the square query range in the data shard, and determine the surface elevation corresponding to the interpolation point based on the query results.

[0008] In one embodiment, constructing a square query range includes: Centered on the latitude and longitude coordinates of the interpolation point, extend upwards and downwards by a preset fixed buffer distance to form the boundary of the square query range.

[0009] In one embodiment, determining that the observation point A and the target point B are in sight when the elevation of all interpolation points is greater than their corresponding surface elevation includes: Iterate through all interpolation points in sequence; If the elevation of any interpolation point is less than or equal to its corresponding ground elevation, the traversal is terminated and it is determined that the observation point A and the target point B are not in sight. If all interpolation points have been traversed and the elevation of all interpolation points is greater than the corresponding ground elevation, then it is determined that the observation point A and the target point B are in line of sight.

[0010] In one embodiment, the linear interpolation of the line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point includes: Based on the three-dimensional coordinates of the observation point A and the target point B, determine the parametric equation of the line segment AB; Based on the preset interpolation step size, multiple parameter values ​​are selected at equal intervals within the parameter domain; Substitute each parameter value into the parameter equation to calculate the three-dimensional coordinates of the corresponding interpolation point.

[0011] In one embodiment, extracting the three-dimensional coordinates of the sampling points from the tile file of the oblique photogrammetry model includes: Read the tile files of the oblique photogrammetry model; The tile file is parsed to extract the longitude, latitude, and elevation coordinates of multiple sampling points recorded therein.

[0012] On the other hand, this application provides a system for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models, which applies the oblique photogrammetry model segmented storage and rapid line-of-sight analysis method described above. The system includes: The data extraction unit is configured to extract the three-dimensional coordinates of sampling points from the tile file of the oblique photogrammetry model; The index calculation unit is configured to calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point. The sharded storage unit is configured to store sample point data belonging to the same spatial grid index as a shard in the time series database; The line segment calculation unit is configured to obtain the three-dimensional coordinates of the observation point A and the target point B, and calculate the line segment AB connecting the observation point A and the target point B based on the three-dimensional coordinates. A linear interpolation unit is configured to perform linear interpolation on the line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point; The elevation query unit is configured to calculate the spatial grid index to which each interpolation point belongs based on its latitude and longitude coordinates, locate the corresponding data segment in the time series database based on the spatial grid index, and obtain the surface elevation corresponding to the interpolation point by querying the spatial range in the located data segment. The visibility judgment unit is configured to compare the elevation of each interpolation point with its corresponding ground elevation, and determine that the observation point A and the target point B are visible to each other when the elevation of all interpolation points is greater than their corresponding ground elevation.

[0013] In another aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the oblique photogrammetry model segmentation storage and fast line-of-sight analysis method as described in any of the preceding embodiments.

[0014] The aforementioned method, system, and medium for oblique photogrammetry model segmentation and rapid line-of-sight analysis constructs an efficient spatial grid index by dividing the sampling point data of the oblique photogrammetry model into grids based on their spatial location and storing them in a time-series database. This allows for the rapid location of the required data segments directly based on the interpolation point positions during subsequent line-of-sight analysis, and the quick acquisition of accurate surface elevations through optimized spatial range queries. This method optimizes the data storage structure, avoiding the overhead of loading and traversing the entire or large amounts of model data required in traditional methods. It transforms computationally intensive elevation queries into efficient database index queries, thereby reducing data retrieval time and system resource consumption. This enables distributed, high-concurrency line-of-sight analysis between two points in a short time (e.g., sub-second) in a typical web server environment, improving analysis speed and response efficiency. Attached Figure Description

[0015] Figure 1 A flowchart illustrating the method for sliced ​​storage and rapid line-of-sight analysis of oblique photogrammetry models provided in this application embodiment; Figure 2 This is a structural block diagram of the oblique photogrammetry model segmentation storage and rapid line-of-sight analysis system provided in the embodiments of this application. Detailed Implementation

[0016] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0017] Oblique photogrammetry models, due to their high realism and accurate geographic coordinate information, have become an important digital foundation for 3D spatial analysis and application development on the web in fields such as smart mines and smart cities. Taking automated drone inspection in smart mines as an example, when planning drone routes, it is essential to ensure that the communication link between each waypoint on the route and the ground airport is not obstructed by terrain features; this requires line-of-sight analysis between the two points. Such analysis requirements are typically characterized by large data volumes (numerous waypoints) and high timeliness requirements (real-time or near-real-time response). Ideally, the line-of-sight analysis service should return results within 0.5 seconds, with minimal server resource consumption and no impact on the normal operation of other functions in the web system.

[0018] Currently, there are two main technical approaches to achieving line-of-sight analysis based on oblique photogrammetry models. The first approach uses professional desktop GIS software (such as ArcGIS and SuperMap). Users need to install this software on their local computer, load the large oblique photogrammetry model file into memory, and then manually select the observation point and target point using the software's built-in line-of-sight analysis tools for calculation. Although the analysis logic of this method is similar to that of this invention (i.e., comparing the line-of-sight elevation with the ground elevation after interpolation sampling), it relies entirely on local high-performance computing resources and requires manual intervention. It cannot be automatically and concurrently integrated with web-based business systems (such as UAV flight path planning web applications), resulting in a cumbersome and inefficient process.

[0019] The second approach is based on web-based 3D rendering engines (such as Cesium) and their provided client-side APIs. This method preprocesses the oblique photogrammetry model into formats such as 3D Tiles and loads it for rendering in the user's browser. Viewpoint analysis calculations are executed on the client-side via JavaScript. While this achieves good integration with web applications, its core calculation process still requires the browser to load large amounts of 3D tile data from the network and relies on the client-side JavaScript engine for complex spatial indexing and mathematical operations. Limited by the client's computing power and network bandwidth, when faced with continuous, large-scale viewpoint analysis requests, it easily leads to browser interface lag and response delays, making it difficult to guarantee analysis performance and stability, and failing to meet the requirements of distributed, high-concurrency processing on the server side.

[0020] A deeper analysis of the two existing technological approaches reveals a common bottleneck: neither has optimized the underlying data storage and retrieval structure for the most crucial and frequent operation in viewport analysis—"quickly and accurately obtaining the corresponding surface elevation based on latitude and longitude coordinates." Whether in desktop software or a web engine, the viewport analysis process essentially requires direct, traversal-based or range-based queries on raw, massive amounts of oblique photogrammetry model data organized as files or streaming tiles. This data access mode suffers from low I / O efficiency and high computational overhead, becoming a key technological obstacle to achieving real-time, fast, and low-resource-consumption viewport analysis capabilities on web servers.

[0021] Therefore, this embodiment is proposed with the core objectives of reconstructing the storage and management of oblique photogrammetry model data, establishing an indexing mechanism that can support millisecond-level elevation queries, and working in conjunction with efficient line-of-sight analysis algorithms.

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] Firstly, this embodiment provides a method for sliced ​​storage and rapid line-of-sight analysis of oblique photogrammetry models, such as... Figure 1 As shown, the method includes steps S1-S8 in sequence, as detailed below.

[0024] Step S1: Extract the three-dimensional coordinates of the sampling points from the tile file of the oblique photogrammetry model.

[0025] Specifically, oblique photogrammetry models are typically organized as 3D tiles, with each tile being an independent directory containing multiple files that constitute the 3D model of that area. In this embodiment, the original model files are in OSGB format. The program traverses the specified model root directory to locate the .osgb files in each tile directory. Using a 3D graphics library capable of parsing OSGB format (such as the open-source OpenSceneGraph library, i.e., the OSG library), each .osgb file is read and parsed. After parsing, all vertex data of the triangular mesh model within the file is obtained. Each vertex contains its 3D spatial coordinates. These coordinates are typically located in a specific projected Cartesian coordinate system (such as the local coordinate system or the UTM projected coordinate system) and include elevation values. Subsequently, combined with spatial reference information files stored in the model directory (such as metadata.xml or proj.txt, which contain coordinate system definitions, origins, scales, etc.), a geographic coordinate transformation library (such as the PROJ library) is used to accurately convert the planar coordinates (X, Y, Z) of each vertex into geodetic latitude and longitude coordinates and elevation. Here, sampling points refer to spatial points with latitude, longitude, and altitude information obtained after transformation from model vertices; they are discretized representations of the landform by the oblique photogrammetry model. In practical applications, the model file format can also be other 3D formats (such as OBJ and FBX), and the parsing library can also be changed accordingly. This application does not limit this.

[0026] Step S2: Calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point.

[0027] The purpose of this step is to establish a regular spatial organization framework for the massive, unordered sampling points. First, the latitude and longitude coordinates of all sampling points are projected onto a unified Cartesian coordinate system using the same coordinate reference system as in step S1, resulting in the coordinates... Define a regular spatial grid that covers the entire analysis region. This grid is defined by the origin of the planar coordinate system. The grid size (gridSize) is uniquely determined. For a given sampling point, the goal of spatial grid index calculation is to obtain a string that uniquely identifies the grid it belongs to. The calculation process is as follows: first, determine the column number (columnpos) and row number (rowpos) of the grid to which the point belongs. The calculation formula is: in This is a rounding function used to identify the row and column of the grid where the point is located. The grid size `gridSize` can be set according to data density and application requirements. Its selection requires a trade-off between storage granularity and query efficiency. For example, for a model with an accuracy of 0.1 meters, setting `gridSize` to 200 meters can effectively control the number of partitions while ensuring query accuracy. A setting of 200 meters means that each grid covers a 200m × 200m surface area. This indexing method discretizes continuous geographic space into regular units, assigning a clear spatial affiliation code to each sample point.

[0028] Step S3: Collect the sampling point data belonging to the same spatial grid index as a piece and store it in the time series database.

[0029] This step forms the foundation for the data structure used in achieving efficient querying. A time-series database, such as InfluxDB or TimescaleDB, is the specific type of database chosen in this embodiment. These databases excel at efficiently handling the writing and querying of massive amounts of data points with timestamps or sequence identifiers. In this step, the spatial grid index is considered a spatial sequence identifier, adapting the oblique photogrammetry data to the time-series data model. For all sampling points that have obtained the same spatial grid index value in step S2, the three-dimensional coordinate information of these sampling points—namely, the longitude, latitude, and elevation fields—is treated as a data batch and written into an independent storage unit within the time-series database. In time-series databases, the core concept of this type of storage unit is for organizing and storing a series of data points with the same structure. For example, in InfluxDB, this concept is called a "Measurement"; in TimescaleDB, it is called a "Hypertable." In this embodiment, regardless of the specific time-series database product used, this storage unit is collectively referred to as a data shard. Each such data shard is identified and accessed through its unique spatial grid index value (e.g., grid015008). This storage method implements the logic of storing geographically adjacent data as adjacent, clustering data that may be queried simultaneously on physical storage, thus optimizing the efficiency of subsequent location-based range queries.

[0030] Step S4: Obtain the three-dimensional coordinates of observation point A and target point B, and calculate the line segment AB connecting observation point A and target point B based on the three-dimensional coordinates.

[0031] Specifically, observation point A and target point B are the two endpoints of the line-of-sight analysis. In a web application scenario, the coordinates of observation point A and target point B can be obtained by the user clicking and picking in the front-end 3D scene, or by entering precise latitude, longitude, and elevation values ​​through a form. Assuming the obtained 3D coordinates of observation point A are... The three-dimensional coordinates of target point B are: To perform geometric calculations, the latitude and longitude of observation point A and target point B must first be converted to Cartesian coordinates using the same projection method as in step S2. and With the elevation remaining constant, the Cartesian coordinates of observation point A and target point B are obtained as follows: In three-dimensional space, the line segment AB connecting the observation point A and the target point B can be uniquely determined. Its direction vector is... .

[0032] Step S5: Perform linear interpolation on line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point.

[0033] Interpolation points, also referred to as line-of-sight points in this embodiment, are a series of sampling points virtually generated at a certain density on line segment AB to analyze whether the line of sight is obstructed. These points are generated by linear interpolation of line segment AB. Specifically, using the parametric equation of line segment AB, let parameter t be used, where point A corresponds to t=0 and point B corresponds to t=1; the coordinates of any point P(t) on the line segment are: Then, set an interpolation step size parameter step (e.g., step=0.001), and take a series of values ​​at intervals of step within the interval t from 0 to 1. (e.g., 0, 0.001, 0.002, …, 1), each Substituting the parameters into the parametric equations, the plane coordinates and elevation of the corresponding interpolation point P_k can be calculated. Subsequently, it is also necessary to... Reverse calculation of latitude and longitude coordinates For future reference. This is the line-of-sight elevation of the interpolation point.

[0034] Step S6: For each interpolation point, calculate its spatial grid index based on its latitude and longitude coordinates, locate the corresponding data piece in the time series database based on the spatial grid index, and obtain the surface elevation corresponding to the interpolation point by querying the spatial range in the located data piece.

[0035] Specifically, for each interpolation point : (1) Index positioning: locate its latitude and longitude Transform into planar coordinates through projection Then reuse the exact same algorithm and parameters from step S2 (the same ,、 Calculate the spatial grid index to which the grid belongs (gridSize). This index value directly corresponds to the data fragment storing the model data for that region.

[0036] (2) Shard query: Based on the calculated index, the corresponding data shard (i.e., a specific table or measurement) in the time series database can be directly located.

[0037] (3) Elevation Acquisition: Within this data segment, perform a spatial range query. This is not a precise point-to-point query, but rather a filtering based on a small range to account for minor deviations caused by coordinate transformation and model sampling. Specifically, the process involves using... Centered on a square query range with sides of 2 * buffer (where buffer is a very small distance threshold, such as 0.00001 degrees), generate an SQL statement to query all model sampling points within this range (i.e., the data stored in step S103). From the returned candidate sampling points, determine the interpolation point by taking the elevation of the nearest point or interpolating the elevations of points within the range. Surface elevation of the location .this This represents the terrain elevation of the oblique photography model at this location.

[0038] Step S7: Compare the elevation of each interpolation point with its corresponding ground elevation.

[0039] Specifically, for each interpolation point Compare their line-of-sight elevations Compared with the surface elevation obtained from the model Size.

[0040] Step S8: When the elevation of all interpolation points is greater than their corresponding ground elevation, it is determined that observation point A and target point B are in line of sight.

[0041] Specifically, the criterion for line-of-sight is: for all interpolation points on line segment AB, the line of sight must always be higher than the ground surface, i.e., it requires... If all points satisfy If there exists at least one interpolation point that satisfies the condition, then it is determined that there is a line of sight between observation point A and target point B. If the line of sight is blocked by terrain or ground features at that point, it is considered as not being able to see.

[0042] Based on the above, this method, through database-based index queries and steps S1-S3, preprocesses the original model file into structured data stored in a high-efficiency time-series database, partitioned by spatial grid. During analysis (step S6), a simple index calculation directly jumps to the target data partition, replacing complex file parsing and spatial searching with a single efficient database range query. Essentially, this shifts the computational load from general-purpose computing units (CPU / GPU) executing complex spatial algorithms to a dedicated data management unit (time-series database) performing optimized index queries, which offers orders of magnitude speed advantage in handling such tasks. Combined with the lightweight analysis logic comprised of steps S5, S7, and S8, and the short-circuit judgment optimization available in step S6 (immediately stopping subsequent queries upon detection of an occlusion point), the entire visibility analysis process can be completed in sub-seconds with extremely low server resource consumption, perfectly supporting the high-concurrency, real-time business requirements of the web application.

[0043] To specifically implement the aforementioned spatial grid index calculation and ensure its efficiency and operability, in one embodiment, the spatial grid index corresponding to each sampling point is calculated based on its latitude and longitude coordinates, including: Step S21: Based on the preset origin of the plane coordinate system and the grid side length, calculate the column number and row number of the latitude and longitude coordinates of the sampling point in the plane coordinate system.

[0044] Specifically, first, a reference plane coordinate system must be established for grid division. This coordinate system can be obtained by projecting geographic latitude and longitude (e.g., using UTM projection). Recalling the previous point, the origin of this coordinate system must be set. The origin can typically be chosen as the projected coordinates of the southwest corner (bottom left) of the model's coverage area to ensure all grid index values ​​are non-negative. Simultaneously, the grid side length `gridSize` is defined; `gridSize` is a length value with units consistent with the planar coordinate system (e.g., meters). For a grid whose coordinates after projection are... The formula for calculating the grid column number (columnpos, east-west direction) and row number (rowpos, north-south direction) of the sampling points is as follows: Step S22: Format and concatenate the calculated column and row numbers to generate a spatial grid index.

[0045] Specifically, the calculated columnpos and rowpos are integers. Directly concatenating them (e.g., concatenating column 5 and row 12 to form "512") might cause confusion with column 51 and row 2 ("512"). Therefore, formatting is necessary. A feasible approach is to format them as a fixed-length decimal string. For example, assuming the model area has no more than 1000 grids in both the east-west and north-south directions, a 3-digit format can be used: columnpos_str = String.format("%03d", columnpos), rowpos_str = String.format("%03d", rowpos). This will format column 5 and row 12 as "005" and "012". Finally, the formatted strings are concatenated in a pre-defined order, such as column number first, row number last, resulting in the index string "005012". In practical applications, a prefix (e.g., "G_") can be added before concatenation to enhance readability, generating the final spatial grid index, such as "G_005012".

[0046] Based on the above, the continuous space is discretized and scalarized through regular grid partitioning and row and column number calculation. Formatted concatenation ensures the standardization and uniqueness of the index string, making it highly suitable as a database table name, partition key, or label, thereby achieving physical data sharding in step S3. This index structure provides a reliable foundation for the subsequent implementation of the crucial capability of quickly locating data shards based on interpolation point coordinates.

[0047] To ensure the generated index has good consistency and manageability, in one embodiment, the calculated column numbers and row numbers are formatted and concatenated, including: Step S221: Format the column number and row number as a fixed-length numeric string.

[0048] Specifically, a fixed number of digits is set for formatting, for example, digit = 3. For any calculated column number columnpos (let's say 15), it is converted into a string of length 3 using the formatting function, padded with '0's on the left if it is less than 3 digits. That is: columnpos_str = "015". Similarly, for the row number rowpos (let's say 8), it is formatted as rowpos_str = "008". This ensures that the string representation has a fixed length regardless of the row and column numbers, avoiding ambiguity caused by concatenation.

[0049] Step S222: Concatenate the formatted numeric string with the preset prefix string to generate a spatial grid index.

[0050] Specifically, define a prefix string, for example, prefix = "grid". Concatenate the prefix string with the column number string and row number string obtained in step S221 in sequence. A common concatenation order is: prefix + columnpos_str + rowpos_str. For example, if prefix = "grid", columnpos_str = "015", and rowpos_str = "008", the resulting complete spatial grid index will be "grid015008". This string can be directly used as the name of a data table (shard) in the time-series database, for example, it can be represented as database.grid015008 in SQL.

[0051] Based on the above, by enforcing fixed-length formatting and adding prefixes, the generated index strings are ensured to have a high degree of standardization and self-interpretability. Fixed length eliminates the risk of ambiguity from concatenation; adding prefixes (such as "grid") makes the index easily identifiable and manageable within the database's global namespace and avoids conflicts with system reserved words. This clear and well-defined index naming convention is a crucial foundation for building automated and scalable data storage and retrieval systems.

[0052] To ensure efficient acquisition of surface elevation, in one embodiment, the surface elevation corresponding to the interpolation point is obtained by spatial range querying within the location data slice, including: Step S61: Construct a square query range centered on the latitude and longitude coordinates of the interpolation point.

[0053] Specifically, for example, for interpolation points Its latitude and longitude are To improve query efficiency and tolerate minor coordinate errors, this embodiment uses a simple square region for approximate querying instead of calculating a precise circular neighborhood. A small positive number buffer is defined as the buffer distance (the unit is the same as latitude and longitude, usually in degrees). Construct a square with a side length of 2 * buffer centered at the buffer. The boundary of this square is determined by four values: minimum longitude. Maximum longitude Minimum latitude Maximum latitude .

[0054] Step S62: Generate and execute a Structured Query Language (SQL) statement to query model sampling points whose latitude and longitude coordinates fall within the square query range in the data shards, and determine the ground elevation corresponding to the interpolation point based on the query results.

[0055] Specifically, after locating the data shard (e.g., table name grid015008), construct an SQL query. The core of this statement is to utilize database indexes to perform efficient range filtering on the `longitude` and `latitude` fields. Example SQL is as follows: SELECT longitude, latitude, elevation FROM grid015008 WHERE longitude>= x min AND longitude <= x max AND latitude >= y min AND latitude <= y max .

[0056] After executing this query, the database will return all model sampling points that fall within the square area. These points can be represented as a set. Next, the interpolation points are determined based on set S. Surface elevation Specific strategies could include: (1) Nearest neighbor method: calculate the distance from each point in S to the nearest neighbor. The spherical or planar distance is used to select the elevation of the closest point as the distance. .

[0057] (2) Interpolation method: If the points in S form a local surface (for example, fitting a local plane or surface function through the points in S), then... Substitute into the function to calculate .

[0058] In practical applications, if the model is dense enough, there is usually only one or a few points in S, and the nearest neighbor method can obtain sufficiently accurate results. And the computational load is small.

[0059] Based on the above, complex spatial proximity queries are transformed into multi-field range join queries, which are best suited for databases. By creating a composite index on the longitude and latitude fields, the database can quickly locate the target data with a complexity close to O(log N), where N is the total amount of data within the shard. Compared to traversing and calculating in memory or building complex spatial index trees (such as R-trees), this method fully leverages the optimized query engine of a mature database management system (DBMS), offloading computationally intensive tasks and achieving millisecond-level altitude retrieval speeds.

[0060] To further clarify and optimize the query range construction process, in one embodiment, a square query range is constructed, including: Step S611: Using the latitude and longitude coordinates of the interpolation point as the center, extend upwards and downwards by a preset fixed buffer distance to form the boundary of the square query range.

[0061] Specifically, a fixed buffer distance is set. This value is an empirical value, selected based on the following principles: it should be greater than the sum of the maximum possible interval between model sampling points and the coordinate transformation error to ensure that the query always captures at least one neighboring model sampling point; yet it should be as small as possible to reduce unnecessary query ranges and improve query efficiency. For example, for an oblique photogrammetry model with a ground resolution of 5 cm, the sampling point spacing might be approximately 0.1 meters, which corresponds to approximately 1e-6 degrees in latitude and longitude. Considering calculation errors, the buffer can be set to 5e-6 degrees (approximately 0.5 meters). Therefore, for interpolation points... The query boundary can then be determined using the aforementioned calculation formulas, specifying the minimum longitude, maximum longitude, minimum latitude, and maximum latitude. These four simple addition and subtraction operations complete the determination of the query boundary. In practical applications, the buffer can be configured according to the precision of the specific data source to adapt to different model data; this embodiment does not impose such limitations.

[0062] Based on the above, a fixed buffer distance avoids the overhead of dynamically calculating the buffer based on the local density of the model, making the query preparation process extremely lightweight. Although this is an approximation method, as long as the buffer value is set reasonably, query performance can be maximized while ensuring the accuracy of query results. This strategy of trading a deterministic, minimal loss of precision for a significant performance improvement is very effective in engineering practice, especially suitable for web service scenarios with extremely high real-time requirements.

[0063] To improve overall analysis efficiency and avoid invalid calculations, in one embodiment, when the elevation of all interpolation points is greater than their corresponding surface elevation, it is determined that observation point A and target point B are in sight, including: Step S81: Iterate through all interpolation points in sequence.

[0064] Specifically, following the order in which the interpolation points are generated (parameter t ranges from 0 to 1), a loop is created to process each interpolation point one by one. .

[0065] Step S82: If the elevation of any interpolation point is less than or equal to its corresponding ground elevation, terminate the traversal and determine that observation point A and target point B are not in sight.

[0066] Specifically, within the loop body, for the current interpolation point Execute step S6 to obtain its surface elevation Then immediately compare their line-of-sight elevations. and Once discovered If the condition is met, it indicates that the line of sight is blocked at this point, and there is no need to check subsequent interpolation points. At this point, the loop immediately exits, all subsequent queries and comparisons cease, and the final result without line of sight is returned directly. This forms a short-circuit evaluation strategy.

[0067] Step S83: If all interpolation points have been traversed and the elevation of all interpolation points is greater than the corresponding ground elevation, then it is determined that observation point A and target point B are in line of sight.

[0068] Specifically, only after the loop has completely traversed all interpolation points and compared the results for each point... Only if all conditions are met will it be determined that there is a line of sight between observation point A and target point B.

[0069] Based on the above, a short-circuit evaluation strategy was used to optimize the line-of-sight analysis process. In reality, many lines of sight are obstructed. Traditional methods that calculate all points before making a judgment involve expensive queries to all interpolation points, while this method terminates immediately upon detecting the first obstruction point, saving significant amounts of unnecessary database queries and computational resources. This optimization is particularly effective for long-distance analysis or high-density interpolation, significantly reducing average response time and improving system throughput.

[0070] To achieve linear interpolation and ensure its mathematical correctness and controllability, in one embodiment, linear interpolation is performed on line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point, including: Step S51: Determine the parametric equation of line segment AB based on the three-dimensional coordinates of observation point A and target point B.

[0071] Specifically, let the coordinates of observation point A in the selected plane coordinate system and elevation be... The coordinates of target point B are The line segment AB connecting A and B can be characterized by a parameter t, where t ∈ [0, 1]. The coordinates of any point P(t) on the line segment can be given by the following parametric equation: When t=0, P(0) = A; when t=1, P(1) = B.

[0072] Step S52: Select multiple parameter values ​​at equal intervals within the parameter domain according to the preset interpolation step size.

[0073] Specifically, an interpolation step size, `step`, is defined, which determines the sampling density. A smaller `step` generates more interpolation points, resulting in higher analysis accuracy, but also a greater computational burden. For example, let's set `step = 0.001`. Then, within the interval [0, 1], from... Starting with 0, a series of parameter values ​​are generated at intervals of step: , , …,until ,in Typically, the value of the last parameter will be ensured. This includes the endpoint B. Therefore, the parameter value sequence is: .

[0074] Step S53: Substitute each parameter value into the parametric equation to calculate the three-dimensional coordinates of the corresponding interpolation point.

[0075] Specifically, for each parameter value in the sequence Substitute it into the parametric equation of step S51: The result of the calculation That is, the coordinates of the kth interpolation point in the plane coordinate system and elevation.

[0076] After that, it is necessary to Convert back to latitude and longitude coordinates via inverse projection This is for use in subsequent queries. This is the line-of-sight elevation of that point.

[0077] Based on the above, the parametric equation form makes interpolation calculations uniform and efficient. The single parameter, the interpolation step size, allows for convenient and flexible control over the balance between analysis accuracy and performance: smaller steps are used in scenarios requiring high-precision analysis (such as safety-critical areas); larger steps are used in scenarios requiring rapid previewing or processing of massive amounts of data.

[0078] As the starting point for data input in the entire technical solution, to clarify the specific process of extracting effective information from the original model data, in one embodiment, the three-dimensional coordinates of sampling points are extracted from the tile file of the oblique photogrammetry model, including: Step S11: Read the tile file of the oblique photogrammetry model.

[0079] Specifically, oblique photogrammetry modeling results are typically organized in a directory tree format. The root directory contains multiple subdirectories (Tile), each tile directory corresponding to a spatial region. This includes the 3D model files for that region (such as multiple .osgb files) and a metadata file describing the spatial location of that tile. The program needs to receive the model's root directory path as input, then recursively traverse the directory structure to locate all .osgb format data files. Simultaneously, it needs to read the global metadata file (such as metadata.xml) in each tile directory or the root directory. This file contains the Coordinate Reference System (CRS) definition used by the model, such as EPSG codes (e.g., EPSG:4547 representing the Beijing 54 coordinate system) or WKT strings.

[0080] Step S12: Parse the tile file and extract the longitude, latitude, and elevation coordinates of multiple sampling points recorded therein.

[0081] Specifically, for each .osgb file, the file is loaded using an OSGB parsing library (such as the osgDB::readNodeFile function in the OSG library). After loading, the geometry in its scene graph is obtained, and all vertices are traversed from the geometry. Each vertex stores its coordinates in the model's local coordinate system. Combined with the tile origin recorded in the tile's metadata. Based on the pose parameters, the local vertex coordinates are transformed to the tile's global coordinate system (usually the projection plane coordinate system). This yields the vertex coordinates. ,in This is the elevation. Finally, using the overall CRS information obtained in step S11, the projected coordinates are transformed using coordinate transformation tools (such as the proj_create_crs_to_crs and proj_trans functions in the PROJ library). Convert to latitude and longitude Thus, the complete 3D geographic coordinates of a sampling point have been extracted from a vertex: This process is repeated for all vertices in the model to complete the data extraction for the entire model. Coordinate transformation involves complex mathematical transformations, but mature libraries (such as PROJ) provide reliable implementations. Those skilled in the art can call the corresponding API based on the CRS information to complete this task, and this application does not limit this aspect.

[0082] Based on the above, by extracting geospatial data from the mainstream oblique photogrammetry format (OSGB), the key steps of reading, parsing, and coordinate transformation of sampling point data are clarified. In particular, the indispensable role of metadata and coordinate transformation in obtaining correct latitude and longitude information is emphasized, thereby ensuring that this method can be integrated with industry-standard data production processes, has broad applicability and repeatability, and provides a high-quality data source for subsequent processing.

[0083] To solidify the method into a deployable and integrable software product, this embodiment provides an oblique photogrammetry model segmentation storage and rapid line-of-sight analysis system, applying the oblique photogrammetry model segmentation storage and rapid line-of-sight analysis method described above, such as... Figure 2 As shown, the system includes: The data extraction unit is configured to extract the 3D coordinates of sampling points from the tile files of the oblique photogrammetry model. This unit is implemented in software as a standalone data preprocessing service or module, containing an OSGB file parser, a coordinate transformer, and relying on geocomputing libraries such as PROJ. The input is the model directory path, and the output is either streaming or batch processing. Data flow.

[0084] The index calculation unit is configured to calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point. This unit receives the output of the data extraction unit, loads the preset (orgX, orgY, gridSize) configuration parameters, performs column number and row number calculation and formatted concatenation for each sampling point, and attaches a spatial grid index label to each data point.

[0085] The sharded storage unit is configured to store sample point data belonging to the same spatial grid index as a shard in the time-series database; this unit is the data write engine. It receives sample point data with index tags, groups and caches it according to the spatial grid index tags, establishes a connection with the time-series database (such as an InfluxDB instance), and writes each group of data to the corresponding data shard (such as InfluxDB's Measurement) in batches. It is responsible for managing the database connection pool, handling write errors, and retries.

[0086] The line segment calculation unit is configured to acquire the 3D coordinates of observation point A and target point B, and calculate the line segment AB connecting observation point A and target point B based on the 3D coordinates. This unit is typically part of a web service, receiving JSON parameters (containing lng, lat, ele) of points A and B sent by the client via a RESTful API or RPC interface. It converts the latitude and longitude to projected coordinates in memory and calculates the parametric equation coefficients of line segment AB.

[0087] The linear interpolation unit is configured to perform linear interpolation on line segment AB to obtain multiple interpolation points and their 3D coordinates. This unit receives line segment information output from the line segment calculation unit and generates an interpolation point parameter sequence based on the configured interpolation step size parameter. The projected coordinates and line-of-sight elevation of each interpolation point are calculated, and then back-projected into latitude and longitude. The elevation query unit is configured to calculate the spatial grid index of each interpolation point based on its latitude and longitude coordinates. Based on this index, it locates the corresponding data shard in the time-series database and retrieves the surface elevation of the interpolation point through a spatial range query within that shard. This unit is the system's query hub. Its embedded index calculation logic (same as the index calculation unit) quickly calculates the spatial grid index label for each interpolation point. Then, based on the spatial grid index label, it routes to the correct database shard client, constructs the aforementioned SQL range query statement, and initiates an asynchronous query. After the query returns, it uses either the nearest neighbor method or interpolation to parse the surface elevation from the result set. .

[0088] The visibility assessment unit is configured to compare the elevation of each interpolation point with its corresponding surface elevation, and determine that observation point A and target point B are visible to each other when the elevations of all interpolation points are greater than their corresponding surface elevations. This unit receives the elevation query unit's returned elevation data. The sequence is processed, and a short-circuit evaluation strategy is implemented. It maintains a state machine that terminates immediately and returns "no line of sight" if any comparison fails, and only returns "line of sight" if all comparisons succeed. The final result is returned to the client via a web interface.

[0089] The aforementioned units can be deployed on the same server or in a distributed manner, communicating through message queues (such as Kafka) or RPC frameworks (such as gRPC). These units collaborate to instantiate the aforementioned methodology into a high-performance, horizontally scalable software system.

[0090] To clarify the software product form of this solution, this embodiment provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the oblique photogrammetry model segmentation storage and rapid line-of-sight analysis method described above is implemented.

[0091] Specifically, computer-readable storage media include, but are not limited to: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), solid-state drives (SSDs), magnetic disks or optical disks, and other media capable of storing program code.

[0092] When the computer program in this storage medium is loaded into and runs on computing devices with processors and memory, such as servers, personal computers, and cloud computing nodes, the processor reads and executes the program instructions. These instructions specifically implement all the steps in the aforementioned method embodiments, such as: controlling the computing device to read OSGB files and extract coordinates; performing grid index calculation and formatting; driving the database client to write data fragments into the time-series database; receiving visibility analysis requests, performing line segment calculations and interpolation; performing efficient data index queries for each interpolation point; and implementing short-circuit logic for visibility judgment. Through this medium, the technical solution described in this embodiment can exist, circulate, and be applied in the form of a software product, enabling any user who obtains this medium, with the corresponding computing environment (having the required database and dependent libraries installed), to reproduce and obtain the fast visibility analysis technical effect brought by the aforementioned method on their device.

[0093] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0094] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models, characterized in that, The method includes the following steps: Extract the 3D coordinates of sampling points from the tile file of the oblique photogrammetry model; Calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point; Sampling point data belonging to the same spatial grid index are stored as a single piece in the time series database; Obtain the three-dimensional coordinates of observation point A and target point B, and calculate the line segment AB connecting observation point A and target point B based on the three-dimensional coordinates; Linear interpolation is performed on the line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point; For each interpolation point, the spatial grid index to which it belongs is calculated based on its latitude and longitude coordinates. The corresponding data segment in the time series database is located based on the spatial grid index, and the surface elevation corresponding to the interpolation point is obtained by querying the spatial range in the located data segment. The elevation of each interpolation point is compared with its corresponding ground elevation. When the elevation of all interpolation points is greater than their corresponding ground elevation, it is determined that the observation point A and the target point B are in line with each other.

2. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 1, characterized in that, The calculation of the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point includes: Based on the preset origin of the plane coordinate system and the grid side length, calculate the column number and row number corresponding to the latitude and longitude coordinates of the sampling point in the plane coordinate system; The calculated column number and row number are formatted and concatenated to generate the spatial grid index.

3. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 2, characterized in that, The step of formatting and concatenating the calculated column number and row number includes: Format the column number and the row number into a fixed-length numeric string; The formatted numeric string is concatenated with a preset prefix string to generate the spatial grid index.

4. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 1, characterized in that, The step of obtaining the surface elevation corresponding to the interpolation point by querying the spatial range within the located data segment includes: A square query range is constructed with the latitude and longitude coordinates of the interpolation point as the center; Generate and execute a Structured Query Language (SQL) statement to query model sampling points whose latitude and longitude coordinates fall within the square query range in the data shard, and determine the surface elevation corresponding to the interpolation point based on the query results.

5. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 4, characterized in that, The construction of a square query range includes: Centered on the latitude and longitude coordinates of the interpolation point, extend upwards and downwards by a preset fixed buffer distance to form the boundary of the square query range.

6. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 1, characterized in that, The step of determining that the observation point A and the target point B are in sight when the elevation of all interpolation points is greater than their corresponding surface elevation includes: Iterate through all interpolation points in sequence; If the elevation of any interpolation point is less than or equal to its corresponding ground elevation, the traversal is terminated and it is determined that the observation point A and the target point B are not in sight. If all interpolation points have been traversed and the elevation of all interpolation points is greater than the corresponding ground elevation, then it is determined that the observation point A and the target point B are in line of sight.

7. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 1, characterized in that, The linear interpolation of line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point includes: Based on the three-dimensional coordinates of the observation point A and the target point B, determine the parametric equation of the line segment AB; Based on the preset interpolation step size, multiple parameter values ​​are selected at equal intervals within the parameter domain; Substitute each parameter value into the parameter equation to calculate the three-dimensional coordinates of the corresponding interpolation point.

8. The method for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models according to claim 1, characterized in that, The extraction of the three-dimensional coordinates of sampling points from the tile file of the oblique photogrammetry model includes: Read the tile files of the oblique photogrammetry model; The tile file is parsed to extract the longitude, latitude, and elevation coordinates of multiple sampling points recorded therein.

9. A system for segmented storage and rapid line-of-sight analysis of oblique photogrammetry models, characterized in that, The system includes: The data extraction unit is configured to extract the three-dimensional coordinates of sampling points from the tile file of the oblique photogrammetry model; The index calculation unit is configured to calculate the corresponding spatial grid index based on the latitude and longitude coordinates of each sampling point. The sharded storage unit is configured to store sample point data belonging to the same spatial grid index as a shard in the time series database; The line segment calculation unit is configured to obtain the three-dimensional coordinates of the observation point A and the target point B, and calculate the line segment AB connecting the observation point A and the target point B based on the three-dimensional coordinates. A linear interpolation unit is configured to perform linear interpolation on the line segment AB to obtain multiple interpolation points and the three-dimensional coordinates of each interpolation point; The elevation query unit is configured to calculate the spatial grid index to which each interpolation point belongs based on its latitude and longitude coordinates, locate the corresponding data segment in the time series database based on the spatial grid index, and obtain the surface elevation corresponding to the interpolation point by querying the spatial range in the located data segment. The visibility judgment unit is configured to compare the elevation of each interpolation point with its corresponding ground elevation, and determine that the observation point A and the target point B are visible to each other when the elevation of all interpolation points is greater than their corresponding ground elevation.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the oblique photogrammetry model segmentation storage and rapid line-of-sight analysis method as described in any one of claims 1-8.

Images