Large-scale dynamic flood risk map efficient ultra-low latency visualization method and system

Abstract

The application provides a large-scale dynamic flood risk map efficient ultra-low delay visualization method and system, which comprises the following steps: based on unstructured initial grid data, a plurality of static rendering fragments are generated; based on the flood evolution state, each static rendering fragment is divided into sub fragments, and the dynamic hydraulic result data of each static rendering fragment is obtained by performing streaming calculation on each calculation sub fragment; based on the viewport state information of the client, the push priority of each static rendering fragment is determined; and the dynamic hydraulic result data is pushed to the client according to the push priority, so that the client performs incremental rendering on the dynamic hydraulic result data based on the static rendering fragment, effectively breaks through the performance bottleneck of large-scale unstructured grid data rendering, breaks through the time sequence barrier of calculation and visualization, realizes the whole-process ultra-low delay visualization from model calculation to front-end display, and provides real-time, smooth and high-usable decision support for flood control emergency command scenes.

Description

Technical Field

[0001] This invention relates to the field of flood risk technology, and in particular to a method and system for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps. Background Technology

[0002] In the field of flood control and disaster reduction, dynamic flood risk maps are an important supporting tool for flood control emergency command and disaster assessment. With the application of high-precision hydrodynamic models and large-scale sensor networks, the spatiotemporal resolution and data volume of flood risk maps have increased dramatically, posing challenges to traditional visualization techniques.

[0003] Flood risk maps possess unique characteristics such as unstructured grids and topological dependencies, sudden updates, and extreme sensitivity to timeliness. Existing visualization technologies and processes have significant shortcomings in addressing these characteristics. On the one hand, large-scale grid data rendering suffers from "memory walls" and "bandwidth walls," making it impossible to effectively utilize GPUs (Graphics Processing Units) for acceleration and failing to meet visual smoothness requirements. On the other hand, the decision-making process remains in a blind box state for extended periods during computation, severely impacting the timeliness of emergency command. Summary of the Invention

[0004] This invention provides a highly efficient and ultra-low latency visualization method and system for large-scale dynamic flood risk maps, which solves the problem that existing technologies fail to meet visual fluency requirements but have poor emergency response timeliness.

[0005] This invention provides an efficient, ultra-low latency visualization method for large-scale dynamic flood risk maps, comprising: Obtain unstructured initial mesh data, and generate multiple static rendering fragments based on the initial mesh data; Based on the flood evolution state, each static rendering segment is divided into sub-segments, and each calculated sub-segment is subjected to streaming computation to obtain the dynamic hydraulic result data of each static rendering segment. Based on the client's viewport state information, the push priority of each static rendering fragment is determined; the dynamic hydraulic result data is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering fragment.

[0006] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided. The method involves dividing each static rendering segment into sub-segments based on the flood evolution state, and performing streaming computation on each of the resulting computational sub-segments to obtain dynamic hydraulic result data for each static rendering segment. This includes: The static rendering slices are evenly divided to obtain multiple initial calculation sub-slices corresponding to each static rendering slice; Within each static rendering segment, the mesh complexity factor of each mesh unit is determined based on the flood evolution state, and the average mesh complexity within the corresponding static rendering segment is determined based on the mesh complexity factor of each mesh unit. If the average complexity of the mesh in any static rendering segment exceeds a preset range, or the ratio of the increasing and decreasing submerged meshes in any initial computational sub-segment of any static rendering segment exceeds a preset ratio, then the static rendering segment is re-divided to obtain each computational sub-segment corresponding to the static rendering segment. Otherwise, the multiple initial computation sub-parts corresponding to any static rendering sub-part are used as each computation sub-part corresponding to any static rendering sub-part; Based on the dependencies between the computational sub-parts, streaming computation is performed on each computational sub-part to obtain the dynamic hydraulic result data of the corresponding static rendering sub-part.

[0007] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided, wherein the flood evolution state includes the grid density, water depth factor and flow velocity factor of each grid cell in the corresponding static rendering slice; The determination of the grid complexity factor for each grid cell based on the flood evolution state includes: Based on the simulation scenario corresponding to each grid cell, as well as the grid density, water depth factor and flow velocity factor of each grid cell, the grid complexity factor of each grid cell is determined. The step of re-dividing any static rendering fragment to obtain the computational sub-fragments corresponding to any static rendering fragment includes: Using the mesh cells with a mesh complexity factor greater than a first threshold within any static rendering segment as seeds, the region is expanded along the hydraulic connectivity relationship to generate each computational sub-segment corresponding to any static rendering segment; wherein the boundary of each computational sub-segment is located inside the boundary of its respective static rendering segment.

[0008] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided, wherein the method determines the push priority of each static rendering slice based on the viewport status information of the client; and pushes the dynamic hydraulic results data to the client according to the push priority, including: Based on the viewport state information and the mesh complexity factor of each mesh unit within each static rendering slice, the importance score of each mesh unit is determined. The importance scores of each grid cell are aggregated to obtain the importance scores of the corresponding static rendering segments. The push priority of each static rendering segment is determined based on the importance scores of each static rendering segment. Based on the push priority, the static rendering segments are sorted to obtain a push queue, and the push waiting time is determined based on the client's network status information. Based on the push waiting time and the push queue, a target push strategy is generated, and the dynamic hydraulic result data is pushed to the client according to the target push strategy.

[0009] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided, wherein determining the push waiting time based on the network status information of the client includes: Obtain the current queue length and upper limit of the queue capacity from the network status information, and determine the congestion coefficient based on the current queue length and the upper limit of the queue capacity; Based on the transmission network bandwidth, the cumulative amount of data to be pushed, and the congestion coefficient, the theoretical transmission waiting time is determined. Based on the theoretical transmission waiting time and the preset maximum waiting time, the push waiting time is determined.

[0010] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided, wherein the dynamic hydraulic result data is pushed to the client according to the push priority, so that the client performs incremental rendering on the received dynamic hydraulic result data based on the static rendering fragments, including: Extract the current viewpoint height from the viewport status information and determine the average side length of the grid for the static rendering slice corresponding to the dynamic hydraulic result data; Based on the current viewpoint height and the average side length of the grid, the target slice range width is determined, and based on the target slice range width and the dynamic hydraulic result data, a target vector slice is generated. The target vector slice is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received target vector slice based on the static rendering slice.

[0011] According to the present invention, a method for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps is provided, wherein pushing the target vector slice to the client according to the push priority includes: Based on the target vector slice, multi-level detail layer data is constructed, which includes basic simplification layer data and various detail layer data. Extract the difference data between each detail layer data and the basic simplified layer data; The difference data is geometrically compressed, and the basic simplified layer data and the compressed difference data are encapsulated into a progressive encoding format to obtain the vector slice to be pushed. The vector slice to be pushed is pushed to the client according to the push priority.

[0012] This invention also provides a high-efficiency, ultra-low-latency visualization system for large-scale dynamic flood risk maps, comprising: The fragmentation generation unit is used to acquire unstructured initial mesh data and generate multiple static rendering fragments based on the initial mesh data; The sub-slice partitioning unit is used to partition each static rendering slice into sub-slices based on the flood evolution state, and to perform streaming calculations on each partitioned calculation sub-slice to obtain the dynamic hydraulic result data of each static rendering slice. The data push unit is used to determine the push priority of each static rendering slice based on the viewport status information of the client; and push the dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering slice.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps as described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps as described above.

[0015] The present invention provides a method and system for efficient and ultra-low latency visualization of large-scale dynamic flood risk maps. By pre-generating fixed static rendering fragments as spatial containers and combining them with the flood evolution status for sub-fragmentation and streaming computation, the time-consuming serial computation is successfully transformed into fine-grained pipelined parallel streaming computation, enabling the simultaneous computation and viewing of flood data. At the same time, by combining the client viewport status information to determine the push priority and with the incremental rendering mechanism, the performance bottleneck of large-scale unstructured grid data rendering is effectively broken through, and the temporal barrier between computation and visualization is eliminated. This achieves ultra-low latency visualization of the entire process from model solution to front-end display, providing real-time, smooth and highly available decision support for flood control emergency command scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the efficient and ultra-low latency visualization method for large-scale dynamic flood risk maps provided by the present invention. Figure 2 This is a flowchart illustrating the static rendering fragment generation process provided by the present invention; Figure 3 This is a flowchart illustrating the sub-slice partitioning process provided by the present invention; Figure 4 This is a schematic diagram of the progressive rendering process of the flood risk map front end provided by the present invention; Figure 5 This is a schematic diagram of the system monitoring and automated operation and maintenance process provided by the present invention; Figure 6 This is a schematic diagram of the structure of the large-scale dynamic flood risk map high-efficiency ultra-low latency visualization system provided by the present invention; Figure 7 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0019] Dynamic flood risk maps are an important tool for flood control and disaster reduction decision-making, playing a crucial role in flood emergency command, disaster assessment, and evacuation. With the application of high-precision hydrodynamic models and large-scale sensor networks, the spatiotemporal resolution and data volume of flood risk maps have increased dramatically, posing a serious challenge to traditional visualization techniques.

[0020] Compared to conventional dynamic visualization scenarios, flood risk maps have unique characteristics. Firstly, to adapt to complex terrain, unstructured triangular meshes are widely used, with significantly different cell sizes, and hydraulic connectivity must be strictly maintained. Disruption of the topology during slicing can lead to misjudgments of the inundation area. Secondly, flood evolution progresses along the river channel, and data updates exhibit characteristics of localized bursts and overall sparseness, such as dramatic changes at breaches. This necessitates a push mechanism that can effectively distinguish between key and background areas. Thirdly, timeliness is extremely sensitive, with emergency decision-making windows measured in minutes, making the requirements for first-frame time and update latency far higher than in conventional scenarios.

[0021] However, existing visualization technologies and processes reveal significant shortcomings when addressing these unique challenges: First, large-scale grid data rendering suffers from both memory and bandwidth limitations. Modern hydrodynamic model results often reach gigabyte levels in size. Traditional WebGIS heavily relies on pre-tiled or server-side rendering, which cannot effectively utilize GPU acceleration when dealing with dynamically changing flood data (the fundamental reason being the contradiction between the dynamic characteristics of unstructured grids and the static caching of pre-tiled data). This easily leads to browser memory overflows or rendering frame rates below 5 FPS, failing to meet the visual smoothness requirements of emergency command. Second, existing technologies typically employ a serial model of full-basin calculation, result output, and visualization publication. Essentially, this lacks fine-grained decomposition and streaming scheduling strategies for computational tasks. High-precision simulations (such as 24-hour forecasts) often require tens of minutes of computation, leaving the decision-making process completely unprepared during this extended period, severely hindering the improvement of emergency response timeliness.

[0022] To address this, this invention provides an efficient and ultra-low latency visualization method for large-scale dynamic flood risk maps. It aims to resolve the conflict between dynamic changes in unstructured meshes and static caching by constructing fixed static rendering fragments as spatial index containers. Furthermore, it breaks down the temporal barriers of traditional serial computation through fine-grained sub-fragmentation and streaming computation. Combined with a client-side viewport-driven priority push and incremental rendering strategy, it achieves simultaneous computation and viewing while completely eliminating the dual performance bottlenecks of blind-box state at the decision-making end and large-scale mesh rendering. This provides high-frame-rate, smooth, and ultra-low latency visualization decision support for flood control emergency command.

[0023] Figure 1 This is a flowchart illustrating the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps provided by this invention. This method is applied to a large-scale dynamic flood risk map efficient ultra-low latency visualization system (hereinafter referred to as the system), such as... Figure 1 As shown, the method includes: Step 110: Obtain unstructured initial mesh data and generate multiple static rendering fragments based on the initial mesh data; Step 120: Based on the flood evolution state, divide each static rendering segment into sub-segments, and perform streaming calculations on each calculated sub-segment to obtain the dynamic hydraulic result data of each static rendering segment. Step 130: Based on the viewport status information of the client, determine the push priority of each static rendering fragment; push dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering fragment.

[0024] Specifically, in practical applications, to accurately simulate flood evolution and adapt to complex geographical features such as mountain undulations and river course, the system first needs to read unstructured grid data—the initial grid data—from existing databases, file systems, and external data sources to discretize complex terrain. Compared to traditional regular grids, unstructured grids, such as triangular and polygonal grids, have significantly different grid cell sizes, allowing for flexible adjustments based on actual terrain changes and accuracy requirements. This reduces the overall computational load while maintaining computational accuracy.

[0025] After obtaining the unstructured initial mesh data, considering the complex topological relationships and varying mesh cell sizes of the unstructured mesh, directly processing or rendering the global mesh would result in significant consumption of computational resources and prolonged latency. Therefore, in this embodiment of the invention, multiple static rendering fragments can be generated using the initial mesh data first. Figure 2 This is a flowchart illustrating the static rendering fragment generation process provided by the present invention, as shown below. Figure 2 As shown, the initial grid data can be preprocessed first, such as format unification and quality cleaning, to convert different types of multi-source grid formats into an internal standard format, remove invalid grids, repair broken connections, and generate clean grid data based on geometric and attribute checks. Next, a spatial index can be built using a specific spatial partitioning algorithm, such as quadtrees or grid partitioning, to allocate the processed grid cells to corresponding static rendering tiles. These static rendering tiles are geographically fixed and remain unchanged throughout the subsequent calculation and visualization process; each static rendering tile has a unique identifier and a fixed geographical extent, and all grid cells are assigned to their respective static rendering tiles during spatial index construction. This design provides a stable container for the organization, querying, and rendering of massive amounts of data, reducing system complexity.

[0026] In real-world flood scenarios, the dynamic process of floods, which evolves over time and space, often exhibits characteristics of localized outbreaks and overall sparse distribution. Therefore, the system acquires various characteristic indicators of this dynamic process in real time, namely the flood evolution status, such as hydrodynamic parameters like water depth, flow velocity, and inundation range at different times, as well as grid density that may affect flood evolution. Furthermore, to adapt to load variations during flood calculations and achieve parallel acceleration, the system performs fine-grained task decomposition within each static rendering partition, dividing each static rendering partition into sub-parts based on the flood evolution status. Each resulting computational sub-part can be independently scheduled and executed, effectively reducing the time consumed in a single computation.

[0027] Next, the system can perform streaming computation on each computational sub-slice. Streaming computation here refers to transforming the complex hydrodynamic calculation task of the entire large-scale watershed into a parallel computational pipeline that continuously outputs results. This breaks the traditional serial black-box mode of full-watershed computation, result output, and visualization, achieving pipelined parallel processing of the task. Through this on-demand computation mechanism, the system can continuously solve and output model results reflecting the flood evolution process, i.e., continuously obtain dynamic hydraulic result data from each static rendering sub-slice.

[0028] Following this, to achieve accurate on-demand data delivery and efficient rendering, the system acquires real-time viewport status information from the client, reflecting the user's focus areas and operational status on the visualization interface. This includes, for example, the geographical coverage of the current viewport, the viewport zoom level, and the user's roaming speed. Based on the client's viewport status information, the system determines the delivery priority for each static rendering slice. During this process, the system dynamically calculates priorities by comprehensively considering the client's focus and the actual situation of flood evolution, ensuring that high-risk areas, areas with drastic changes in water conditions, and areas of key user concern are given higher priority. Finally, the system pushes the corresponding dynamic hydraulic results data to the client according to the determined delivery priority of each static rendering slice, thereby maximizing the transmission value of decision-making data within limited network bandwidth.

[0029] Correspondingly, after receiving these dynamic hydraulic results data pushed according to their priority, the client does not need to re-render the entire large scene. Instead, it performs incremental rendering of the received dynamic hydraulic results data based on each static rendering tile. That is, since the geographical range of the underlying static rendering tiles, which act as containers, is fixed, the client can cache the tile data of inactive areas for a long time, and only use the incremental update mechanism to locally refresh the data of high-risk or drastically changed tiles. This mechanism greatly reduces the amount of network data transmission and the front-end rendering pressure, enabling the front-end to respond quickly and display the latest flood risk information smoothly when the user zooms or pans in the browser.

[0030] The present invention provides an efficient and ultra-low latency visualization method for large-scale dynamic flood risk maps. By pre-generating fixed static rendering fragments as spatial containers and combining them with the flood evolution status for sub-framing and streaming computation, the time-consuming serial computation is successfully transformed into fine-grained pipelined parallel streaming computation, enabling the simultaneous computation and viewing of flood data. At the same time, by combining the client viewport status information to determine the push priority and with the incremental rendering mechanism, the performance bottleneck of large-scale unstructured grid data rendering is effectively overcome, breaking down the temporal barriers between computation and visualization. This achieves ultra-low latency visualization of the entire process from model solution to front-end display, providing real-time, smooth, and highly available decision support for scenarios such as flood control emergency command.

[0031] Based on the above embodiments, step 120 includes: Each static rendering segment is evenly divided to obtain multiple initial calculation sub-segments corresponding to each static rendering segment; Within each static rendering slice, the mesh complexity factor of each mesh cell is determined based on the flood evolution state, and the average mesh complexity within the corresponding static rendering slice is determined based on the mesh complexity factor of each mesh cell. If the average complexity of the mesh in any static rendering segment exceeds a preset range, or the ratio of the submerged and engulfed meshes in any initial computational sub-segment of any static rendering segment exceeds a preset ratio, then the static rendering segment is re-divided to obtain the computational sub-segments corresponding to the static rendering segment; otherwise, the multiple initial computational sub-segments corresponding to the static rendering segment are used as the computational sub-segments corresponding to the static rendering segment. Based on the dependencies between the computational sub-parts, streaming computation is performed on each computational sub-part to obtain the dynamic hydraulic result data of the corresponding static rendering sub-part.

[0032] Specifically, Figure 3 This is a flowchart illustrating the sub-slice partitioning process provided by the present invention, as shown below. Figure 3As shown, the process of dividing each static rendering segment into sub-segments based on the flood evolution state, and performing stream computing on each of the resulting computational sub-segments to obtain the dynamic hydraulic results data for each static rendering segment specifically includes the following steps: In the initial stage of the computational task, to initially distribute the massive computational task across multiple nodes for parallel execution, the system uniformly divides each pre-built, spatially fixed static rendering partition. This division requires no prior terrain or hydrological data; it simply splits the static rendering partition equally according to geometric dimensions such as the number of grid cells. This operation quickly yields multiple initial computational sub-partitions corresponding to each static rendering partition. For example, each static rendering partition can be uniformly divided into several initial computational sub-partitions, such as 10,000 grid cells, thus building a basic parallel processing framework for subsequent dynamic streaming computation.

[0033] Next, due to the highly dynamic nature of flood evolution, such as rapid water flow and shifts in the wet-dry boundary, the computational resource consumption of different grid cells varies significantly at different times. Therefore, to accurately quantify this computational consumption, the system calculates a complexity factor for each grid cell based on its actual hydrological dynamics, i.e., the current flood evolution state, to characterize the degree of computational resource consumption. This is known as the grid complexity factor.

[0034] Subsequently, for each static rendering slice, the system can aggregate and evaluate the mesh complexity factors of all mesh units within it, such as by taking the average value, to obtain the average mesh complexity within each static rendering slice, thereby monitoring the current computational load level of each static rendering slice in real time.

[0035] Then, the system will make controlled dynamic adjustments based on the real-time monitored load changes. That is, the system sets a preset range to limit load fluctuations and a preset proportion to monitor drastic changes at the wet-dry boundary. For any static rendering sub-partition, if the change in the average mesh complexity of the sub-partition exceeds the preset range, such as 15%, or if the ratio of newly added or removed submerged meshes in any initial computation sub-partition (i.e., the proportion of newly added or removed submerged meshes to the total meshes in the initial computation sub-partition) exceeds the preset proportion, such as 10%, then if at least one of these two situations occurs, it means that the initial computation sub-partition pattern can no longer maintain a balanced computational load. In this case, the system will only initiate local adjustments within the static rendering sub-partition that triggered the above situation, that is, re-divide the static rendering sub-partition.

[0036] Here, the repartitioning process is strictly constrained to ensure that the boundaries of newly generated sub-partitions never cross the boundaries of their respective static rendering sub-partitions, and to ensure that the number of mesh cells and the total mesh complexity (obtained by multiplying the average mesh complexity by the number of mesh cells) within each sub-partition are controlled within the target range, such as the number of mesh cells being in the range of [5000, 50000]. The upper and lower limits of the total mesh complexity are dynamically configured according to the node performance, thereby obtaining each computational sub-partition corresponding to the static rendering sub-partition, so that computational resources are re-biased towards areas with drastic changes in water conditions.

[0037] Conversely, if the water conditions within the static rendering tile remain relatively stable during the flood evolution process, i.e., the above two situations are not triggered, in order to avoid the additional system performance overhead caused by frequent adjustments to the mesh structure, the system can keep the initial partitioning pattern unchanged and directly treat the multiple initial computational sub-tiles obtained through uniform partitioning as each computational sub-tile.

[0038] Finally, due to the upstream-to-downstream evolution of water flow, the divided computational sub-slices are not absolutely isolated spatially and hydraulically, but rather possess topological connectivity and a sequential data transfer order; that is, the computational sub-slices have dependencies. Therefore, the system can coordinate the computational order based on these dependencies, such as the directed acyclic graph dependencies between the computational sub-slices, and distribute computational tasks sequentially according to these dependencies. While ensuring that each computational sub-slice can execute in parallel and maintain hydraulic continuity, streaming computation is performed on each computational sub-slice to continuously and efficiently solve for the latest hydrological data, thereby obtaining the dynamic hydraulic results data for each statically rendered slice.

[0039] In this embodiment of the invention, by introducing a two-stage hierarchical partitioning strategy that combines initial uniform partitioning with controlled dynamic repartitioning, not only is rapid distribution of computational tasks and multi-node parallelism achieved in the early stages of model computation, but also the actual load dynamics can be keenly captured during the complex process of flood evolution, enabling adaptive local repartitioning. This effectively avoids the huge additional overhead caused by frequent global repartitioning and ensures that computing resources are always tilted towards areas with drastic changes in water conditions. At the same time, streaming scheduling computation is performed based on the topological dependencies between sub-partitions, which strictly guarantees the hydraulic continuity of flood evolution. Thus, while maintaining a continuous balance of computational load, the processing efficiency of model streaming computation and the ultra-low latency response capability of the system are greatly improved.

[0040] Based on the above embodiments, the flood evolution state includes the grid density, water depth factor, and flow velocity factor of each grid cell within the corresponding static rendering slice; The grid complexity factor for each grid cell is determined based on the flood evolution state, including: Based on the simulation scenario corresponding to each grid cell, as well as the grid density, water depth factor and flow velocity factor of each grid cell, the grid complexity factor of each grid cell is determined. The static rendering partition is re-partitioned to obtain the corresponding computational sub-partitions, including: Using the mesh cells with a mesh complexity factor greater than the first threshold within the static rendering segment as seeds, the region is expanded along the hydraulic connectivity relationship to generate each computational sub-segment corresponding to the static rendering segment; wherein the boundary of each computational sub-segment is located inside the boundary of its respective static rendering segment.

[0041] Specifically, the flood evolution state can include the grid density, depth factor, and velocity factor of each grid cell within each static rendering tile. In complex hydrodynamic simulations, the consumption of computational resources is not only related to the mere presence or absence of water flow, but is also constrained by a variety of dynamic and static attributes.

[0042] The grid density here reflects the fineness of spatial discretization; generally, the denser the grid, the greater the computational burden. The water depth factor characterizes the physical state of water depth, while the flow velocity factor reflects the intensity of water flow. Using these three as core indicators to characterize the evolution of a flood can comprehensively reflect the computational burden of a single grid.

[0043] When determining the grid complexity factor for each grid cell, the system considers the differences in the dominant factors affecting computational resource consumption across various simulation scenarios, such as urban built-up areas, mountainous watersheds, and plain river networks. For instance, urban built-up areas are sensitive to grid density and water depth, while mountainous watersheds are sensitive to flow velocity. Therefore, the system first needs to determine the simulation scenario corresponding to each grid cell. Based on this, and considering the scenario characteristics, different weights are assigned to the grid density, water depth factor, and flow velocity factor. Then, the grid complexity factor for each grid cell can be calculated based on the grid density, water depth factor, and flow velocity factor, along with their respective weights.

[0044] Here, by comprehensively calculating the simulated scenario constraints of the grid cells along with real-time grid density, water depth factor, and flow velocity factor, the grid complexity factor of each grid cell can be accurately determined. This factor, as a quantitative indicator, intuitively and objectively reflects the actual computational resource requirements of each grid cell for the system at the current moment.

[0045] When the above process determines that local adjustments are needed, that is, when any static rendering segment needs to be re-divided, the mesh cells with a mesh complexity factor greater than the first threshold in the static rendering segment can be used as seeds, and the region can be expanded along the hydraulic connectivity relationship to generate each computational sub-segment corresponding to the static rendering segment; wherein the boundary of each computational sub-segment is located inside the boundary of its respective static rendering segment.

[0046] In practice, the system first selects mesh cells with extremely high computational load (i.e., mesh complexity factors greater than a first threshold) within the static rendering partition, using these as seeds for region growth. Then, using these high-load seeds as centers, the system expands outwards along hydraulic connectivity (i.e., the topological paths through which water flows between adjacent mesh cells), gradually aggregating surrounding connected mesh cells into new computational regions, thus generating the computational sub-parts corresponding to the static rendering partition. Throughout the expansion and growth process, the system implements strict spatial constraints to ensure that the expansion stops immediately upon reaching the boundary of its respective static rendering partition, thereby guaranteeing that the boundaries of each computational sub-part are within the boundaries of its static rendering partition. This constraint ensures that the newly generated computational sub-parts do not cross the boundaries of the underlying fixed container.

[0047] In this embodiment of the invention, by introducing multi-dimensional features such as simulated scene, grid density, water depth factor, and flow velocity factor, the computational complexity of the grid is accurately quantified. At the same time, a hydraulic connectivity expansion method with high-complexity grid cells as seeds is used for dynamic repartitioning. This not only ensures that computing resources can be focused on key nodes with the most severe water conditions and the most complex terrain, but also, through strict boundary constraints, allows each computational sub-fragment to be embedded in a static rendering container. This design, which is both adaptive to the load and ensures the stability of the underlying spatial index, greatly avoids the additional overhead of cross-regional topology reconstruction and further improves the efficiency and system reliability of large-scale flood streaming computation.

[0048] Based on the above embodiments, the mesh complexity factor of each mesh cell It can be calculated using the following formula: In the formula, The normalized grid density has a value range of [value range missing]. ; The water depth factor has a range of values ​​of [value range missing]. ; The velocity factor has a range of values ​​of 100. The ratio of the grid velocity to the maximum velocity across the entire basin at the current moment is used. , and These are the weights corresponding to the grid density, water depth factor, and current velocity factor, respectively, and satisfy the following conditions: It can be determined through the analytic hierarchy process or by training with historical data.

[0049] Among them, water depth factor Piecewise function representation is used to accurately characterize the physical properties at the wet-dry interface where computational complexity increases significantly, while maintaining continuity: In the formula, The real-time water depth of the grid cell is expressed in meters (m). The wet and dry threshold is usually set to 0.1–0.2 m, and can be adjusted according to the model's accuracy and stability.

[0050] Among them, weight , and This reflects the relative contributions of grid density, water depth factor, and flow velocity factor to the computational load. In practical applications, these weights need to be calibrated based on the topographic features and hydrological characteristics of the watershed to ensure that the partitioning accurately reflects the actual consumption of computational resources. Specifically, in this embodiment of the invention, a historical data training method is used, by recording the data of each grid cell... The values ​​are obtained by fitting multiple linear regression, with the computation time as the target variable.

[0051] To facilitate practical application, this invention, based on the characteristics of different watersheds and through extensive simulation experiments and expert experience, summarizes the following reference weights (in practical applications, the corresponding reference weights can be selected according to the engineering scenario, or fine-tuned based on these), as shown in Table 1: Table 1: Reference Weight Values ​​Table To control the calculation In this embodiment of the invention, the following strategies are employed to limit the frequency of computation and repartitioning, taking into account both the value and dynamically adjusted resource consumption: (1) Time window control: The value is calculated once every 10 time steps, which means that the repartitioning interval is at least 10 time steps to avoid frequent adjustments due to small fluctuations.

[0052] (2) Threshold for variation range: The preset range and preset ratio used for repartitioning were determined through multiple sets of comparative experiments. For example, when the variation range is less than 10%, the impact of the computational load offset on the overall efficiency is negligible, and frequent adjustments will increase the overhead; when the variation range exceeds 20%, the uneven load has a significant impact on computational efficiency. Experiments show that using a combination of 10%, 20%, and 15% can achieve the best balance between computational efficiency and adjustment overhead.

[0053] (3) Locality constraint: Repartitioning only applies to the changed initial computational sub-partitions / mesh cells and their surroundings, without global repartitioning, thereby minimizing the cost of a single adjustment.

[0054] Through the aforementioned controlled dynamic adjustment mechanism, the system can maintain a balanced computing load throughout the flood evolution process, while keeping the additional overhead of repartitioning within an acceptable range, thus achieving efficient allocation of computing resources to areas with severe flooding and dense grids.

[0055] Based on the above embodiments, in step 130, the push priority of each static rendering fragment is determined based on the viewport status information of the client; dynamic hydraulic result data is pushed to the client according to the push priority, including: Based on viewport state information and the mesh complexity factor of each mesh unit within each static rendering slice, the importance score of each mesh unit is determined. The importance scores of each grid cell are aggregated to obtain the importance scores of the corresponding static rendering segments. Based on the importance scores of each static rendering segment, the push priority of each static rendering segment is determined. Based on the push priority, each static rendering slice is sorted to obtain the push queue, and the push waiting time is determined based on the client's network status information. Based on the push waiting time and push queue, a target push strategy is generated, and dynamic hydraulic result data is pushed to the client according to the target push strategy.

[0056] Specifically, the process of determining the push priority of each static rendering fragment based on the client's viewport status information, and then pushing dynamic hydraulic result data to the client according to the push priority, includes the following steps: First, the system extracts viewport status information, which primarily reflects the user's current visual focus and the distance of each grid cell from that center. Simultaneously, the system determines the grid complexity factor for each grid cell; the calculation process for this factor has been detailed above and will not be repeated here. The system then performs a comprehensive calculation, considering factors such as whether the water flow at the grid cell is turbulent, whether the water depth changes drastically, and whether the grid cell is currently within the user's magnified field of view, thereby accurately determining the importance score of each grid cell. This score quantifies the value of each grid cell to the user's decision-making at the current moment.

[0057] Next, since data transmission and rendering are based on static rendering shards as the basic unit, the system needs to convert the importance scores at the mesh level to the shard level to obtain the importance scores of each static rendering shard. Specifically, the system adopts a maximum value aggregation strategy, that is, instead of averaging or summing, it directly extracts the maximum value among the importance scores of all mesh units within a static rendering shard and uses this score as the importance score of the corresponding static rendering shard. The key to this design is that if a static rendering shard contains a very high-risk or highly concerned mesh unit, such as a recently occurred breach, the entire static rendering shard will receive a very high score. Subsequently, the system can determine the push priority of each static rendering shard based on its importance score; the higher the score, the higher the push priority.

[0058] The system then sorts the static rendering fragments, placing those with higher priority at the front and those with lower priority at the back, thus creating an ordered push queue. However, considering that blindly sending large amounts of data during network congestion can lead to browser lag or data loss, the system monitors the client's network status in real time, such as current round-trip latency, estimated bandwidth, and message queue congestion, and dynamically determines the push waiting time based on these network conditions. When network conditions are good, the push waiting time is shortened to improve real-time performance; when network congestion occurs, the push waiting time is appropriately extended to buffer traffic.

[0059] Finally, the system combines the sorted push queue with the calculated push waiting time to generate a target push strategy. This strategy clearly defines the optimal solution for "what to send first, what to send later," and "when to send." Ultimately, the system's push engine strictly follows the target push strategy to push dynamic hydraulic results data to the client.

[0060] In this embodiment of the invention, by integrating the viewport status reflecting user attention with the grid complexity factor reflecting the severity of the flood situation, and adopting a maximum value aggregation strategy, it is ensured that key static rendering fragments containing high-risk nodes can obtain the highest priority. At the same time, by combining the real-time network status of the client to dynamically control the push waiting time and generate a target push strategy, not only is the risk of instantaneous network congestion and server avalanche avoided, but also the most decision-making dynamic flood data can be pushed to the viewport of emergency command personnel in a timely and smooth manner under limited bandwidth conditions, which greatly improves the timeliness and practical experience of the system.

[0061] Based on the above embodiments, determining the push waiting time based on the client's network status information includes: Obtain the current queue length and maximum queue capacity of the message queue from the network status information, and determine the congestion coefficient based on the current queue length and maximum queue capacity; The theoretical transmission waiting time is determined based on the transmission network bandwidth, the cumulative amount of data to be pushed, and the congestion coefficient. The push waiting time is determined based on the theoretical transmission waiting time and the preset maximum waiting time.

[0062] Specifically, the process of determining the push waiting time based on network status information may include the following steps: To accurately and in real-time detect network congestion, the system continuously monitors the underlying network status information of communication links (such as WebSocket long connections). During this process, the system captures the status of message queues, retrieving the current queue length (i.e., the number of messages currently piled up in the queue that have not yet been acknowledged by the client, directly reflecting the real-time status of data lag and network latency) and the queue capacity limit (i.e., the maximum number of data packets that the communication protocol or memory allows to buffer). Subsequently, the system calculates the congestion coefficient based on the current queue length and the queue capacity limit. For example, it calculates the idle ratio of the message queue. , This is the current queue length. The idle ratio is used as the upper limit of the queue capacity and is then used as the congestion coefficient. The congestion coefficient, a dynamic adjustment factor between 0 and 1, intuitively reflects the actual throughput capacity and congestion level of the current network.

[0063] After identifying network congestion, the system further estimates the transmission network bandwidth of the communication link (i.e., the theoretical transmission rate of the network channel) and the amount of data accumulated in the buffer at the current moment, i.e., the accumulated data to be pushed. The system can use this accumulated data volume, along with the transmission network bandwidth and congestion coefficient, to correct the transmission time under ideal bandwidth, thus obtaining the theoretical transmission waiting time. This waiting time represents the estimated time required to completely send the accumulated data under the current real-world network congestion conditions. However, when facing extreme network fluctuations or sudden data surges, the theoretical transmission waiting time may be excessively long, causing the front-end view to experience prolonged "freezing" or stuttering. To prevent this, the system introduces a mandatory fallback parameter, namely a preset maximum waiting time. Finally, the system compares the calculated theoretical transmission waiting time with the maximum waiting time and takes the smaller of the two as the push waiting time.

[0064] In this embodiment of the invention, a push waiting mechanism that can adapt to network fluctuations is constructed by using queue length, accumulated data volume, and network bandwidth. This mechanism uses the stacking state of the message queue to calculate the congestion coefficient in real time. When the network is smooth, the waiting time is shortened to ensure the ultimate real-time performance. When the network is congested, the waiting time is extended adaptively to balance the network load. This effectively avoids network congestion and service avalanche caused by instantaneous data peaks, and ensures that the system can take into account both the timeliness of data push and the stability of the network environment during large-scale dynamic flood data transmission.

[0065] Based on the above embodiments, the system monitors the viewport status information of the client in real time. When the user is quickly roaming, it prioritizes pushing low-detail contour data to ensure smoothness; when the user is observing statically, it pushes data based on the priority of static rendering slices. The specific push timing can be calculated using the following formula: In the formula, For push notification waiting time; This represents the cumulative amount of data to be pushed. For transmitting network bandwidth; This is the congestion coefficient. , This is the current queue length. This represents the maximum queue capacity.

[0066] Importance score of grid cells It can be calculated using the following formula: In the formula, The grid complexity factor is the number of grid cells. This is a distance factor, representing the proximity of the grid cell to the visual center currently being focused on by the user; and These are the weights corresponding to the grid complexity factor and the distance factor, respectively, and satisfy the following conditions: It can be calibrated experimentally. For example, in urban flooding scenarios. , To balance computational load and user attention.

[0067] Among them, distance factor , The Euclidean distance from the grid cell to the visual center currently being focused on by the user. It is half the length of the current viewport diagonal; Fusion and The importance score obtained In the process, the contribution of hydrological dynamics and grid features to the importance was preserved, while user attention dimension was introduced, further reducing system overhead.

[0068] Importance score of static rendering fragments This can be expressed by the following formula: in, For the first static rendering slice The importance score of each grid cell.

[0069] Based on the above embodiments, dynamic hydraulic result data is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on static rendering fragments, including: Extract the current viewpoint height from the viewport status information and determine the average side length of the grid for the static rendering slice corresponding to the dynamic hydraulic results data; Based on the current viewpoint height and average grid side length, the target slice range width is determined. Based on the target slice range width and dynamic hydraulic results data, a target vector slice is generated. The target vector slice is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received target vector slice based on the static rendering slice.

[0070] Specifically, the process of pushing dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering of the received dynamic hydraulic result data based on static rendering fragments, includes the following steps: First, the system needs to accurately perceive the user's viewing angle, that is, extract the current viewpoint height from the viewport status information. This current viewpoint height typically reflects the user's zoom level on the browser or client interface, determining how close or far the user is observing the map—for example, zooming in to view local details or zooming out to view the overall macroscopic situation. Simultaneously, considering the significant differences in the size of unstructured grids under varying terrain complexity, the system also needs to determine the average side length of the grid for the static rendering tiles corresponding to the dynamic hydraulic results data. This average side length is a key scale parameter characterizing the grid density and discretization accuracy within a local area, used to quantify the terrain complexity and basic data density of that area.

[0071] Next, the system employs a spatial adaptive adjustment mechanism, which determines the target tile width based on the current viewpoint height and the average grid side length. For example, by combining the current viewpoint height, the average grid side length, the maximum zoom level, and specific empirical coefficients, a suitable tile geographic range width, i.e., the target tile range width, can be dynamically calculated.

[0072] Here, the target slice range width It can be calculated using the following formula: In the formula, This is an empirical coefficient, and its value range is... For high-risk areas such as urban built-up areas, the value is taken as follows: To ensure the precision of the slices; for low-risk areas such as farmland and woodland, values ​​are taken as follows: This reduces the number of requests by merging slices; the specific value can be configured according to actual business needs. Z is the average side length of the grid; Z is the current viewpoint height. The preset maximum scaling level, such as 18 levels.

[0073] Then, the tiling engine in the system extracts dynamic hydraulic result data of the grid cells within the corresponding geographical width from each static rendering tile. Under the premise of strictly maintaining hydraulic connectivity and topological relationships, it generates target vector tiles corresponding to each static rendering tile. The size and coverage of these dynamically generated target vector tiles can automatically scale and change with the zoom in and out of the user's viewpoint and the density of the underlying grid. In order to maintain hydraulic continuity across tiles, tiles can include a set proportion of boundary overlap.

[0074] Finally, the push engine can push the target vector slices corresponding to each static rendering slice to the client according to the push priority, thereby ensuring that slice data containing critical high-risk meshes can be prioritized for network bandwidth distribution.

[0075] After receiving these on-demand generated slice data, the client can directly perform incremental rendering on the received target vector slices based on the static rendering slices, since the underlying layer already has a fixed spatial container mapping relationship. The front-end WebGL rendering engine only needs to refresh the local state of dynamic hydraulic results such as water depth and flow velocity that have changed within the newly received target vector slice area, without having to redraw the global background.

[0076] In this embodiment of the invention, the traditional static slicing mode with fixed pixel size is abandoned, and an adaptive dynamic vector slicing mechanism based on the current viewpoint height and the average side length of the grid is introduced. This mechanism ensures that when the user zooms in to view a high-density grid area, the physical range of the slice automatically shrinks, effectively avoiding the problem of front-end decoding lag or memory overflow caused by too many unstructured grids in a single slice. When zooming out to view the whole area, the slices can be automatically merged, greatly reducing the number of concurrent network requests. This combination of adaptive slicing and incremental rendering significantly reduces the performance loss of rendering large-scale grid data, enabling the front-end rendering frame rate to remain stable at a very high level, such as above 30 FPS. This provides emergency command personnel with an extremely smooth visual operation experience during continuous panning and zooming interactive operations.

[0077] Based on the above embodiments, pushing target vector slices to the client according to push priority includes: Based on the target vector slices, multi-level detail layer data is constructed, which includes basic simplified layer data and data of each detail layer. Extract the difference data between each detailed layer and the basic simplified layer; Geometric compression is performed on the differential data, and the basic simplified layer data and the compressed differential data are encapsulated into a progressive encoding format to obtain the vector slice to be pushed. Vector slices to be pushed are pushed to the client according to the push priority.

[0078] Specifically, the process of pushing target vector slices to the client according to push priority may include the following steps: First, when transmitting large-scale dynamic vector tiles over a network, directly transmitting the complete high-precision mesh data would result in significant bandwidth pressure and severely slow down the first frame rendering time. Therefore, the system reconstructs the data organization architecture of the target vector tile, that is, it constructs multi-level detail layer data based on the target vector tile, for example, organizing it into three levels of detail layers from LOD0 to LOD2. This multi-level detail layer data presents a hierarchical structure from coarse to fine.

[0079] Here, the multi-level detail layer data includes basic simplified layer data and various detail layer data. Among them, the basic simplified layer data (such as LOD0 level) only retains the core outline of the slice, the macroscopic inundation range, and the most basic hydraulic topological features. Its data volume is extremely small, aiming to ensure that users can see the overall water situation as quickly as possible. On the other hand, the various detail layer data (such as LOD1, LOD2 levels) progressively add more delicate terrain undulations, finer grid boundaries, and high-precision hydrodynamic attribute information such as water depth and flow velocity.

[0080] Next, to avoid data redundancy and redundant transmission caused by multi-level data organization structures, the system no longer stores the full data of each level independently. Instead, it employs differential encoding to extract the differences between the data of each detail layer and the basic simplified layer. These differences refer to the additional mesh vertex coordinate offsets, increased local topological connectivity details, and incremental information on relevant hydraulic properties that are present in the high-precision detail layers compared to the low-precision basic simplified layers. By accurately extracting these differences, the system can eliminate redundant basic contour information between levels to the greatest extent possible.

[0081] Subsequently, to further compress the data volume to adapt to extreme network conditions in emergency scenarios, the system performs geometric compression on the differential data. In practice, the system can introduce efficient 3D geometric compression algorithms, such as the Draco geometric compression algorithm, to perform high-proportion binary compression on the extracted incremental mesh vertices and topological patches. Then, the system encapsulates the basic simplified layer data and the compressed differential data into a progressive encoding format. This progressive encoding format supports on-demand requests and incremental parsing. That is, it combines the lightweight base layer with highly compressed detail increments into one, ultimately obtaining the vector tile to be pushed. After this processing, the average data size of each tile can be reduced from the original 2.3MB to approximately 0.7MB.

[0082] Finally, after completing the lightweight encoding and encapsulation of the slice data, the push engine can push the vector slices to be pushed to the client according to the push priority. In the actual network transmission and rendering process, the system will prioritize pushing the basic simplified layer data with a very small volume to the client, so that the client can complete the first screen rendering in a very short time, such as within 0.8 seconds; then, when the user's view stays on a specific area or zooms in, such as zooming to the city center area, the system will dynamically request and receive subsequent incremental difference data according to the progressive encoding format, thereby realizing a smooth transition from coarse to fine and progressive incremental rendering on the front end.

[0083] In this embodiment of the invention, a progressive encoding format encapsulation of target vector slices is achieved by constructing multi-level detail layers and using a differentiated extraction strategy, combined with an advanced geometric compression algorithm. This fundamentally eliminates redundant information in multi-level data representation, resulting in a sharp decrease in the volume of single slice data. Furthermore, through a progressive transmission mode that prioritizes the distribution of basic simplification layers and incrementally pushes high-precision detail layers on demand, the latency of first-screen loading and first-frame rendering is greatly reduced. This approach balances the limited network bandwidth constraints in extreme emergency scenarios with the smooth interactive requirements of users for high-precision hydrological details during continuous zooming and panning.

[0084] Based on the above embodiments, and based on the dependencies between each computational sub-partition, streaming computation is performed on each computational sub-partition to obtain the dynamic hydraulic result data of the corresponding static rendering sub-partition, including: Based on the dependencies between each computational sub-segment, a directed acyclic graph scheduling sequence is constructed; Based on the grid complexity factor of each computational sub-partition, the computational sub-partitions on the critical path in the directed acyclic graph scheduling sequence are prioritized. According to the sorted directed acyclic graph scheduling sequence, streaming computation is performed on each computational sub-segment to obtain the dynamic hydraulic result data of the corresponding static rendering sub-segment.

[0085] Specifically, the process of performing streaming computation on each computation sub-partition based on the dependencies between them includes the following steps: In real-world terrain, water flow evolution follows a strict causal sequence; for example, water inevitably flows from upstream to downstream or to low-lying areas. Therefore, computational sub-slices cannot be computed arbitrarily and without order. Based on this, the system needs to first determine the order of computational sub-slices in terms of spatial topology and hydraulic energy transfer, i.e., the dependencies between them. Based on these dependencies, the system can construct a directed acyclic graph scheduling sequence. This scheduling sequence not only defines which downstream computational sub-slices must strictly wait for the upstream computational sub-slices to complete their data boundary condition calculations before starting, but also clearly outlines which computational sub-slices located in different branches and not interfering with each other can be safely handed over to the multi-core processor for multi-threaded parallel computation.

[0086] After constructing the Directed Acyclic Graph (DAG) scheduling sequence, the dependency chain with the longest processing time, directly determining the overall computation task completion time, is called the critical path. To prevent individual computationally intensive sub-parts from slowing down the overall progress, the system monitors the entire computation process in real time and prioritizes computational sub-parts on the critical path in the DAG scheduling sequence based on the grid complexity factor of each sub-part. Its core scheduling logic is to prioritize scheduling and allocating computational resources to high-load computational sub-parts with drastic water situation changes, extremely dense grids, and located on the critical path, such as computational sub-parts in the low-lying areas of the city center where the first flood occurred or around the breach, to ensure that these critical areas can be solved as early as possible.

[0087] Finally, after clarifying the parallel dependencies and scheduling priorities of all sub-shards, the system strictly follows the sorted directed acyclic graph scheduling sequence to distribute the shard computation tasks to the compute node cluster for execution. During execution, the system supports multi-threaded concurrent processing and node failure retries. That is, the system continuously performs streaming computation on each computation sub-shard. As the computation task pipeline progresses, the results of critical, high-risk shards are produced first, followed by subsequent shards, thereby continuously obtaining dynamic hydraulic result data for each static rendering shard.

[0088] In this embodiment of the invention, by constructing a directed acyclic graph scheduling sequence and introducing a priority sorting mechanism based on grid complexity factor on the critical path, not only are the complex hydraulic topological dependencies and multi-threaded parallel boundaries between each computational sub-slice clarified, but also the adaptive tilting of computing resources towards critical areas with severe water conditions and high load is realized. This completely breaks the performance bottleneck of traditional serial computing and ensures that the model results of high-risk areas with the highest decision-making value can be solved and produced first. As a result, the time for emergency command personnel to wait for the first frame of the image is compressed from the traditional tens of minutes to a few seconds, laying the core scheduling and data foundation for achieving ultra-low latency visualization.

[0089] Based on the above embodiments, in order to support the efficient and ultra-low latency visualization method for large-scale dynamic flood risk maps, the system has also undergone corresponding optimizations and designs in terms of underlying architecture, front-end rendering, and operation and maintenance support.

[0090] Figure 4 This is a schematic diagram of the progressive rendering process of the flood risk map front-end provided by the present invention. Figure 5 This is a schematic diagram of the system monitoring and automated operation and maintenance process provided by the present invention, such as... Figure 4 and Figure 5As shown, in terms of system architecture and deployment, this invention adopts a layered microservice architecture, divided into a data layer, a service layer, an application layer, and a deployment layer. All components are containerized and deployed, and managed uniformly through Kubernetes, supporting multi-cloud and hybrid cloud deployment modes, specifically including Kubernetes cluster deployment, database cluster deployment, middleware deployment, and application service deployment.

[0091] The core role of the Kubernetes cluster is as the foundation for system deployment and the elastic scheduling engine. It is responsible for unified automated management, service discovery, fault recovery, and horizontal scaling based on actual load for all containerized microservices, such as streaming computing and slicing engines. This ensures high availability, elastic scaling, and automated operation and maintenance during peak traffic periods. When deploying a Kubernetes cluster, a minimum of three nodes should be used, with each node configured with at least 8 cores and 16GB of memory.

[0092] The database cluster consists of PostgreSQL+PostGIS and ClickHouse clusters. Their function is to perform hybrid storage and efficient querying of heterogeneous data. PostgreSQL+PostGIS manages basic geographic information, such as regional divisions, river networks, and static spatial data, and leverages powerful spatial indexing capabilities to support complex spatial analysis. Simultaneously, the ClickHouse distributed cluster processes computationally generated time-series grid data, such as water level and flow velocity, utilizing its columnar storage and high-throughput write capabilities to achieve real-time ingestion of millions of data points per second and millisecond-level aggregation queries. Working together, they provide a solid data foundation for dynamic front-end rendering and real-time push notifications. The PostgreSQL+PostGIS cluster deployment uses PostgreSQL 14+PostGIS 3.2, configured as a master-slave replication cluster. The ClickHouse cluster is configured as a 3-node distributed cluster, with 2 replicas per node, using the ReplicatedMergeTree engine. To optimize query performance, a sorting key of (cell_id, timestamp) is created on the ClickHouse table `grid_data_local`, and materialized views are set for high-risk areas to pre-aggregate minute-level water level change data.

[0093] The role of middleware deployment is to build a high-performance data channel and state coordination layer for the system, specifically including three aspects: Redis cache cluster: As a high-speed cache and state buffer, it accelerates access to hot data (such as frequently accessed basic map tiles), manages distributed sessions, and buffers temporary results during sharding computation, significantly reducing the read pressure on the backend database; Kafka message queue: Acts as an asynchronous data pipeline and traffic buffer, responsible for transmitting massive amounts of real-time computation results between streaming computing services, result push services, and data storage layers, ensuring system stability even in the face of instantaneous data peaks, and achieving complete decoupling between the production and consumption ends; Monitoring and logging system: Constitutes an observability platform, collecting cluster and service performance indicators and operation logs in real time, providing data support for automatic scaling decisions, and helping operations personnel quickly locate faults.

[0094] The role of application service deployment is to carry core business logic and implement specific functional services. It breaks down the system into multiple independent microservice units. Each microservice unit is containerized using Docker and deployed and managed uniformly using Kubernetes. Specifically, these include: streaming-compute-service (responsible for sharded computation and push); tile-engine-service (responsible for dynamic tile generation); api-gateway (responsible for request routing and authentication); websocket-server (responsible for real-time data push); and geo-server-service (responsible for basic geographic information services). Through application service deployment, the system modularizes and decouples complex water conservancy professional calculations and visualization tasks, enabling each function to be developed, scaled, and maintained independently, thus supporting stable operation and rapid iteration under high concurrency scenarios.

[0095] See Figure 4As can be seen, in terms of progressive rendering of flood risk maps, the client can efficiently reconstruct the mesh and render flood inundation results in real time, ensuring smooth user interaction and real-time updates of flood data. Specifically, the front end receives dynamic vector tiles / target vector tiles pushed according to push priority via WebSocket, dynamically loads different levels of detail (LODs) based on the viewpoint position, and manages them through the LOD manager. Since static rendering tiles are fixed, the front end can cache target vector tiles in inactive areas for a long time, only updating the changed data of high-risk tiles received incrementally. In detail, target vector tiles are transmitted through a Kafka queue. The incremental update mechanism receives pushed data via WebSocket, only locally updating the static rendering tiles within the current user's viewport range, and then performing WebGL rendering to update the data. When high-priority static rendering tile data is received, the front end immediately updates the mesh data of the corresponding area; when the user zooms or pans, the LOD manager dynamically requests static rendering tiles of corresponding precision based on the viewpoint. The update frequency can be dynamically adjusted according to the user's operation status, with a maximum frame rate of 30 FPS in a static state.

[0096] See Figure 5 It is understood that system monitoring and automated operation and maintenance specifically includes four aspects: monitoring indicator system, visualization observation platform, automated operation and maintenance management, and log and alarm management. Specifically, a quantitative monitoring indicator system covering the entire chain can be established, including computing performance (sharding time / CPU / GPU utilization), network performance (WebSocket / push latency), storage performance (ClickHouse / disk I / O), and business indicators (concurrency / first frame time / update latency). Data is collected using the Prometheus collector, and the changing trends of these indicators and service call topology are centrally displayed on visualization observation platforms such as Grafana dashboards. Real-time alarms are triggered when indicators exceed thresholds.

[0097] Based on monitoring data, the system leverages native Kubernetes capabilities to achieve automated operation and maintenance management: Through Horizontal Pod Autoscaler (HPA), it automatically scales up and down microservice instance replicas in the Kubernetes cluster based on CPU utilization, memory utilization, and custom business metrics (such as WebSocket connection count and message queue backlog length). In the event of node or Pod failure, it automatically schedules to healthy nodes for failover and employs a rolling update strategy during version releases to ensure uninterrupted service. Simultaneously, it centrally collects container logs and transmits them to an alarm manager, supporting full-text search and identification of abnormal patterns and sending alarm notifications according to severity levels. Furthermore, the system is configured with scheduled backup and recovery plans, regularly backing up the PostgreSQL business database and key ClickHouse tables of the Kubernetes cluster and saving disaster recovery scripts. Regular drills verify data security and business continuity.

[0098] The efficient ultra-low latency visualization system for large-scale dynamic flood risk maps provided by this invention is described below. The efficient ultra-low latency visualization system for large-scale dynamic flood risk maps described below can be referred to in correspondence with the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps described above.

[0099] Figure 6 This is a schematic diagram of the structure of the high-efficiency, ultra-low latency visualization system for large-scale dynamic flood risk maps provided by this invention, as shown below. Figure 6 As shown, the system includes: The fragmentation generation unit 610 is used to acquire unstructured initial mesh data and generate multiple static rendering fragments based on the initial mesh data. The sub-slice partitioning unit 620 is used to partition each static rendering slice into sub-slices based on the flood evolution state, and to perform streaming calculations on each partitioned calculation sub-slice to obtain the dynamic hydraulic result data of each static rendering slice. The data push unit 630 is used to determine the push priority of each static rendering segment based on the viewport status information of the client; and push the dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering segment.

[0100] The large-scale dynamic flood risk map high-efficiency ultra-low latency visualization system provided by this invention uses pre-generated fixed static rendering fragments as spatial containers, and combines the flood evolution status to perform sub-fragmentation and streaming computation. It successfully transforms the time-consuming serial computation into fine-grained pipelined parallel streaming computation, realizing the simultaneous computation and viewing of flood data. At the same time, by combining the client viewport status information to determine the push priority and with the incremental rendering mechanism, it effectively breaks through the performance bottleneck of large-scale unstructured grid data rendering, breaks down the temporal barrier between computation and visualization, and realizes ultra-low latency visualization of the entire process from model solution to front-end display. It provides real-time, smooth and highly available decision support for scenarios such as flood control emergency command.

[0101] Based on the above embodiments, the sub-slice partitioning unit 620 is used for: The static rendering slices are evenly divided to obtain multiple initial calculation sub-slices corresponding to each static rendering slice; Within each static rendering segment, the mesh complexity factor of each mesh unit is determined based on the flood evolution state, and the average mesh complexity within the corresponding static rendering segment is determined based on the mesh complexity factor of each mesh unit. If the average complexity of the mesh in any static rendering segment exceeds the preset range, or the ratio of the increasing, decreasing, and submerged meshes in any initial computational sub-segment of any static rendering segment exceeds the preset ratio, then the static rendering segment is re-divided to obtain the computational sub-segments corresponding to the static rendering segment. Otherwise, the multiple initial computation sub-parts corresponding to the static rendering sub-part are used as the computation sub-parts corresponding to the static rendering sub-part; Based on the dependencies between the computational sub-parts, streaming computation is performed on each computational sub-part to obtain the dynamic hydraulic result data of the corresponding static rendering sub-part.

[0102] Based on the above embodiments, the flood evolution state includes the grid density, water depth factor, and flow velocity factor of each grid cell within the corresponding static rendering slice; Sub-slice partitioning unit 620 is used for: Based on the simulation scenario corresponding to each grid cell, as well as the grid density, water depth factor and flow velocity factor of each grid cell, the grid complexity factor of each grid cell is determined. Using the mesh cells with a mesh complexity factor greater than a first threshold within the static rendering segment as seeds, the region is expanded along the hydraulic connectivity relationship to generate each computational sub-segment corresponding to the static rendering segment; wherein the boundary of each computational sub-segment is located inside the boundary of its respective static rendering segment.

[0103] Based on the above embodiments, the data push unit 630 is used for: Based on the viewport state information and the mesh complexity factor of each mesh unit within each static rendering slice, the importance score of each mesh unit is determined. The importance scores of each grid cell are aggregated to obtain the importance scores of the corresponding static rendering segments. The push priority of each static rendering segment is determined based on the importance scores of each static rendering segment. Based on the push priority, the static rendering segments are sorted to obtain a push queue, and the push waiting time is determined based on the client's network status information. Based on the push waiting time and the push queue, a target push strategy is generated, and the dynamic hydraulic result data is pushed to the client according to the target push strategy.

[0104] Based on the above embodiments, the data push unit 630 is used for: Obtain the current queue length and upper limit of the queue capacity from the network status information, and determine the congestion coefficient based on the current queue length and the upper limit of the queue capacity; Based on the transmission network bandwidth, the cumulative amount of data to be pushed, and the congestion coefficient, the theoretical transmission waiting time is determined. Based on the theoretical transmission waiting time and the preset maximum waiting time, the push waiting time is determined.

[0105] Based on the above embodiments, the data push unit 630 is used for: Extract the current viewpoint height from the viewport status information and determine the average side length of the grid for the static rendering slice corresponding to the dynamic hydraulic result data; Based on the current viewpoint height and the average side length of the grid, the target slice range width is determined, and based on the target slice range width and the dynamic hydraulic result data, a target vector slice is generated. The target vector slice is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received target vector slice based on the static rendering slice.

[0106] Based on the above embodiments, the data push unit 630 is used for: Based on the target vector slice, multi-level detail layer data is constructed, which includes basic simplification layer data and various detail layer data. Extract the difference data between each detail layer data and the basic simplified layer data; The difference data is geometrically compressed, and the basic simplified layer data and the compressed difference data are encapsulated into a progressive encoding format to obtain the vector slice to be pushed. The vector slice to be pushed is pushed to the client according to the push priority.

[0107] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7 As shown, the electronic device may include a processor 710, a communications interface 720, a memory 730, and a communication bus 740. The processor 710, communications interface 720, and memory 730 communicate with each other via the communication bus 740. The processor 710 can call logical instructions in the memory 730 to execute an efficient, ultra-low latency visualization method for large-scale dynamic flood risk maps. This method includes: acquiring unstructured initial grid data and generating multiple static rendering tiles based on the initial grid data; dividing each static rendering tile into sub-tiles based on the flood evolution state, and performing streaming computation on each of the divided computational sub-tiles to obtain dynamic hydraulic result data for each static rendering tile; determining the push priority of each static rendering tile based on the client's viewport state information; and pushing the dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering tiles.

[0108] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, wherein when the program instructions are executed by a computer, the computer is able to execute the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps provided by the above methods, the method comprising: acquiring unstructured initial grid data, and generating multiple static rendering fragments based on the initial grid data; dividing each static rendering fragment into sub-fragments based on the flood evolution state, and performing streaming computation on each of the divided computational sub-fragments to obtain dynamic hydraulic result data of each static rendering fragment; determining the push priority of each static rendering fragment based on the viewport state information of the client; and pushing the dynamic hydraulic result data to the client according to the push priority, so that the client performs incremental rendering on the received dynamic hydraulic result data based on the static rendering fragments.

[0110] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements an efficient, ultra-low latency visualization method for large-scale dynamic flood risk maps provided by the methods described above. This method includes: acquiring unstructured initial grid data and generating multiple static rendering fragments based on the initial grid data; dividing each static rendering fragment into sub-fragments based on the flood evolution state, and performing streaming computation on each of the divided computational sub-fragments to obtain dynamic hydraulic result data for each static rendering fragment; determining the push priority of each static rendering fragment based on the viewport state information of the client; and pushing the dynamic hydraulic result data to the client according to the push priority, so that the client performs incremental rendering on the received dynamic hydraulic result data based on the static rendering fragments.

[0111] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A highly efficient and ultra-low latency visualization method for large-scale dynamic flood risk maps, characterized in that, include: Obtain unstructured initial mesh data, and generate multiple static rendering fragments based on the initial mesh data; Based on the flood evolution state, each static rendering segment is divided into sub-segments, and each calculated sub-segment is subjected to streaming computation to obtain the dynamic hydraulic result data of each static rendering segment. Based on the client's viewport status information, the push priority of each static rendering slice is determined; The dynamic hydraulic results data is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic results data based on the static rendering fragments.

2. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to claim 1, characterized in that, Based on the flood evolution state, each static rendering segment is divided into sub-segments, and each of the resulting computational sub-segments is subjected to streaming computation to obtain the dynamic hydraulic results data of each static rendering segment, including: The static rendering slices are evenly divided to obtain multiple initial calculation sub-slices corresponding to each static rendering slice; Within each static rendering segment, the mesh complexity factor of each mesh unit is determined based on the flood evolution state, and the average mesh complexity within the corresponding static rendering segment is determined based on the mesh complexity factor of each mesh unit. If the average complexity of the mesh in any static rendering segment exceeds a preset range, or the ratio of the increasing and decreasing submerged meshes in any initial computational sub-segment of any static rendering segment exceeds a preset ratio, then the static rendering segment is re-divided to obtain each computational sub-segment corresponding to the static rendering segment. Otherwise, the multiple initial computation sub-parts corresponding to any static rendering sub-part are used as each computation sub-part corresponding to any static rendering sub-part; Based on the dependencies between the computational sub-parts, streaming computation is performed on each computational sub-part to obtain the dynamic hydraulic result data of the corresponding static rendering sub-part.

3. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to claim 2, characterized in that, The flood evolution state includes the grid density, water depth factor, and flow velocity factor of each grid cell within the corresponding static rendering slice; The determination of the grid complexity factor for each grid cell based on the flood evolution state includes: Based on the simulation scenario corresponding to each grid cell, as well as the grid density, water depth factor and flow velocity factor of each grid cell, the grid complexity factor of each grid cell is determined. The step of re-dividing any static rendering fragment to obtain the computational sub-fragments corresponding to any static rendering fragment includes: Using the mesh cells with a mesh complexity factor greater than a first threshold within any static rendering segment as seeds, the region is expanded along the hydraulic connectivity relationship to generate each computational sub-segment corresponding to any static rendering segment; wherein the boundary of each computational sub-segment is located inside the boundary of its respective static rendering segment.

4. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to claim 2, characterized in that, The push priority of each static rendering slice is determined based on the viewport status information of the client. The dynamic hydraulic results data are pushed to the client according to the push priority, including: Based on the viewport state information and the mesh complexity factor of each mesh unit within each static rendering slice, the importance score of each mesh unit is determined. The importance scores of each grid cell are aggregated to obtain the importance scores of the corresponding static rendering segments. The push priority of each static rendering segment is determined based on the importance scores of each static rendering segment. Based on the push priority, the static rendering segments are sorted to obtain a push queue, and the push waiting time is determined based on the client's network status information. Based on the push waiting time and the push queue, a target push strategy is generated, and the dynamic hydraulic result data is pushed to the client according to the target push strategy.

5. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to claim 4, characterized in that, Determining the push waiting time based on the client's network status information includes: Obtain the current queue length and upper limit of the queue capacity from the network status information, and determine the congestion coefficient based on the current queue length and the upper limit of the queue capacity; Based on the transmission network bandwidth, the cumulative amount of data to be pushed, and the congestion coefficient, the theoretical transmission waiting time is determined. Based on the theoretical transmission waiting time and the preset maximum waiting time, the push waiting time is determined.

6. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to any one of claims 1 to 5, characterized in that, The step of pushing the dynamic hydraulic result data to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic result data based on the static rendering fragments, includes: Extract the current viewpoint height from the viewport status information and determine the average side length of the grid for the static rendering slice corresponding to the dynamic hydraulic result data; Based on the current viewpoint height and the average side length of the grid, the target slice range width is determined, and based on the target slice range width and the dynamic hydraulic result data, a target vector slice is generated. The target vector slice is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received target vector slice based on the static rendering slice.

7. The efficient ultra-low latency visualization method for large-scale dynamic flood risk maps according to claim 6, characterized in that, The step of pushing the target vector slice to the client according to the push priority includes: Based on the target vector slice, multi-level detail layer data is constructed, which includes basic simplification layer data and various detail layer data. Extract the difference data between each detail layer data and the basic simplified layer data; The difference data is geometrically compressed, and the basic simplified layer data and the compressed difference data are encapsulated into a progressive encoding format to obtain the vector slice to be pushed. The vector slice to be pushed is pushed to the client according to the push priority.

8. A high-efficiency, ultra-low latency visualization system for large-scale dynamic flood risk maps, characterized in that: include: The fragmentation generation unit is used to acquire unstructured initial mesh data and generate multiple static rendering fragments based on the initial mesh data; The sub-slice partitioning unit is used to partition each static rendering slice into sub-slices based on the flood evolution state, and to perform streaming calculations on each partitioned calculation sub-slice to obtain the dynamic hydraulic result data of each static rendering slice. The data push unit is used to determine the push priority of each static rendering fragment based on the viewport status information of the client. The dynamic hydraulic results data is pushed to the client according to the push priority, so that the client can perform incremental rendering on the received dynamic hydraulic results data based on the static rendering fragments.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the efficient ultra-low latency visualization method for large-scale dynamic flood risk maps as described in any one of claims 1 to 7.

Images