A method and system for real-time interactive presentation of spatial positioning data of drainage pipe network

Abstract

This invention relates to the field of drainage network information processing technology, and more particularly to a real-time interactive presentation method and system for spatial positioning data of drainage networks. The method includes: acquiring verified facility data and automatically marking affected map tiles when new data is added to the database; upon receiving a request for a marked tile, dynamically simplifying the facility data according to the target scaling level and generating vector tiles; performing high-performance parsing, thinning, and rendering of the tiles, and supporting querying the original high-precision data through coordinate inversion and tolerance buffering, thereby achieving real-time mapping and interactive verification of field-collected data. This invention achieves data synchronization through R-tree indexing and time windows, utilizes quadtree on-demand slicing, combines Web Worker concurrent parsing and screen-space thinning rendering, and achieves precise attribute querying through coordinate inversion and tolerance buffering, significantly improving the efficiency and interactive experience of field data collection for drainage networks.

Description

Technical Field

[0001] This invention relates to the field of drainage network information processing technology, and in particular to a real-time interactive presentation method and system for spatial positioning data of drainage networks. Background Technology

[0002] In the management and operation of urban drainage pipe network assets, the collection of pipeline spatial location data is a fundamental task. Traditional methods typically employ a sequential process of geophysical exploration followed by surveying: geophysical personnel use equipment such as electromagnetic induction instruments and ground-penetrating radar to mark the pipeline route at the manhole and hand-draw sketches; surveyors then use RTK or total stations to collect coordinates of feature points; and office staff manually integrate the scattered paper sketches, survey data, and attribute tables into a map. This process requires at least two shifts working in shifts and is extremely time-consuming and labor-intensive. Furthermore, because the data carriers for each stage are independent, the completeness of the data collection cannot be verified in real time during the fieldwork. Often, omissions or topological connection errors are only discovered after the map is completed in the office, requiring further fieldwork. Simultaneously, the pipeline map is usually delivered several days later, preventing on-site decision-makers from viewing the pipeline route, burial depth, and relationships with adjacent pipelines in real time at the manhole, and making it difficult to intuitively assess spatial conflicts between pipelines. The above process suffers from significant drawbacks, including low fieldwork efficiency, fragmented information, and severe delays in visualization.

[0003] Therefore, there is an urgent need to provide a technical solution to address the above problems. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method and system for real-time interactive presentation of spatial positioning data of drainage pipe networks.

[0005] In a first aspect, the present invention provides a method for real-time interactive presentation of spatial positioning data of drainage pipe networks, the technical solution of which is as follows:

[0006] Obtain verified spatial location data representing the spatial location of drainage network facilities and the corresponding attribute information of the facilities, and construct a dynamic R-tree spatial index adapted to point-like and line-like facilities of the drainage network. Based on the time window mechanism, cache the data and write it to the spatial database.

[0007] When new data is detected in the spatial database, based on the spatial coordinates of the new data, the quadtree pyramid model is used to back-calculate one or more map tiles that represent different zoom levels of the electronic map and are affected by the spatial coordinates, and these tiles are marked as pending updates.

[0008] Upon receiving a request instruction for a map tile, if the requested map tile is in an pending update state, the system dynamically and geometrically simplifies the latest facility data for the corresponding geographic area in the spatial database according to the target scaling level of the current request, and encodes and generates vector tile data for the corresponding map tile.

[0009] Web Worker is used to concurrently parse vector tile data and apply dynamic thinning based on screen space error threshold before rendering and display. When an interaction command for a map facility is received, the coordinates of the interaction points on the map are inversely calculated and geographic tolerance buffered. Based on the R-tree spatial index, the spatial location data and attribute information corresponding to the facility in the spatial database without geometric simplification are queried within the tolerance range.

[0010] The beneficial effects of the real-time interactive presentation method for spatial positioning data of drainage pipe networks according to the present invention are as follows:

[0011] The method of this invention achieves data synchronization through R-tree indexing and time windows, utilizes quadtree slicing on demand, combines Web Worker concurrent parsing and screen space thinning rendering, and achieves accurate attribute query through coordinate inverse calculation and tolerance buffering, which significantly improves the efficiency and interactive experience of on-site data collection in drainage pipe networks.

[0012] Secondly, this invention provides a real-time interactive presentation system for spatial positioning data of drainage pipe networks, the technical solution of which is as follows:

[0013] The real-time interactive presentation system for the spatial positioning data of the drainage pipe network includes:

[0014] A portable RTK terminal is used to receive satellite observation data and differential correction signals, calculate spatial positioning data, and transmit it in real time via Bluetooth in combination with the attribute information of drainage pipe network facilities.

[0015] The mobile application is used to receive Bluetooth data streams transmitted from portable RTK terminals, parse GPGGA statements to extract positioning coordinates, verify the validity of the data based on differential correction data, and upload the verified spatial positioning data after associating it with attribute information.

[0016] The server receives data uploaded from the mobile application, builds a dynamic R-tree spatial index, caches data and writes it to the spatial database based on a time window mechanism; it monitors changes in the spatial database, calculates the map tiles affected by the changes and marks them as pending updates; it responds to client requests for map tiles, performs dynamic geometric simplification of facility data within the corresponding geographic area according to the target scaling level, and generates vector tile data.

[0017] The client receives and parses vector tile data, decodes it in parallel into point and line geometric features using Web Workers, dynamically thins it based on screen space error thresholds, and then renders it using WebGL. In response to interactive commands on map facilities, the client performs coordinate inversion and geographic tolerance buffering on interactive points, queries the server for corresponding unsimplified spatial positioning data and attribute information, and returns the query results.

[0018] The beneficial effects of the real-time interactive presentation system for spatial positioning data of drainage pipe networks according to the present invention are as follows:

[0019] The system of this invention achieves data synchronization through R-tree indexing and time windows, utilizes quadtree slicing on demand, combines Web Worker concurrent parsing and screen space thinning rendering, and achieves accurate attribute query through coordinate inverse calculation and tolerance buffering, which significantly improves the efficiency and interactive experience of on-site data collection in drainage pipe networks.

[0020] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0022] Figure 1 This is a flowchart illustrating an embodiment of a method for real-time interactive presentation of spatial positioning data of a drainage pipe network according to the present invention.

[0023] Figure 2 This is a schematic diagram of the quadtree pyramid model of the present invention;

[0024] Figure 3 This is a schematic diagram illustrating the content of the GPGGA data parsing format in this invention;

[0025] Figure 4 This is a schematic diagram of an embodiment of a real-time interactive presentation system for spatial positioning data of a drainage pipe network according to the present invention.

[0026] Figure 5 This is a flowchart of the dynamic vector slicing process in this invention;

[0027] Figure 6 This is a schematic diagram of the WebGL block loading and rendering process of the present invention;

[0028] Figure 7This is a schematic diagram of the real-time update mechanism implemented in this invention. Detailed Implementation

[0029] This invention aims to solve the problems of information fragmentation and feedback lag caused by the step-by-step sequential process of data acquisition, mapping, and verification in traditional drainage network mapping. It provides a closed-loop technical solution that enables high-precision positioning, real-time data visualization, and interactive verification simultaneously during field operations. Unlike existing technologies that artificially separate geophysical exploration, surveying, and indoor mapping, this invention constructs a coherent technical path of "positioning-acquisition-indexing-slicing-rendering," allowing field personnel to simultaneously acquire centimeter-level spatial data on mobile terminals while instantly viewing dynamically generated network topology maps. This compresses the previously fragmented information processing across multiple stages and carriers into a unified, real-time on-site workflow.

[0030] The unique concept of this invention lies in abandoning the traditional passive mapping approach of "collecting first, then storing in the database, and then publishing," and instead adopting an architecture of proactive perception and dynamic response. On the one hand, by deeply integrating the real-time differential positioning of portable RTK terminals with the instant parsing capabilities of mobile applications, it ensures that spatial data possesses high accuracy and timeliness from the source. On the other hand, it innovatively introduces a dynamic R-tree spatial index adapted to the characteristics of pipeline network facilities and a vector tiling mechanism that updates on demand. This enables the system to automatically and accurately recalculate local map tiles based on data changes, and maintains smooth interaction even in massive data environments by utilizing front-end concurrent parsing and adaptive thinning strategies. This design not only eliminates information barriers between internal and external operations but also, for the first time, achieves a fundamental shift from "blind collection" to "what you see is what you get" in drainage pipeline network sites, providing strong technical support for rapid on-site decision-making and topology verification.

[0031] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0032] Figure 1 This diagram illustrates a flowchart of an embodiment of a real-time interactive presentation method for spatial positioning data of a drainage pipe network provided by the present invention. This method is executed by a real-time interactive presentation system for spatial positioning data of a drainage pipe network. Figure 1 As shown, it includes the following steps:

[0033] S100. Obtain verified spatial positioning data representing the spatial location of drainage network facilities and the corresponding attribute information of the facilities, and construct a dynamic R-tree spatial index adapted to point-like and line-like facilities of the drainage network. Based on the time window mechanism, cache the data and write it to the spatial database.

[0034] In this embodiment, "verified" means that the original positioning data is screened based on the validity of the differential correction signal to ensure that the acquired spatial positioning data reaches centimeter-level accuracy, thereby meeting the requirements for accurate acquisition of the spatial location of drainage pipe network facilities.

[0035] "Drainage network facilities" include point facilities (such as inspection wells and drainage outlets) and linear facilities (such as pipe sections).

[0036] A "dynamic R-tree spatial index" is a tree-like spatial index that can dynamically adjust the node structure (including node splitting and merging) as data is inserted. It is used to efficiently organize the minimum bounding rectangle of the facility to support subsequent fast spatial range queries.

[0037] The "time window mechanism" refers to setting a fixed time window, during which multiple pieces of location data are accumulated in memory, and then written to the spatial database in batches after the window ends, in order to reduce frequent database write operations and improve data throughput.

[0038] It should be noted that traditional solutions often write location data to the database one record at a time in real time, which can lead to significant write pressure in high-concurrency scenarios. This step uses a time-window batch write mechanism, which significantly reduces the database load while ensuring data real-time performance.

[0039] Furthermore, one specific implementation of step S100 includes: receiving high-precision spatial positioning data from the acquisition terminal and validating each data entry, retaining only data with valid differential correction and meeting accuracy requirements; simultaneously acquiring facility attribute information entered by field personnel via mobile terminals. Then, a minimum bounding rectangle is constructed for each facility: for point-like facilities, its coordinates are used as the rectangle; for linear facilities, its geometric bounding rectangle is used. These minimum bounding rectangles, along with the corresponding data storage locations, are dynamically inserted into the R-tree as entries, constructing a spatial index that can be updated in real time as data increases. Simultaneously, a time window mechanism is activated: newly arrived data is cached in memory, and after each preset time window (e.g., 10 seconds), all accumulated data within the window is written to the spatial database in batches, triggering incremental updates to the R-tree spatial index after writing.

[0040] S200. When new data is detected in the spatial database, based on the spatial coordinates of the new data, use the quadtree pyramid model to back-calculate one or more map tiles that represent different zoom levels of the electronic map and are affected by the spatial coordinates, and mark them as pending updates.

[0041] In this embodiment, the "quadrinode pyramid model" is a multi-scale spatial grid partitioning model that divides an electronic map from a global view to a street view into multiple zoom levels. The Earth's surface at each level is divided into several rows and columns of tile grids, with each tile uniquely identified by its zoom level and row / column number. This model establishes a mapping function from "geographic coordinates to tile ID," enabling rapid calculation of the tile number corresponding to any spatial coordinate at each zoom level.

[0042] To facilitate understanding of the hierarchical structure and tile mapping relationship of this model, such as Figure 2 As shown. Figure 2 This diagram illustrates a quadtree pyramid model, showing the correspondence between tile grids and geographic features at different scaling levels. The diagram displays the pyramid structure from lower levels (e.g., z9) to higher levels (e.g., z11) from top to bottom. As the Z value increases, the tile grid's division of geographic space becomes increasingly fine. The blue line in the diagram represents an exemplary geographic feature (e.g., a drainage pipe segment). This feature traverses specific tile grids at multiple levels. Green tiles represent areas unaffected by data changes, while red tiles represent the set of tiles affected by this geographic feature and marked as "pending update." This diagram clearly demonstrates how, when a single geographic feature changes, the system locates and marks the target tiles requiring updating at different levels based on their spatial span, thereby achieving efficient local data updates.

[0043] "Marking as pending update" means marking these tiles as "dirty" in the cache or database and clearing their original cached data, indicating that they need to be regenerated the next time they are requested.

[0044] Understandably, traditional solutions typically require waiting for all data to be collected before generating tiles as a whole. This step, however, implements a real-time response mechanism that triggers tile failure as soon as data is written, ensuring that subsequent requests can obtain the latest data.

[0045] Furthermore, one specific implementation of step S200 includes: listening for insertion or update events in the spatial database via a database trigger. When new data is written, the trigger captures the spatial coordinates and timestamp of the data and stores them in a lightweight cache database. A short time window (e.g., 5 seconds) is set. After the window ends, the spatial coordinates of all accumulated changed data within the window are retrieved from the cache database. For each spatial coordinate, the tile ID corresponding to each scaling level is calculated using the mapping function in the quadtree pyramid model, resulting in a set of affected tiles. Then, all tiles in this set are marked as "to be updated," and the original slice data of these tiles in the cache is cleared. In this way, when a subsequent request for these tiles is received, the slices will be regenerated based on the latest database content.

[0046] S300: Receive a request instruction for map tiles. If the requested map tile is in an update pending state, dynamically and geometrically simplify the latest facility data of the corresponding geographical area in the spatial database according to the target scaling level of the current request, and encode and generate vector tile data of the corresponding map tile.

[0047] In this embodiment, "dynamic geometry simplification" refers to the simplification strategy of different precision for linear and point facilities according to different zoom levels requested: geometric details are greatly simplified in macro view (small zoom level) to reduce the amount of data, while fine geometry is preserved in micro view (large zoom level) to ensure display quality.

[0048] "Vector slice data" is binary data encoded into simplified geometric and attribute information according to the standard vector slice format. It has the characteristics of small size, fast transmission and direct parsing.

[0049] It should be noted that, unlike the traditional approach of pre-generating all tiles, this step only performs tile generation when a tile is marked as pending an update and requested, which is a "generate-on-demand, calculate and deploy" model, significantly reducing computational and storage pressure.

[0050] Furthermore, a specific implementation of step S300 includes: during map browsing, sending a tile request based on the current viewport range, with the request parameters including the tile number. Upon receiving the request, first checking if the tile is marked as "pending update". If it is in the pending update state, calculating its corresponding geographic range (boundary box) based on the tile number, and then using the R-tree spatial index constructed in step S100, quickly querying all drainage network facility data (including point and line facilities) located within that geographic range from the spatial database. Next, dynamically geometrically simplifying the query results according to the target scaling level of the current request: for line facilities, adjusting the degree of geometric simplification according to the scaling level, with greater simplification at lower scaling levels; for point facilities, aggregation or thinning is performed at low scaling levels, while all point facilities are retained at high scaling levels. After completing the geometric simplification, the simplified data is encoded into a vector tile format and returned to the requester, while the tile is marked as "updated" and cached for direct use by subsequent identical requests.

[0051] S400 uses Web Worker to concurrently parse vector tile data and applies dynamic thinning based on screen space error threshold for rendering and display; when it receives an interaction command for a map facility, it performs coordinate inverse calculation and geographic tolerance buffering on the interaction points on the map, and queries the spatial database for the unsimplified spatial positioning data and attribute information corresponding to the facility within the tolerance range based on the R-tree spatial index.

[0052] In this embodiment, "Web Worker" is an independent thread running in the background of the browser, used to process computationally intensive tasks in parallel (such as decoding vector slices) to avoid blocking the rendering interaction of the main thread.

[0053] "Dynamic thinning based on screen space error threshold" refers to dynamically determining which facilities are displayed on the screen too small to be clearly identified based on the current view's scaling level and screen pixel density, and removing them from the rendering list, thereby significantly reducing the number of rendering operations while ensuring visual quality.

[0054] "Coordinate inverse calculation and geographic tolerance buffering" refers to converting the screen pixel coordinates clicked by the user into geographic coordinates through inverse projection transformation, and then constructing a tolerance buffer based on the conversion relationship between the pixel and the actual geographic distance at the current zoom level to compensate for the geometric position offset that may be caused by the simplified display at the front end, so as to ensure that the original facility records in the backend database can be accurately matched.

[0055] "Spatial positioning data and attribute information without geometric simplification" refers to complete, unsimplified, raw facility data stored in a spatial database, including precise coordinates and all attribute fields.

[0056] Understandably, traditional solutions often fail to provide precise clicks for queries after simplifying the display. This step, however, combines simplified rendering with precise querying, ensuring both smooth display of massive amounts of data and accurate attribute retrieval.

[0057] Furthermore, one specific implementation of step S400 includes: upon receiving vector tile data, starting multiple Web Worker threads for parallel decoding, with each Worker independently processing one or more tile data, decoding the binary vector tiles into point and line geometric features, converting them into a WebGL-compatible Buffer data format, and then transferring these Buffers to the main thread. Upon receiving the data, the main thread performs dynamic thinning based on a screen space error threshold: calculating the screen pixel density corresponding to the geographical unit distance according to the current zoom level, and setting a minimum resolvable distance. For line features, if the projection of their geometric feature length onto the screen is less than this resolvable distance, they are discarded; for point features, if the number of facilities within a unit pixel area exceeds a preset capacity threshold, they are sorted according to their preset importance weights, retaining only the higher-weighted portion for rendering. The dynamically thinned geometric features are then rendered using WebGL with hardware acceleration and displayed on the electronic map.

[0058] When an interactive command for a map facility is received (e.g., a user clicks on a location on the map), the screen pixel coordinates of the clicked location are obtained. These coordinates are then converted to geographic coordinates using the inverse projection transformation matrix of the current map view. Next, a geographic tolerance buffer (e.g., a rectangular area) is constructed centered on these geographic coordinates, based on the conversion relationship between pixels and actual geographic distance at the current zoom level. A query interface is called, using the geometric range of this tolerance buffer as a query parameter. The R-tree spatial index constructed in step S100 is used to retrieve the original facility records within this buffer area without any geometric simplification, and complete attribute information is obtained. The query results are displayed in a pop-up window or sidebar, enabling precise on-site interactive queries.

[0059] In summary, steps S100 to S400 complete a closed loop from data acquisition, index construction, real-time tile updates, on-demand dynamic slicing, concurrent rendering to precise interactive querying, realizing the "collection and presentation, and interactive presentation" of spatial positioning data of drainage pipe network.

[0060] Those skilled in the art will understand that the specific parameters in the above steps (such as time window length, minimum visual resolvable distance, pixel capacity threshold, etc.) can be adjusted according to the actual application scenario and hardware performance, and all fall within the protection scope of this invention.

[0061] In one alternative approach, the step of obtaining verified spatial location data characterizing the spatial location of drainage network facilities and the corresponding attribute information of the facilities in the aforementioned step S100 includes:

[0062] S110 receives a data stream compliant with the NMEA-0183 protocol transmitted via Bluetooth from a portable RTK terminal.

[0063] A "portable RTK terminal" refers to a lightweight device integrating a high-precision GNSS module. It can receive raw satellite observation data and differential correction streams broadcast from the cloud, and calculate centimeter-level positioning results through a built-in RTK engine. The "NMEA-0183 protocol" is a common GPS receiver data output format, using ASCII character streams, with each statement beginning with a "$" and ending with a newline character. The data stream is transmitted via Bluetooth BLE GATT protocol.

[0064] Furthermore, one specific implementation of step S110 includes: after the portable RTK terminal is powered on and completes RTK initialization, it continuously outputs NMEA-0183 statements at a set frequency. After establishing a connection via Bluetooth, it receives byte stream data in real time and searches for the start character "$" and the end character "\r\n" in the byte stream to extract the complete NMEA statement string.

[0065] S120. Parse the GPGGA statement in the data stream to obtain the positioning coordinates, and determine the validity of the positioning coordinates based on the pre-determined differential correction data in the GPGGA statement. When the determination is valid, use the corresponding positioning coordinates as valid spatial positioning data with centimeter-level accuracy.

[0066] In this embodiment, the "GPGGA statement" is a statement in the NMEA-0183 protocol used to output fixed data from the Global Positioning System, such as... Figure 3 As shown, it includes key fields such as time, latitude, longitude, positioning quality indication, number of satellites used, horizontal accuracy factor, altitude, geoid separation value, and differential correction age. "Differential correction data" refers to the differential correction age field in the GPGGA statement. This field represents the number of seconds since the last valid differential signal was received. If this value exists and is less than a preset threshold, it indicates that the current positioning result has undergone differential enhancement processing and has centimeter-level accuracy.

[0067] Understandably, relying solely on the coordinates output by the RTK terminal is insufficient to determine whether it is in a differential fixed solution state. However, by parsing the differential correction age in the GPGGA statement, usable high-precision positioning data can be easily and effectively filtered out, ensuring that the coordinates used for subsequent spatial indexing and tile generation are accurate and reliable.

[0068] Furthermore, one specific implementation of step S120 includes: traversing the received complete NMEA statements, identifying statements starting with "$GPGGA" or "$GNGGA"; splitting the statements by commas, extracting latitude, longitude, and elevation fields, and converting the coordinates in degree-minute format to geographic coordinates in decimal units; reading the differential correction age field, and if this field is not empty and the value is less than a preset threshold (e.g., 3 seconds), then the current positioning coordinates are determined to be valid and belong to a centimeter-level precision RTK fixed solution; otherwise, the data is discarded. For the valid coordinates, they are associated with the current timestamp and device identifier to form a standardized centimeter-level spatial positioning data record.

[0069] S130. Obtain the pre-input attribute information of the drainage network facility, wherein the attribute information includes at least one of the following: facility type, material, pipe diameter, flow direction, burial depth, and ownership unit.

[0070] In this embodiment, "pre-input attribute information" refers to the business description data related to the facility that is manually filled in or selected from a preset drop-down list through the data collection interface on the mobile terminal when arriving at the facility site (such as a manhole, drain outlet, or pipe section). "Facility type" is used to distinguish between manholes, rainwater grates, drain outlets, pipe sections, etc.; "Material" refers to the material of the pipe (such as concrete, PVC, HDPE, metal, etc.); "Pipe diameter" refers to the inner diameter or nominal diameter of the pipe; "Flow direction" indicates the direction of water flow (usually from upstream to downstream); "Buried depth" refers to the depth of the top or bottom of the pipe from the ground; "Ownership unit" refers to the unit responsible for the management or maintenance of the facility.

[0071] It should be noted that spatial positioning data only provides the location coordinates of the facilities, while drainage network asset management and operation and maintenance require a large number of attribute fields to support analysis (such as pipe diameter affecting flow capacity, and burial depth determining maintenance difficulty). This step associates attribute information with spatial positioning data in the same data acquisition stage, avoiding the internal integration errors caused by the separation of attributes and coordinates in the traditional process.

[0072] Furthermore, one specific implementation of step S130 includes: upon receiving valid spatial positioning data, automatically popping up or activating the attribute entry interface on the mobile terminal. The interface pre-sets commonly used attribute fields for drainage networks, among which "Facility Type" is a mandatory field, selectable via click buttons such as "Inspection Well, Rainwater Well, Drainage Outlet, Pipe Section," etc. For pipe sections, "Starting Well Number and Ending Well Number" must also be entered (or associated in subsequent topology construction steps). Other fields such as material (concrete / metal / plastic, etc.), pipe diameter (mm), flow direction (clockwise / counterclockwise), and burial depth (meters) can be entered via input boxes or sliders. Ownership units can be selected from a pre-imported unit list. All attribute information and the spatial positioning coordinates obtained in step S120 form a complete facility record in the local cache, assigned a temporary unique identifier, and uploaded to the spatial database when the time window is triggered. If the same facility needs to be collected multiple times (e.g., coordinates are collected first, then attributes are added), the records are merged and updated according to the identifier.

[0073] In summary, steps S110 to S130 together constitute a complete process for acquiring, validating, and associating attributes of high-precision spatial positioning data, providing an accurate and complete data foundation for subsequent index construction and real-time presentation.

[0074] In an alternative approach, the step of constructing a dynamic R-tree spatial index adapted to the point-like and linear facilities of the drainage network in step S100 includes:

[0075] S140. For drainage facilities that exhibit point-like characteristics in geographical space, construct the minimum bounding rectangle based on the spatial coordinates of the corresponding drainage facilities; for drainage facilities that exhibit line-like characteristics in geographical space, construct the minimum bounding rectangle based on their geometric bounding rectangle.

[0076] In this embodiment, the "minimum bounding rectangle" refers to the smallest axis-aligned rectangle that can completely contain a geographic feature, typically defined by the coordinates of its lower left and upper right corners. For point-like drainage facilities (such as manholes and drainage outlets), since their spatial extent is only a single coordinate point, this coordinate point is used as both the lower left and upper right corners of the minimum bounding rectangle, i.e., the x-coordinate of the rectangle. min =x max = Longitude, y min =y max =Latitude.

[0077] For drainage facilities with linear features (such as pipe segments), the bounding rectangle of its actual geometric shape is used as the minimum bounding rectangle. That is, the minimum longitude, maximum longitude, minimum latitude, and maximum latitude of all points on the line segment (including endpoints and intermediate inflection points) are taken as the boundary of the rectangle. For linear pipelines with multiple inflection points, the coordinates of all inflection points constituting the pipeline are traversed, and the minimum longitude coordinate x is calculated for each. min and maximum value x max Minimum value of latitude coordinate y min and maximum value y max Construct the minimum bounding rectangle as (x min ,y min ,x max ,y max ).

[0078] It should be noted that representing spatial elements of different dimensions as a minimum bounding rectangle is the foundation for constructing an R-tree spatial index. Whether point-like or linear, facilities can participate in node splitting and spatial queries within the tree structure through their MBR (Mean Backing Representation Principle), thereby achieving a unified index for heterogeneous spatial data.

[0079] Furthermore, a specific implementation of step S140 includes: whenever a drainage network facility data (including spatial positioning coordinates and attributes) is confirmed as valid and ready to be entered into the database, the geometric type of the facility is first determined.

[0080] If the facility type is identified as a point category such as "inspection well", "rainwater well", or "drainage outlet", then its latitude and longitude coordinates (lon,lat) are read, and the minimum bounding rectangle is constructed as (lon,lat,lon,lat).

[0081] If the facility type is identified as a linear category such as "pipe segment", then obtain the starting coordinates (lon1, lat1) and ending coordinates (lon2, lat2) of the pipe segment from the data, and calculate x. min =min(lon1,lon2), x max =max(lon1,lon2), y min =min(lat1,lat2), y max =max(lat1,lat2), constructing the minimum bounding rectangle as (x min ,y min ,x max ,y max ).

[0082] For a linear pipeline with multiple inflection points, the coordinates of all inflection points constituting the pipeline are traversed, and the minimum and maximum values ​​of longitude (X coordinate) and latitude (Y coordinate) are taken as the boundary of the pipeline's minimum bounding rectangle, i.e., the lower left corner of the rectangle is (x... min ,y min The coordinates of the upper right corner are (x max ,y max ).

[0083] Once the MBR is constructed, it will be transferred along with the facility data to the next step.

[0084] S150. The minimum bounding rectangle of each drainage facility and the storage location of the corresponding drainage facility data are used as a storage entry of the R-tree node. Through the node splitting and merging mechanism of the R-tree, they are dynamically inserted into the R-tree structure to construct the R-tree spatial index.

[0085] The R-tree structure includes a root node, internal nodes, and leaf nodes. The root node is used to index the entire spatial range. The internal nodes are located in the middle layer of the R-tree structure and are used to store the minimum bounding rectangle of their child nodes and pointers. The child nodes include at least one of internal nodes and leaf nodes. The leaf nodes are located at the bottom layer of the tree structure and are used to store the minimum bounding rectangle of the drainage facilities and the storage location of the corresponding drainage facility data.

[0086] In this embodiment, "R-tree" is a tree-shaped data structure used for spatial data indexing. Each node corresponds to a storage unit, and multiple entries are stored within each node. Each entry consists of two parts: a minimum bounding rectangle (MBR) and a pointer to a child node or data record.

[0087] Here, "child node" refers to the lower-level node of the current node, which can be an internal node or a leaf node; correspondingly, the current node can be called the "upper-level node" relative to its child nodes. However, for consistency, this embodiment uses "root node, internal node, leaf node" and "child node" to describe the hierarchical relationship.

[0088] "Dynamic insertion" refers to updating the R-tree structure in real time when new data arrives by selecting appropriate leaf nodes, inserting entries, splitting nodes and propagating upwards when necessary, without rebuilding the entire tree.

[0089] The "node splitting and merging mechanism" is used to maintain the balance of the tree: when the number of entries in a node exceeds the preset maximum capacity M, the entries of that node are split into two groups, forming two new nodes, and the MBRs of these two new nodes are inserted into the upper-level internal nodes of that node; if the upper-level internal nodes also overflow, the splitting continues upwards until the root node. When data deletion causes the number of entries in a node to fall below the minimum padding number m, node merging or re-insertion can be triggered.

[0090] Understandably, traditional spatial indexes, if built in batches, cannot adapt to scenarios where field data arrives in real time. This step employs a dynamic insertion mechanism, updating the R-tree immediately after each facility data entry is written, enabling subsequent tile queries and spatial retrieval to utilize the latest data instantly, thus meeting the real-time requirement of "collection equals indexing".

[0091] Furthermore, one specific implementation of step S150 includes: initializing an empty R-tree, setting the maximum number of entries M (e.g., 32) that each node can hold, and the minimum padding size m (e.g., M / 2). The root node is initially a leaf node. For each facility data to be inserted and its constructed minimum bounding rectangle MBR... new Given a storage location pointer (such as a database primary key or memory address), perform the following dynamic insert procedure:

[0092] First, select the leaf nodes. Specifically, start traversing from the root node and calculate the MBR in sequence. new After inserting each child node, the area increment of the MBR of that child node is calculated. The child node with the smallest area increment is selected to continue downwards until a leaf node is reached. Here, a child node refers to the lower-level node (which may be an internal node or a leaf node) pointed to by the current internal node.

[0093] It is understandable that the above description of selecting leaf nodes is based on the premise that the root node is not a leaf node. If the current node is a leaf node, it is selected directly.

[0094] Secondly, insert an entry, specifically: (MBR) newThe data pointer is added as a new entry to the selected leaf node.

[0095] Finally, check for node overflow and handle the split, specifically:

[0096] If the number of entries in the leaf node does not exceed M, the insertion is complete, and the MBR of the upper-level internal nodes is updated level by level (i.e., the MBR of the upper-level internal nodes is expanded to include the newly inserted MBR). new ).

[0097] If the number of entries exceeds M, then perform node splitting: Divide the M+1 entries of the node into two groups using a linear or quadratic splitting algorithm, minimizing the sum of the total areas of the new MBRs in each group. Then, generate two new leaf nodes and replace the original node with these two new nodes. Insert the MBRs and pointers of these two new nodes into the parent internal nodes of the leaf node.

[0098] If the upper-level internal node also overflows, the same splitting operation is recursively performed on the internal node: its entries are divided into two groups, generating two new internal nodes, and the MBR and pointers of these two new nodes are inserted into the internal node of the next higher level, and so on, until the root node.

[0099] If the root node also overflows, a new root node is generated, and the two new nodes after the original root node splits become the child nodes of the new root node, increasing the height of the tree by one level.

[0100] Throughout the splitting process, all nodes maintain the R-tree structure definition: the root node covers the entire data space; each internal node stores the MBR of all its child nodes and corresponding pointers, but does not store actual data; the leaf nodes store the minimum bounding rectangle of each facility and the corresponding data storage location.

[0101] Through the above dynamic insertion process, R-tree always reflects the spatial distribution of all drainage network facilities in the current spatial database, providing millisecond-level response capability for subsequent tile range queries and geographic tolerance buffer retrieval.

[0102] In summary, steps S140 to S150 construct minimum bounding rectangles for point-like and line-like facilities respectively, and utilize the dynamic node splitting and merging mechanism of R-tree to build a spatial index structure that updates in real time with the data, providing efficient spatial query support for the entire real-time interactive presentation method.

[0103] In an alternative approach, in step S200 above, when new data is detected being stored in the spatial database, the step of using a quadtree pyramid model to back-calculate one or more map tiles representing different zoom levels of the electronic map based on the spatial coordinates of the new data, and marking them as pending updates, includes:

[0104] S210. Capture the change information of newly stored data, including spatial coordinates and timestamps, through a database trigger, and store the change information in the cache database; after the preset time window ends, retrieve the spatial coordinates of all the changed data accumulated within the time window from the cache database.

[0105] In this embodiment, a "database trigger" is a stored program that is automatically executed when an insert, update, or delete operation occurs in a spatial database table. It is used to capture data change events in real time without the need for polling.

[0106] "Cache database" refers to a lightweight key-value storage system (such as Redis) with high-speed read and write performance, used to temporarily store change information that arrives in a short period of time, avoiding frequent direct access to the spatial database.

[0107] A "time window" refers to a fixed waiting period (e.g., 5 seconds) used to accumulate multiple changes that arrive within the window before batch processing them, thereby reducing the number of tile recalculations and update markings and lowering system overhead.

[0108] It should be noted that if tile inversion and marking are triggered immediately after each data entry is written, a large amount of redundant calculations will occur in high-frequency data acquisition scenarios (for example, when multiple points are continuously collected in the same area, the same set of tiles will be recalculated each time). By introducing a time window mechanism, the spatial coordinates of all changed data within the window are collected and processed uniformly, which can significantly reduce the server load.

[0109] Furthermore, one specific implementation of step S210 includes creating an INSERT or UPDATE trigger on the target table of the spatial database (e.g., a drainage network facility table). When new data is written, the trigger automatically captures the spatial coordinates (longitude, latitude) and operation timestamp of the data, and stores this information in a separate cache database (e.g., Redis) in key-value pairs. The key can contain the facility identifier and time window number, and the value is a coordinate string. Simultaneously, the system maintains a scheduled task that, every preset time window (e.g., 5 seconds), reads all accumulated change records within that window from the cache database, extracts the spatial coordinates from each record, and forms a list of coordinates to be processed. After reading, the entries corresponding to that window in the cache database are cleared to avoid duplicate processing.

[0110] S220. Based on the spatial coordinates, using the geographic coordinate-tile ID mapping function in the pre-built quadtree pyramid model, calculate the tile IDs belonging to the spatial coordinates at each scaling level, and obtain one or more map tiles affected by the spatial coordinates.

[0111] In this embodiment, the "quadrinode pyramid model" is a multi-scale spatial grid partitioning model that divides the electronic map from a global view (zoom level 0) to a street view (zoom level N) into multiple levels, with each level's Earth surface divided into 2... Z ×2 Z A tile grid (Z is the scaling level), each tile is uniquely identified by a triple (Z,X,Y), where X is the column number and Y is the row number.

[0112] The "Geographic Coordinate-Tile ID Mapping Function" refers to a function that calculates the tile number corresponding to a given geographic coordinate (lon, lat) and scaling level Z. Since each level divides the longitude range [-180°, 180°] into 2... Z The latitude range is also divided into 2 equal parts after being mapped using the Mercator projection. Z Therefore, X and Y can be obtained by calculating the equal division of coordinates along the longitude and latitude directions. For each scaling level, this mapping function can quickly determine the unique tile to which any spatial coordinate belongs.

[0113] Understandably, a spatial coordinate will fall onto different tiles at different zoom levels: the lower the zoom level (the more macroscopic the view), the larger the geographical area covered by the tiles, and the same coordinate may correspond to a few tiles; the higher the zoom level (the more microscopic the view), the finer the tile division, and the coordinate will correspond to tiles at more zoom levels. Therefore, it is necessary to traverse all zoom levels (e.g., from the smallest zoom level 0 to the largest zoom level Z). max To fully identify all affected tiles, the tile IDs at each level must be calculated separately.

[0114] Furthermore, one specific implementation of step S220 includes:

[0115] For each change data obtained in step S210, its spatial coordinates (lon, lat) are used to determine the preset zoom level range of the electronic map, for example, from the minimum level 0 to the maximum level Z. max (e.g., level 20). For each scaling level Z (0 ≤ Z ≤ Z), max The tile ID is determined using the mapping function in the quadtree pyramid model.

[0116] Calculate the tile column number X along the longitude direction: Map the longitude value from the geographical range to the column index range under the current level. Specifically, add 180° to the longitude to make its range [0°, 360°], then divide by 360° to get the proportion of that longitude in the global longitude span, then multiply this proportion by the total number of columns in the current level (i.e., 2 raised to the power of Z), and finally round down to get the integer column number X.

[0117] Calculating the tile row number Y in the latitude direction: Based on the Mercator projection system used in electronic maps, the latitude value is converted into a normalized coordinate value on the projection plane (range 0 to 1). Specifically, after converting the latitude (degrees) to radians, the corresponding projected coordinates are calculated using the Mercator projection formula, and then normalized to obtain the y-value. This y-value is then multiplied by the total number of rows in the current level (i.e., 2 raised to the power of Z), and finally rounded down to obtain the integer row number Y.

[0118] The above calculation yields the tile ID (Z, X, Y) for this coordinate at zoom level Z. This calculation is repeated for each zoom level to obtain the set of tile IDs affected by this spatial coordinate at all levels. All tile IDs generated by the current coordinate are then merged with the results generated by other coordinates within the time window, and deduplication is performed to form the final set of tiles affected by all the data changes in this update—that is, one or more map tiles affected by this spatial coordinate.

[0119] It is understood that this embodiment is only illustrated using Web Mercator as an example. In actual applications, the corresponding standard algorithm can be adopted according to the selected map service, as long as a definite mapping relationship between geographic coordinates and tile IDs can be established.

[0120] S230. All the obtained map tiles are combined into a tile set, and the map tiles in the tile set are marked as pending update. At the same time, the original cached data corresponding to the map tiles in the pending update state is cleared.

[0121] In this embodiment, "marked as pending update" means setting a status flag (e.g., "dirty" or "invalid") for a specified tile in the tile caching system or database, indicating that the vector slice data corresponding to the tile is outdated and needs to be regenerated based on the latest spatial database content.

[0122] "Clearing existing cached data" means deleting or removing previously generated slice files or memory caches for the tile to free up storage space and ensure that old data is not returned on the next request.

[0123] It's important to note that simply marking the state without immediately regenerating the tile avoids redundant computational overhead when updating the same tile multiple times within a short period. When the tile is actually requested, it is generated on demand based on the latest data, thus implementing a strategy of delayed computation and on-demand updates.

[0124] Furthermore, one specific implementation of step S230 includes:

[0125] The set of affected tile IDs obtained in step S220 is used as a list to be processed. For each tile ID in the list, the current status of the tile is queried in the tile status table (which can be stored in a cache database or in memory).

[0126] If the tile has not yet been marked as pending update, its status is set to "pending update" (e.g., a write key with a value of "dirty"), and an expiration time (e.g., 10 minutes) is set to avoid occupying state storage for an extended period. Simultaneously, if a generated vector tile cache file already exists for the tile (e.g., stored in a distributed file system or CDN), it is immediately deleted or marked as invalid. If the same tile is repeatedly hit by multiple changes within a time window, subsequent hits only require checking the status; there is no need to repeatedly clear the cache.

[0127] After all tiles are marked and the cache is cleared, the update process for this time window ends. When a subsequent request for a tile is received, the status of the tile is first checked: if the status is "pending update", the dynamic tile generation process in subsequent step S300 is triggered; if the status is "updated" or does not exist, the cached tile data is returned directly.

[0128] In summary, S210 to S230 achieve an efficient mechanism for incremental tile-level updates after spatial data is written by capturing changes through database triggers, accumulating coordinates over time windows, calculating tile IDs using quadtree mapping, marking tiles as pending updates, and clearing the cache. This lays the foundation for subsequent on-demand dynamic slicing.

[0129] In an alternative approach, the step S300 above, which involves dynamically geometrically simplifying the latest facility data corresponding to the geographic area in the spatial database based on the currently requested target scaling level and encoding it to generate vector tile data for the corresponding map tiles, includes:

[0130] S310. Based on the geographical range corresponding to the requested map tile, use the R-tree spatial index to query all drainage network facility data within that geographical range in the spatial database to obtain the set of facilities to be processed and perform coordinate projection transformation; according to the target scaling level, perform dynamic geometric simplification on the coordinate projection transformed facility data in the set of facilities to be processed, specifically:

[0131] In this embodiment, "requested map tile" refers to a request sent by the client with tile number (Z, X, Y) based on the current window range when browsing an electronic map.

[0132] "Geographic range" refers to the real-world geographical boundary covered by the tile, usually represented by a bounding box consisting of minimum longitude, maximum longitude, minimum latitude, and maximum latitude.

[0133] The “R-tree spatial index” is a dynamic spatial index constructed in the aforementioned step S150, used to quickly query all drainage network facility data falling within this geographical range.

[0134] "Coordinate projection transformation" refers to converting the original latitude and longitude coordinates (WGS84) of the facility into coordinate values ​​suitable for the current local coordinate system of the tile. Usually, it is first converted to Mercator projection coordinates and then mapped to pixel coordinates inside the tile.

[0135] "Dynamic geometric simplification" refers to applying different levels of simplification to linear and point structures based on the target scaling level, in order to balance data volume and expressive effect.

[0136] It's important to note that users have different needs for detail at different zoom levels: in the macro view (small zoom level), a large number of facilities are displayed overlapping, requiring significant simplification to reduce the amount of data; in the micro view (large zoom level), users need to view fine layouts and accurate locations, so more detail should be retained. Dynamic geometric simplification is designed based on this need.

[0137] Further, a specific implementation of step S310 includes: First, calculating the geographic bounding box corresponding to the requested map tile number (Z, X, Y). Then, using the R-tree spatial index constructed in step S150, quickly querying all drainage network facility data (including point facilities such as manholes and drainage outlets, and linear facilities such as pipe segments) within the bounding box to obtain the set of facilities to be processed. Next, performing coordinate projection transformation on each facility in the set: converting the original latitude and longitude coordinates (lon, lat) of the facility into local pixel coordinates in the current tile coordinate system. Specifically, first converting the latitude and longitude to Web Mercator projection coordinates, and then calculating the pixel position (px, py) of the coordinates within the tile based on the tile number and tile size (e.g., 256 pixels). After completing the coordinate transformation, dynamically geometrically simplifying the facility data in the set of facilities to be processed according to the current requested target scaling level Z, where different simplification strategies are used for linear facilities and point facilities, as described in steps S311 and S312 below.

[0138] S311. For linear facilities, the Douglas-Puk algorithm is used for simplification, and its distance tolerance ϵ is dynamically calculated based on the target scaling level Z. Among them, Z max The maximum zoom level preset for the electronic map; k is the basic tolerance coefficient.

[0139] In this embodiment, the "Douglas-Puk algorithm" is a commonly used algorithm for simplifying linear features. It retains the overall shape characteristics of linear features by recursively deleting points that deviate from the connecting line by a given tolerance.

[0140] "Distance tolerance ϵ" is a key parameter in this algorithm, representing the vertical distance threshold from a point to its corresponding line segment (formed by connecting two endpoints): points less than this threshold will be deleted, while points greater than or equal to this threshold will be retained.

[0141] The “basic tolerance factor k” is a preset constant (e.g., 0.5 meters) used to control the degree of simplification of the baseline.

[0142] Maximum scaling level Z max "" is the highest preset zoom level for electronic maps (e.g., level 20), at which the finest geometric details need to be preserved.

[0143] Understandably, the distance tolerance ϵ dynamically adjusts with the target scaling level Z: when Z is small (macro view), ϵ is large, resulting in high thinning and a significant reduction in data volume; as Z increases (micro view), ϵ decreases exponentially, gradually approaching 0, thus preserving more detail. This formula guarantees that at the highest scaling level Z... max Below, ϵ=k×2 0 =k, meaning only points with deviations less than the basic tolerance coefficient are deleted; at lower levels, ϵ increases exponentially, significantly enhancing the simplification.

[0144] Furthermore, one specific implementation of step S311 includes: for each linear facility (i.e., pipe segment) in the set of facilities to be processed, obtaining its original inflection point sequence (start point, intermediate inflection point, end point). Based on the current target scaling level Z, calculating the distance tolerance ϵ, where k is pre-set to 0.5 meters, and Z... max Set the value to 20. Then, call the Douglas-Puk algorithm: First, connect the start and end points of the line segment as a baseline, calculate the perpendicular distance from all intermediate vertices to this baseline, and find the maximum perpendicular distance d. max If d max If the distance is less than ϵ, then all intermediate vertices are deleted, keeping only the start and end points; otherwise, the line segment is divided into two parts by the point of maximum distance, and the above process is recursively performed on each part. The final output is a simplified sequence of vertices. This simplified linear facility data will be used for subsequent encoding.

[0145] S312. For dot-shaped facilities, when the target zoom level is less than the preset threshold, divide the current map tile into M×M sub-grids, and retain the dot-shaped facility with the highest weight in each sub-grid according to the preset importance weight of the facility; when the target zoom level is greater than or equal to the preset threshold, retain all dot-shaped facilities.

[0146] In this embodiment, the "preset threshold" is a zoom level value (such as level 15) used to distinguish between the macroscopic view and the microscopic view.

[0147] The "sub-grid" refers to a small rectangular area formed by equally dividing the current tile into M parts in both the horizontal and vertical directions (for example, when M is 4, 4×4 = 16 sub-grids are formed).

[0148] The "preset importance weight" is a value assigned to each type of dot-shaped facility in advance (for example, the weight of the main pipe inspection well is higher than that of the branch pipe inspection well, and the weight of the drain outlet is higher than that of the general rain grate), which is used to determine which facilities to retain preferentially when thinning is required.

[0149] It should be noted that in the macroscopic view (zoom level less than the preset threshold), dot-shaped facilities are densely overlapped, and rendering each one is neither necessary nor will seriously affect performance. Through grid aggregation, only the dot with the highest weight in each sub-grid is retained, which can significantly reduce the number of renderings while ensuring that important facilities are not omitted. In the microscopic view (zoom level reaches or exceeds the preset threshold), the user needs to view the specific well positions, and all dot-shaped facilities should be retained at this time to ensure the positioning accuracy.

[0150] Further, a specific implementation manner of step S312 includes: obtaining the target zoom level Z of the current request. If Z < T (T is the preset threshold, such as 15), perform aggregation and simplification: divide the current tile (with a size of 256×256 pixels) into M equal parts in both the horizontal and vertical directions (M is 4), forming M×M sub-grids, and each sub-grid corresponds to a 64×64 pixel area. For all dot-shaped facilities falling within the range of this sub-grid, read the preset importance weight of each facility (the weight value can be pre-stored in the attribute field, for example, the weight of the main pipe inspection well is 10, the weight of the branch pipe inspection well is 5, and the weight of the rain grate is 3), select the facility with the highest weight from them, and retain its coordinates and attributes; other dot-shaped facilities within the same sub-grid are discarded. If multiple facilities have the same weight, further selection can be made according to the time stamp or the distance from the center of the sub-grid. If Z ≥ T, no simplification is performed on the dot-shaped facilities, and all dot-shaped facilities within the geographical range of this tile are retained. After the simplification is completed, the data (coordinates and attributes) of the retained dot-shaped facilities are passed to the next step.

[0151] S320. Encode the dynamically geometrically simplified facility data into a vector tile format to generate vector tile data that matches the currently requested map tile.

[0152] In this embodiment, "vector tile format" refers to a binary format used for transmitting and storing vector geographic data, such as Mapbox Vector Tile (MVT) or GeoJSON Vector Tile. This format encodes geometric features such as points, lines, and polygons, along with their attributes, into a compact binary stream, supporting efficient parsing and rendering on the front end.

[0153] "Vector tile data" is an encoded block of binary data that can be returned directly as the response content for the tile request.

[0154] It should be noted that the encoding process requires writing the coordinates of the simplified geometric elements (which have been projected and transformed into local pixel coordinates of the tiles) into the corresponding layers and feature structures according to the vector tiling specifications, while retaining necessary attribute fields (such as facility type, pipe diameter, burial depth, etc.) for interactive queries on the front end.

[0155] Furthermore, one specific implementation of step S320 includes: creating a vector tile encoder (e.g., an MVT encoder) corresponding to the requested tile. First, a layer is defined within the tile, such as "point". layer "Used to store point-like facilities, "line layer "This is used to store linear facilities. For each linear facility simplified in step S311, the local pixel coordinates of its vertex sequence tiles are written into the line feature, along with attribute information (such as material, pipe diameter, flow direction, etc.). For each point facility simplified in step S312, its local pixel coordinates are written into the point feature, along with attribute information (such as facility type, burial depth, ownership unit, etc.). The encoder compresses and serializes all features according to the vector tile specification, generating a binary data block. Finally, this data block is returned as the response content of the map tile, and the cache is updated (if the tile was previously marked as "pending update," its status is simultaneously changed to "updated"). Thus, the complete generation process from the original database data to deliverable vector tile data is completed."

[0156] In summary, steps S310 to S320, through spatial range query, coordinate projection transformation, Douglas-Pock dynamic tolerance simplification for linear facilities, hierarchical adaptive mesh aggregation for point facilities, and final encoding into vector tile format, achieve on-demand dynamic generation of lightweight tile data that matches the target scaling level, providing efficient data support for real-time front-end rendering and interaction.

[0157] In an alternative approach, the steps in step S400 above, which involve concurrently parsing the vector tile data using a Web Worker and applying dynamic thinning based on a screen space error threshold before rendering and displaying, include:

[0158] S410: The vector tile data is decoded in parallel into point-like and line-like geometric features using Web Worker, and then converted into a Buffer data format adapted to WebGL. The request priority is determined based on the distance between the center point of each map tile in the same zoom level and the center point of the current view. The geometric features corresponding to high-priority map tiles are pushed to the main thread first to avoid blocking the main thread.

[0159] In this embodiment, "Web Worker" is an independent thread running in the background of the browser, used to perform computationally intensive tasks (such as decoding binary data and parsing geometric features), without blocking the main thread responsible for page interaction and rendering.

[0160] "Vector slice data" refers to the binary format data block (e.g., MVT format) generated in step S320, which contains point and line geometric features and their attribute information after dynamic geometric simplification.

[0161] "Buffer data format" refers to a binary array format (such as Float32Array) that WebGL can directly use to store graphics data required for rendering, such as vertex coordinates and colors.

[0162] "Request priority" refers to determining the processing order of tile data based on the distance between the tile's center point and the current view's center point: the closer the distance, the higher the priority, and the earlier its geometric elements are pushed to the main thread for rendering.

[0163] It's important to note that during electronic map browsing, tiles within and around the viewport have the greatest impact on user experience, while tiles far from the viewport are temporarily invisible. By controlling the decoding and push order through a priority queue, we can ensure that the area currently seen by the user is rendered first, avoiding delays in rendering tiles within the viewport due to loading distant tiles.

[0164] Furthermore, one specific implementation of step S410 includes: upon receiving a batch of vector tile data, creating an independent decoding task for each tile. The main thread maintains a priority queue, where each entry contains the tile number, the tile center coordinates, and the current view center coordinates. A priority score is calculated based on the Euclidean distance between the tile center and the view center, with a higher score for a smaller distance. Then, high-priority tile decoding tasks are assigned to idle Web Worker threads. The main thread distributes tasks containing tile request information to selected Worker threads via the postMessage interface. In this embodiment, if a Worker thread does not yet possess the binary data of the tile, it initiates a network request via the FetchAPI to obtain the tile's binary data (ArrayBuffer).

[0165] Each Worker independently performs the following operations: using a built-in vector tile decoder (such as a PBF decoder), it decodes the binary vector tile data into a set of point geometric features and a set of line geometric features, parsing the coordinate sequence (already local pixel coordinates of the tile) and attribute fields of each feature; then, it converts these geometric features into the Buffer data format required by WebGL, for example, writing the coordinates (x, y) of points and the vertex sequence of lines sequentially into a Float32Array. After decoding and conversion, the Worker transfers the Buffer data to the main thread via message passing (instead of copying), avoiding memory overhead.

[0166] The main thread receives these buffers in priority order and temporarily stores them in the rendering queue. When the viewport changes (such as panning or scaling), the priority is recalculated and the order of subsequent tasks is adjusted to ensure that the tile in the center of the current view is always processed first.

[0167] It's important to note that, to eliminate the overhead of copying large amounts of data into memory, when the Worker sends the parsed geometric data back to the main thread via `postMessage`, it employs a transferable object mechanism. This mechanism directly transfers the memory ownership of buffers such as `ArrayBuffer` to the main thread, and the Worker no longer retains a reference to that memory. This zero-copy mechanism significantly reduces the main thread's waiting time and peak memory usage, preventing UI stuttering caused by data copying.

[0168] S420. For the parsed point and line geometric features, perform dynamic thinning based on the screen space error threshold. Specifically:

[0169] The screen pixel density corresponding to the geographical unit distance is calculated by combining the target scaling level, and the preset minimum visual resolvable distance is matched. Linear geometric features whose geometric feature length and screen pixel density do not meet the visibility conditions are eliminated. For point geometric features that exceed the unit pixel area capacity threshold, they are sorted according to the preset importance weight and high-priority point geometric features are retained.

[0170] In this embodiment, the "screen space error threshold" refers to a preset pixel length (e.g., 2 pixels) used to determine whether a geographic feature is sufficiently clear and distinguishable when displayed on the screen. If the projected length of the geometric features of a feature on the screen is less than this threshold, it is considered that it cannot be effectively recognized by the user and should be discarded.

[0171] "Screen pixel density corresponding to geographic unit distance" refers to how many screen pixels per meter (or other geographic unit) on the map at the current zoom level.

[0172] For linear features, "geometric feature length" refers to the total length of its broken line (length in geographic space).

[0173] The "unit pixel area capacity threshold" refers to the maximum number of dot-shaped facilities that can be displayed within each pixel area. If this number is exceeded, thinning is required.

[0174] "Preset importance weight" refers to the pre-assigned values ​​to different types of point facilities (e.g., the main pipe inspection well has a higher weight than the branch pipe inspection well), which are used to prioritize the retention of more important facilities during dredging.

[0175] Understandably, the geometric elements obtained after decoding in step S410 have already undergone tile-level simplification (dynamic geometric simplification). However, during viewport rendering, the overlapping of multiple tiles may still result in overly dense display. Dynamic thinning of the screen space error threshold is a secondary screening from a visual perception perspective, further eliminating elements that are too small to be displayed on the screen or that are densely occluded, thereby improving rendering smoothness and visual effects.

[0176] Furthermore, one specific implementation of step S420 includes: dynamically thinning the geometric features that have been converted to Buffer format based on a screen space error threshold before rendering is performed.

[0177] First, calculate the screen pixel density D corresponding to the geographical unit distance at the current view level Z. pixel (For example, obtaining the number of pixels per meter at the current resolution through a map service interface). Simultaneously, to accommodate the thinning requirements of different scaling levels, the global thinning tolerance ϵ can be calculated based on the current target scaling level Z. client Its calculation formula is Among them, Z baseε is the preset baseline scaling level (e.g., level 15); α is the density control coefficient (e.g., 0.5); β is the base display tolerance (e.g., 1 pixel). This formula ensures that as the scaling level decreases (map shrinks), ε... client The data increases exponentially, thereby automatically enhancing the thinning effect and preventing browser lag caused by massive amounts of data.

[0178] For linear geometric features: set a fixed minimum visual resolvable distance δ. min (e.g., 2 pixels), or use the dynamically calculated ϵ as described above. client (i.e. ϵ) client (Z) is used as the judgment threshold (one of the two methods can be used, or it can be configured according to the actual scenario). Traverse each linear feature and calculate its geometric feature length L. geo (That is, the total length of the broken line in geographical space, in meters). If L geo ×D pixel <Selected threshold (ϵ) client or δ min If the projection length of the linear element on the screen is less than the resolvable distance, the user cannot clearly identify its direction, and it is removed; otherwise, it is retained.

[0179] For point-like geometric features: Calculate the average density ρ of point features per unit pixel area within the current viewport. If ρ exceeds the preset unit pixel area tolerance threshold ρ... max (e.g., 0.01 pixels / pixel) 2 If the weighted average is ρ, then weight-based thinning is triggered: all point-like facilities are sorted from high to low according to their preset importance weights, and only the top N facilities with the highest weights are retained, where N = ρ max ×Viewport pixel area.

[0180] Alternatively, another feasible strategy is to employ an aggregation method based on dynamic thinning tolerance: for all point facilities within the current tile, calculate the distance between each pair (in the tile's local coordinate system), and if the minimum distance is less than ϵ... client (Z) then these points are considered as aggregateable clusters, and only the point facility with the highest weight is retained in each cluster, while the rest are removed.

[0181] The two point-based thinning strategies described above can be selected or combined depending on the actual scenario. If ρ does not exceed the threshold and aggregation is not triggered, all point-based facilities are retained.

[0182] After the above dynamic thinning process, the remaining point and line geometric elements are the elements that actually need to be rendered.

[0183] S430 uses WebGL to perform hardware-accelerated rendering and display of point and line geometric features after dynamic thinning and filtering.

[0184] In this embodiment, "WebGL" is a JavaScript API used to render 2D and 3D graphics in a web browser. It can utilize GPU hardware acceleration to efficiently draw a large number of geometric shapes.

[0185] "Hardware-accelerated rendering" refers to offloading graphics computing tasks to the graphics processing unit (GPU), freeing up the central processing unit (CPU) and thus achieving higher frame rates and a smoother interactive experience.

[0186] It should be noted that the number of geometric features after thinning in step S420 has been significantly reduced, but it may still contain tens of thousands of points or lines. Drawing each element individually using the Canvas 2D API directly would lead to performance degradation, while WebGL can complete large-scale graphics rendering with extremely low overhead by uploading vertex data to the GPU buffer all at once and having the GPU process drawing commands in parallel.

[0187] Further, a specific implementation of step S430 includes: creating a WebGL rendering context and associating it with a canvas element during map view initialization. Several Vertex Buffer Objects (VBOs) are pre-allocated to store vertex data for point and line features. After dynamic thinning in step S420, all vertex coordinates of the retained point geometry (each point is a (x,y) pixel coordinate) are merged into a Float32Array and written to the point feature VBO; all vertex sequences of the line geometry (each line segment lists all its vertices in sequence) are merged into another Float32Array and written to the line feature VBO. Simultaneously, the corresponding shader is set, defining unified variables such as vertex position attributes and colors. During each frame rendering, the canvas is first cleared, then the VBOs are bound, and WebGL drawing commands (such as drawArrays) are called to draw point features (using point primitives) and line features (using line strips or line primitives) respectively. To distinguish different facility types, different colors and sizes can be set for facilities of different importance or types. Once rendering is complete, the map is displayed to the user. When the map viewport changes (such as panning or zooming), steps S410 to S430 are repeated to update the rendered content.

[0188] In an alternative approach, in step S400 above, the step of performing coordinate inversion and geographic tolerance buffering on the interaction points on the map when an interaction command for the map facility is received includes:

[0189] S440. Obtain the screen pixel coordinates corresponding to the interaction point, and convert the screen pixel coordinates into geographic coordinates using the inverse projection transformation matrix of the current view.

[0190] In this embodiment, an "interactive command" refers to an operation triggered when a user selects a location on the map canvas by clicking with a mouse, tapping on a touchscreen, or using other input methods.

[0191] "Screen pixel coordinates" refer to the coordinates of the interactive point on the browser canvas in pixels. The origin is usually the top left corner of the canvas, with the x-axis positive to the right and the y-axis positive downwards.

[0192] The "inverse projection transformation matrix" is a mathematical transformation matrix that maps points in the screen pixel coordinate system back to a geographic coordinate system (such as WGS84 latitude and longitude), denoted as M. −1 This matrix is ​​the inverse of the forward projection matrix from geographic coordinates to screen coordinates in the current state of the map view. It allows for the reverse calculation from screen coordinates to geographic coordinates.

[0193] It should be noted that, since map views may undergo transformations such as translation and scaling, the relationship between screen pixel coordinates and geographic coordinates is not a simple linear one. It is necessary to construct an inverse transformation matrix using the projection transformation parameters of the current view (including scaling level, view center point, resolution, etc.) in order to accurately obtain the corresponding geographic coordinates.

[0194] Furthermore, one specific implementation of step S440 includes: when an interaction instruction from a map facility is received, first obtaining the screen pixel coordinates (x, y, y) of the clicked location from the event object. screen ,y screen Then, obtain the inverse projection transformation matrix M of the current map view. −1 This matrix is ​​typically pre-calculated and stored during view initialization or each viewport change (pan, zoom). Using this matrix, screen coordinates can be converted to geographic coordinates using the following formula:

[0195] ;

[0196] Where (lon,lat) are the converted geographic coordinates. These coordinates represent the real-world location corresponding to the user's click location.

[0197] S450. Using the geographic coordinates as the center, construct a geographic tolerance buffer based on a preset pixel fault tolerance threshold to define a precise spatial retrieval range.

[0198] In this embodiment, the "preset pixel tolerance threshold" refers to an allowable error value in units of pixels (e.g., 1 pixel unit) to compensate for the positioning deviation that may occur when the user clicks on the touch screen or mouse, as well as the impact of the slight displacement of the geometric element position caused by the front-end simplified rendering.

[0199] "Geographic tolerance buffer" refers to a geographic range (usually a rectangle) centered on the converted geographic coordinates and extended outwards according to the pixel tolerance threshold and the conversion relationship between pixels and geographic distance at the current scaling level. This range is used to retrieve potentially clickable facilities in the backend database.

[0200] Understandably, when a user clicks, it's difficult to precisely align their finger or mouse pointer with an icon that's only a few pixels in size on the screen, and the displayed position after dynamic thinning may differ slightly from the original coordinates. By constructing a buffer with a certain pixel width, the hit rate can be significantly improved, ensuring that the user's intent is accurately recognized.

[0201] Further, a specific implementation of step S450 includes: obtaining the geographic coordinates (lon, lat) obtained in step S440. Obtaining the actual geographic distance (in meters) corresponding to one pixel at the current zoom level Z, denoted as resolution. Setting a preset pixel tolerance threshold τ (e.g., 1 pixel unit in each direction, i.e., τ=1), the half-width of the geographic tolerance buffer (the geographic offset in the longitude and latitude directions) is Δ=τ×resolution. Then, a rectangular geographic range is constructed centered at (lon, lat): [lon-Δ, lon+Δ]×[lat-Δ, lat+Δ]. This rectangle is the geographic tolerance buffer, used for subsequent spatial queries.

[0202] S460. Within the geographical range of the spatial tolerance buffer, use the R-tree spatial index to query the spatial database for unreduced spatial location data and attribute information that are located within this range and correspond to the drainage network facilities, and return the query results.

[0203] In this embodiment, "spatial positioning data and attribute information without geometric simplification" refers to the complete, unprocessed, raw facility records stored in the spatial database, including precise coordinates (raw centimeter-level accuracy) and all business attribute fields (such as facility type, material, pipe diameter, burial depth, ownership unit, etc.). Unlike the simplified data used in front-end rendering, this raw data is used for precise querying and detailed display.

[0204] "Unique identifier mapping" means that each graphic element rendered by the front end carries a globally unique identifier (FID). If a click operation directly hits a certain front end graphic element, there is no need to perform a backend space query. The original record can be located directly in the local cache or server index through this identifier, and the attribute pop-up window can be displayed in milliseconds.

[0205] It should be noted that the data displayed in the front-end rendering may have undergone dynamic geometric simplification and screen space thinning, and its position and quantity are no longer in their original state. If you directly click on a front-end graphic element and that element carries an FID, you can use the FID to quickly obtain the attribute first; if the graphic element is not hit (for example, clicking on a blank area or a linear feature that does not carry an FID), then the spatial tolerance buffer will be used for querying.

[0206] Furthermore, one specific implementation of step S460 includes: first determining whether the current interaction command has hit a certain primitive rendered by the front end.

[0207] If a match is found and the primitive carries a globally unique identifier (FID), the corresponding original facility record without geometric simplification is retrieved directly from the local cache or through the server-side index based on the FID, and the complete attribute information is returned for display, achieving millisecond-level response.

[0208] If no element is found (e.g., the clicked location has no element, or the clicked area has been thinned and removed), the following background spatial query process (i.e., spatial tolerance buffer query) is executed: The geographic tolerance buffer constructed in step S450 is used as the query range to construct a spatial query statement. Using the R-tree spatial index constructed in step S150, all drainage network facilities (including point facilities such as manholes and drainage outlets, and linear facilities such as pipe segments) are quickly retrieved from the spatial database, and facility records whose geometric locations fall within the buffer range are filtered out. For point facilities, it is determined whether their coordinates are within the buffer rectangle; for linear facilities, it is determined whether their polyline intersects with or contains the buffer rectangle. The query results return complete attribute information for each matched facility (such as facility ID, type, material, pipe diameter, flow direction, burial depth, ownership unit, etc.) and original spatial coordinates. If no facility falls within the buffer, an empty result is returned. Finally, the query results are returned to the front end in a structured data format (such as JSON), which the front end can display in a pop-up window or sidebar for users to view detailed information.

[0209] In summary, steps S440 to S460 achieve accurate acquisition of original facility data under a simplified rendering view by using the inverse transformation from screen coordinates to geographic coordinates (using the inverse projection transformation matrix formula), constructing a buffer based on pixel tolerance, prioritizing unique identifier mapping, and accurately querying the R-tree spatial index. This ensures the reliability and integrity of on-site interactive queries.

[0210] Figure 4 This diagram illustrates the structure of an embodiment of a real-time interactive presentation system 500 for spatial positioning data of a drainage pipe network provided by the present invention. Figure 4 As shown, the system 500 includes:

[0211] The portable RTK terminal 510 is used to receive satellite observation data and differential correction signals, calculate spatial positioning data, and transmit it in real time via Bluetooth in combination with the attribute information of drainage pipe network facilities.

[0212] The mobile application 520 is used to receive Bluetooth data streams transmitted by portable RTK terminals, parse GPGGA statements to extract positioning coordinates, verify the validity of the data based on differential correction data, and upload the verified spatial positioning data after associating it with attribute information.

[0213] Server 530 is used to receive data uploaded by the mobile application, build a dynamic R-tree spatial index, cache data and write it to the spatial database based on the time window mechanism; monitor changes in the spatial database, calculate the map tiles affected by the changed data and mark them as pending updates; respond to client requests for map tiles, and dynamically geometrically simplify the facility data within the corresponding geographical area according to the target scaling level to generate vector tile data.

[0214] Client 540 is used to receive and parse vector tile data, decode it in parallel into point and line geometric features through Web Worker, dynamically thin it based on the screen space error threshold, and then render it through WebGL; and respond to interactive commands on map facilities, perform coordinate inverse calculation and geographic tolerance buffering on interactive points, query the server for the corresponding unsimplified spatial positioning data and attribute information, and return the query results.

[0215] To facilitate understanding of the complete process of dynamic vector slicing generation and client-side rendering in this invention, as follows: Figure 5 As shown, Figure 5 This is a flowchart of a dynamic vector tile process. The process consists of three parts: a spatial database, a server (vector tiles), and a map client. In the diagram, the "server-to-vector tile" module corresponds to the server 530 of this invention, and the "map client" module corresponds to the client 540 of this invention.

[0216] Data flows from the spatial database and first enters the server-side (vector tiling) module, where it sequentially executes the "data query" and "vector tiling" steps: The data query step, based on a dynamic R-tree spatial index, quickly retrieves the corresponding drainage network facility data from the spatial database according to the geographic range requested by the map tiles; the vector tiling step, based on the requested target scaling level, dynamically geometrically simplifies the retrieved facility data and encodes it into adapted vector tile data. The generated vector tile data is sent to the map client module, where it sequentially executes the "dynamic rendering" and "WEBGL map display" steps: The dynamic rendering step uses WebWorker to decode the vector tile data in parallel, converting it into point and line geometric features, and dynamically thins it based on a screen space error threshold; the WEBGL map display step renders the dynamically thinned geometric features using WebGL hardware acceleration, ultimately achieving a visualized map presentation. This flowchart clearly illustrates the complete chain from data query and vector tile generation to efficient client-side rendering, intuitively demonstrating the technical characteristics of this invention: on-demand generation and layered rendering.

[0217] The technical solution in this embodiment achieves data synchronization through R-tree indexing and time windows, utilizes quadtree slicing on demand, combines Web Worker concurrent parsing and screen space thinning rendering, and achieves accurate attribute query through coordinate inverse calculation and tolerance buffering, which significantly improves the efficiency and interactive experience of on-site data collection in drainage pipe networks.

[0218] In one alternative approach, the server includes:

[0219] The spatial index construction module is used to construct the minimum bounding rectangle for point-like drainage facilities based on their spatial coordinates, and to construct the minimum bounding rectangle for linear drainage facilities based on their geometric bounding rectangle. The minimum bounding rectangle of each drainage facility and its corresponding data storage location are used as a storage entry for an R-tree node. A dynamic R-tree spatial index is constructed through node splitting and merging mechanisms.

[0220] The dynamic tile service module is used to query facility data using R-tree spatial index and perform coordinate projection transformation based on the geographic range corresponding to the requested map tile. For linear facilities, it uses the Douglas-Puk algorithm to perform dynamic distance tolerance simplification according to the target scaling level. For point facilities, it performs grid aggregation and retains importance weights according to the target scaling level, and encodes the simplified data into vector tile format.

[0221] In the aforementioned optional methods, a spatial indexing module constructs minimum bounding rectangles for point and linear facilities respectively and dynamically maintains the R-tree structure. Combined with the dynamic tiling service module, this R-tree spatial index is used to quickly query facility data within the target geographic area. Based on the target scaling level, the distance tolerance for linear facilities is dynamically adjusted using the Douglas-Pock algorithm; for point facilities, grid aggregation and importance weight retention are performed at low scaling levels, and all points are retained at high scaling levels. This achieves efficient end-to-end processing from data organization to tile generation, significantly reducing the tiling computation overhead for large-scale pipeline network data, while ensuring the rationality of data simplification and the integrity of the representation effect under different scaling levels.

[0222] In one alternative approach, the client includes:

[0223] The concurrent parsing module is used to decode vector tile data into point and line geometric features in parallel through Web Worker, convert it into a Buffer data format adapted to WebGL, and determine the request priority based on the distance between the center point of each map tile in the same zoom level and the center point of the current view, and push the geometric features corresponding to high-priority tiles to the main thread first.

[0224] The dynamic thinning rendering module is used to calculate the screen pixel density corresponding to the geographical unit distance by combining the target scaling level, remove linear geometric features whose geometric feature length and screen pixel density do not meet the preset minimum visual resolvable distance, and retain high-priority features after sorting point geometric features that exceed the unit pixel area capacity threshold according to the preset importance weight, and display them through hardware acceleration rendering via WebGL.

[0225] The interactive query module is used to obtain the screen pixel coordinates corresponding to the interactive point, convert them into geographic coordinates using the inverse projection transformation matrix of the current view, construct a geographic tolerance buffer based on the conversion relationship between the pixels of the current zoom level and the actual geographic distance, and use the R-tree spatial index to query the spatial positioning data and attribute information without geometric simplification within the tolerance range and return the query results.

[0226] To more intuitively demonstrate the core process of "WebGL chunk loading and rendering" on the client side of this invention, please refer to... Figure 6 , Figure 6This is a flowchart of the WebGL chunk loading and rendering process of the present invention, which is a detailed supplement to the client-side stage of the aforementioned dynamic vector tiling process. The process uses the "vector tiling service" (corresponding to the on-demand vector tiling generation service of the present invention) as the data source. On the client side, chunk loading is first achieved through the "concurrent request" and "data parsing" stages, corresponding to the operation of WebWorker parallel decoding of vector tiling data in S410. Multi-threaded processing of chunk data avoids blocking of the main thread, and supports "custom style" configuration to realize on-demand visualization of pipeline facilities (such as colors, icons, etc. corresponding to facility types). After parsing, the geometric elements are processed by "layered thinning" (corresponding to the dynamic thinning strategy based on screen space error threshold in S420, which removes redundant elements that cannot be clearly displayed on the screen) and "dynamic rendering". The map is then displayed smoothly through WebGL hardware acceleration to achieve smooth visualization. This clearly demonstrates the technical characteristics of the present invention, which achieves efficient parsing and smooth display of massive pipeline data through chunk loading, dynamic thinning and hardware rendering. It complements the aforementioned end-to-end vector tiling process and fully presents the full-link technical details of the present invention from data generation to client presentation.

[0227] In the aforementioned optional approach, the concurrent parsing module utilizes Web Worker to decode vector tiles in parallel and convert them into WebGL Buffer data format. Priority is determined based on the distance between the tile and the viewport center to avoid blocking the main thread. Combined with the dynamic thinning rendering module, which calculates pixel density based on screen space error threshold, removes invisible linear features, and filters overly dense point features according to importance weight before rendering with WebGL hardware acceleration, and the interactive query module converts screen click coordinates into geographic coordinates through inverse projection transformation and constructs a tolerance buffer, it uses R-tree to accurately query the unsimplified original facility data. This achieves smooth loading and rendering of massive pipeline network data, while balancing high performance under simplified view and accuracy of precise click queries, thus improving the user experience and decision reliability during on-site operations.

[0228] To more intuitively demonstrate the real-time update mechanism and its technical effects implemented by steps S200 and S300 in the aforementioned method, please refer to... Figure 7 , Figure 7This is a schematic diagram of the real-time update mechanism provided by the present invention. The diagram clearly illustrates the complete closed loop of the invention from data acquisition to front-end rendering: The high-precision drainage network spatial data obtained via RTK, corresponding to step S100, is stored in the spatial database after verification and attribute association; when the database data changes, the server (i.e., the aforementioned server 530) continuously monitors the data changes, triggers a data change event, and accurately marks the specific vector tiles affected by this change as pending updates, corresponding to the tile marking logic in step S200; when the client (i.e., the aforementioned client 540) browses the map and requests access to the marked changed area... The server will trigger targeted vector tile generation and updates, corresponding to the on-demand tile generation logic in step S300. After receiving the latest tile data, the client will dynamically thin and render it using WebGL to achieve real-time display, corresponding to the rendering process in step S400. The core advantage of this mechanism lies in "minimum area update". By accurately marking the affected tiles and generating and transmitting local data only when requested by the user, it avoids the redundant overhead of full updates, significantly reduces the server's computing load and network transmission pressure, and ensures the real-time performance of the front-end data, realizing an efficient closed-loop interaction of drainage network spatial data from collection to presentation.

[0229] The steps for implementing the corresponding functions of each parameter and module in the real-time interactive presentation system 500 for spatial positioning data of drainage pipe network described above can be referred to the parameters and steps in the embodiments of the real-time interactive presentation method for spatial positioning data of drainage pipe network described above, and will not be repeated here.

[0230] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for real-time interactive presentation of spatial positioning data of drainage pipe networks, used to realize real-time mapping and interactive verification of positioning data during on-site collection of drainage pipe network data, characterized in that, include: Obtain verified spatial location data representing the spatial location of drainage network facilities and the corresponding attribute information of the facilities, and construct a dynamic R-tree spatial index adapted to point-like and line-like facilities of the drainage network. Based on the time window mechanism, cache the data and write it to the spatial database. When new data is detected in the spatial database, based on the spatial coordinates of the new data, the quadtree pyramid model is used to back-calculate one or more map tiles that represent different zoom levels of the electronic map and are affected by the spatial coordinates, and these tiles are marked as pending updates. Upon receiving a request instruction for a map tile, if the requested map tile is in an pending update state, the system dynamically and geometrically simplifies the latest facility data for the corresponding geographic area in the spatial database according to the target scaling level of the current request, and encodes and generates vector tile data for the corresponding map tile. Web Worker is used to concurrently parse vector tile data and apply dynamic thinning based on screen space error threshold before rendering and display. When an interaction command for a map facility is received, the coordinates of the interaction points on the map are inversely calculated and geographic tolerance buffered. Based on the R-tree spatial index, the spatial location data and attribute information corresponding to the facility in the spatial database without geometric simplification are queried within the tolerance range.

2. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, The steps for obtaining verified spatial location data characterizing the spatial location of drainage pipe network facilities and the corresponding attribute information of the facilities include: Receives data streams compliant with the NMEA-0183 protocol transmitted via Bluetooth from portable RTK terminals; Parse the GPGGA statement in the data stream to obtain the positioning coordinates, and determine the validity of the positioning coordinates based on the pre-determined differential correction data in the GPGGA statement. When the positioning coordinates are determined to be valid, the corresponding positioning coordinates are used as valid spatial positioning data with centimeter-level accuracy. Obtain the pre-input attribute information of the drainage network facility, the attribute information including at least one of the following: facility type, material, pipe diameter, flow direction, burial depth, and ownership unit.

3. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, The steps for constructing a dynamic R-tree spatial index that adapts to both point-like and linear facilities in drainage pipe networks include: For drainage facilities that exhibit point-like characteristics in geographic space, the minimum bounding rectangle is constructed based on the spatial coordinates of the corresponding drainage facilities; for drainage facilities that exhibit line-like characteristics in geographic space, the minimum bounding rectangle is constructed based on their geometric bounding rectangle. The minimum bounding rectangle of each drainage facility and the storage location of the corresponding drainage facility data are used as a storage entry of the R-tree node. Through the node splitting and merging mechanism of the R-tree, they are dynamically inserted into the R-tree structure to construct the R-tree spatial index. The R-tree structure includes a root node, internal nodes, and leaf nodes. The root node is used to index the entire spatial range. The internal nodes are located in the middle layer of the R-tree structure and are used to store the minimum bounding rectangle of their child nodes and pointers. The child nodes include at least one of internal nodes and leaf nodes. The leaf nodes are located at the bottom layer of the tree structure and are used to store the minimum bounding rectangle of the drainage facilities and the storage location of the corresponding drainage facility data.

4. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, When new data is detected being stored in the spatial database, the steps involved in back-calculating one or more map tiles representing different zoom levels of the electronic map based on the spatial coordinates of the new data using a quadtree pyramid model, and marking them as pending updates, include: The database triggers capture changes to newly stored data, including spatial coordinates and timestamps, and store these changes in the cache database. After a preset time window ends, the database retrieves the spatial coordinates of all the changes accumulated during that time window from the cache database. Based on the spatial coordinates, the geographic coordinate-tile ID mapping function in the pre-built quadtree pyramid model is used to calculate the tile IDs belonging to the spatial coordinates at each scaling level, thereby obtaining one or more map tiles affected by the spatial coordinates. All the obtained map tiles are combined into a tile set, and the map tiles in the tile set are marked as pending updates. At the same time, the original cached data corresponding to the map tiles in the pending update state is cleared.

5. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, The steps of dynamically geometrically simplifying the latest facility data for the corresponding geographic area in the spatial database based on the currently requested target scaling level, and encoding it to generate vector tile data for the corresponding map tiles, include: Based on the geographical range corresponding to the requested map tile, the R-tree spatial index is used to query all drainage network facility data within that geographical range in the spatial database, obtaining a set of facilities to be processed and performing coordinate projection transformation; according to the target scaling level, dynamic geometric simplification is performed on the coordinate projection transformed facility data in the set of facilities to be processed, specifically: For linear facilities, the Douglas-Puk algorithm is simplified, and its distance tolerance ϵ is dynamically calculated based on the target scaling level Z. Among them, Z max The maximum zoom level preset for the electronic map; k is the basic tolerance factor; For point-like facilities, when the target zoom level is less than a preset threshold, the current map tile is divided into M×M sub-grids, and the point-like facility with the highest weight is retained in each sub-grid according to the preset importance weight of the facility; when the target zoom level is greater than or equal to the preset threshold, all point-like facilities are retained. The facility data, after dynamic geometric simplification, is encoded into a vector tile format to generate vector tile data that matches the currently requested map tiles.

6. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, The steps of concurrently parsing vector tile data using Web Workers and then rendering and displaying it after applying dynamic thinning based on a screen space error threshold include: The vector tile data is decoded in parallel into point and line geometric features using Web Workers, and then converted into a Buffer data format adapted to WebGL. The request priority is determined based on the distance between the center point of each map tile in the same zoom level and the center point of the current view. The geometric features corresponding to high-priority map tiles are pushed to the main thread first to avoid blocking the main thread. For the parsed point and line geometric features, perform dynamic thinning based on the screen space error threshold. Specifically: The screen pixel density corresponding to the geographical unit distance is calculated by combining the target scaling level, and the preset minimum visual resolvable distance is matched. Linear geometric features whose geometric feature length and screen pixel density do not meet the visibility conditions are eliminated. For point geometric features that exceed the unit pixel area capacity threshold, they are sorted according to the preset importance weight and high-priority point geometric features are retained. The point and line geometric features, after dynamic thinning and filtering, are then rendered and displayed using WebGL with hardware acceleration.

7. The real-time interactive presentation method for spatial positioning data of drainage pipe networks according to claim 1, characterized in that, When an interaction command for a map facility is received, the steps of performing coordinate inversion and geographic tolerance buffering on the interaction points on the map include: Obtain the screen pixel coordinates corresponding to the interaction point, and convert the screen pixel coordinates into geographic coordinates using the inverse projection transformation matrix of the current view; Using the geographic coordinates as the center, a geographic tolerance buffer is constructed in combination with a preset pixel fault tolerance threshold to define the precise spatial retrieval range; Within the geographical range of the spatial tolerance buffer, the R-tree spatial index is used to query the spatial database for unreduced spatial location data and attribute information that are located within this range and correspond to the drainage network facilities, and the query results are returned.

8. A real-time interactive presentation system for spatial positioning data of drainage pipe networks, used to realize real-time mapping and interactive verification of positioning data during on-site collection of drainage pipe network data, characterized in that, include: A portable RTK terminal is used to receive satellite observation data and differential correction signals, calculate spatial positioning data, and transmit it in real time via Bluetooth in combination with the attribute information of drainage pipe network facilities. The mobile application is used to receive Bluetooth data streams transmitted from portable RTK terminals, parse GPGGA statements to extract positioning coordinates, verify the validity of the data based on differential correction data, and upload the verified spatial positioning data after associating it with attribute information. The server is used to receive data uploaded by the mobile application, build a dynamic R-tree spatial index, and cache and write data to the spatial database based on a time window mechanism. Monitor changes in the spatial database, calculate the map tiles affected by the changes and mark them as pending updates; respond to client requests for map tiles, dynamically simplify the facility data within the corresponding geographic area according to the target zoom level, and generate vector tile data; The client is used to receive and parse vector tile data, decode it in parallel through Web Worker into point geometric features and line geometric features, dynamically thin it based on the screen space error threshold, and then render and display it through WebGL. In response to interactive commands on map facilities, the system performs coordinate inversion and geographic tolerance buffering on interactive points, queries the server for corresponding unreduced spatial positioning data and attribute information, and returns the query results.

9. The real-time interactive presentation system for spatial positioning data of drainage pipe networks according to claim 8, characterized in that, The server includes: The spatial index construction module is used to construct the minimum bounding rectangle for point-like drainage facilities based on their spatial coordinates, and to construct the minimum bounding rectangle for linear drainage facilities based on their geometric bounding rectangle. The minimum bounding rectangle of each drainage facility and its corresponding data storage location are used as a storage entry for an R-tree node. A dynamic R-tree spatial index is constructed through node splitting and merging mechanisms. The dynamic tile service module is used to query facility data using R-tree spatial index and perform coordinate projection transformation based on the geographic range corresponding to the requested map tile. For linear facilities, it uses the Douglas-Puk algorithm to perform dynamic distance tolerance simplification according to the target scaling level. For point facilities, it performs grid aggregation and retains importance weights according to the target scaling level, and encodes the simplified data into vector tile format.

10. The real-time interactive presentation system for spatial positioning data of drainage pipe networks according to claim 8, characterized in that, The client includes: The concurrent parsing module is used to decode vector tile data into point and line geometric features in parallel through Web Worker, convert it into a Buffer data format adapted to WebGL, and determine the request priority based on the distance between the center point of each map tile in the same zoom level and the center point of the current view, and push the geometric features corresponding to high-priority tiles to the main thread first. The dynamic thinning rendering module is used to calculate the screen pixel density corresponding to the geographical unit distance by combining the target scaling level, remove linear geometric features whose geometric feature length and screen pixel density do not meet the preset minimum visual resolvable distance, and retain high-priority features after sorting point geometric features that exceed the unit pixel area capacity threshold according to the preset importance weight, and display them through hardware acceleration rendering via WebGL. The interactive query module is used to obtain the screen pixel coordinates corresponding to the interactive point, convert them into geographic coordinates using the inverse projection transformation matrix of the current view, construct a geographic tolerance buffer based on the conversion relationship between the pixels of the current zoom level and the actual geographic distance, and use the R-tree spatial index to query the spatial positioning data and attribute information without geometric simplification within the tolerance range and return the query results.

Images