Three-dimensional geographic information visualization system supporting dynamic interaction

Abstract

The invention relates to the technical field of geographic information systems, particularly discloses a three-dimensional geographic information visualization system supporting dynamic interaction, and aims to solve the problems of high data processing delay, low resource utilization rate and event and object semantic mapping deficiency in the prior art. Comprising a real-time data stream access and preprocessing module used for receiving and standardizing heterogeneous sensor data in parallel; the space-time event stream processing engine is used for performing incremental state management and updating based on the geographic grid index; the geographic object semantic dynamic binding module is used for realizing automatic association between event data and scene object attributes through declarative rules; the distributed memory geographic state database is used for high-concurrency storage and query of object states; and the asynchronous non-blocking rendering pipeline is used for driving the graphics engine to perform local redrawing. According to the method and the device, millisecond-level response from data access to visual rendering is realized, and the resource utilization rate and the system usability are improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of geographic information systems, and specifically relates to a three-dimensional geographic information visualization system supporting dynamic interaction. BACKGROUND

[0002] Three-dimensional geographic information visualization is an important technical field of the intersection and integration of geographic information systems and computer graphics, which converts complex geographic spatial data into intuitive and interactive three-dimensional graphic models, and is widely used in key scenes such as city planning, environmental monitoring, emergency command, and intelligent transportation. Real-time interaction with high dynamics and low latency is the core goal of improving system practical value and user experience.

[0003] Currently, three-dimensional geographic information visualization systems supporting dynamic interaction mostly adopt a serial processing architecture of "data collection, conversion, storage, query, and rendering". This architecture has several obvious defects in actual application:

[0004] Firstly, the data processing delay is high, and the original data needs to be converted and persisted through multiple steps, which is difficult to meet the requirements of real-time scenes such as emergency command for millisecond-level response;

[0005] Secondly, the system resource utilization is low, and frequent full data update and redundant calculation lead to waste of computing and rendering resources;

[0006] Thirdly, there is a lack of automatic and dynamic event and geographic object semantic mapping mechanism, and users often need to manually establish the association by writing complex scripts, which not only increases the development and maintenance cost, but also introduces additional processing delay.

[0007] In view of the above problems, the present application provides a solution. SUMMARY

[0008] The purpose of the present application is to provide a three-dimensional geographic information visualization system supporting dynamic interaction to solve the problems of high data processing delay, low resource utilization, and lack of sensor event and geographic object semantic mapping capability caused by the serial processing architecture in the prior art.

[0009] The technical solution of the present application is a three-dimensional geographic information visualization system supporting dynamic interaction, which comprises:

[0010] A three-dimensional geographic information visualization system supporting dynamic interaction comprises:

[0011] A real-time data stream access and preprocessing module is used to receive and standardize heterogeneous sensor data in parallel, and output standardized event tuples with timestamps, spatial coordinates, and semantic labels;

[0012] A spatio-temporal event stream processing engine, connected with the real-time data stream access and preprocessing module, is configured to perform incremental state management and update on the standardized event tuples based on a geographic space index, and generate an incremental update instruction;

[0013] A geographic object semantic dynamic binding module, connected with the real-time data stream access and preprocessing module and the three-dimensional scene graph, is configured to automatically associate event data and scene object visualized attributes through a declarative rule;

[0014] A distributed memory geographic state database, connected with the spatio-temporal event stream processing engine, is configured to store and query the state of geographic objects in a high-concurrency manner in a memory storage mode;

[0015] An asynchronous non-blocking rendering pipeline, connected with the spatio-temporal event stream processing engine and the distributed memory geographic state database, is configured to drive a graphic rendering engine to perform partial redrawing according to the incremental update instruction;

[0016] A visualized interaction and feedback module, connected with the distributed memory geographic state database and the asynchronous non-blocking rendering pipeline, is configured to respond to user interaction and support user intervention data feedback to the real-time data stream access and preprocessing module.

[0017] Preferably, the real-time data stream access and preprocessing module comprises:

[0018] A plurality of protocol adapters arranged in parallel, configured to respectively parse sensor raw data in different formats;

[0019] A coordinate converter, configured to uniformly convert the parsed coordinate data to a system preset global three-dimensional rectangular coordinate system;

[0020] A semantic label attaching component, configured to attach semantic labels to data according to a preconfigured semantic label library, and generate the standardized event tuples.

[0021] Preferably, the spatio-temporal event stream processing engine comprises:

[0022] An incremental state management unit, constructed based on a geographic grid index or a dynamic hybrid tree space index, is configured to locate the space index unit according to event coordinates, traverse only the geographic objects within the space index unit, determine the objects to be updated through an influence determination function, calculate the state changes and generate the incremental update instruction, and simultaneously update the state of the corresponding objects in the distributed memory geographic state database.

[0023] Preferably, the geographic object semantic dynamic binding module maintains a semantic mapping rule library, wherein each rule contains a trigger condition based on an event semantic label and an execution action of assigning values to a target object attribute slot in the three-dimensional scene graph;

[0024] The geographic object semantic dynamic binding module listens to the standardized event tuple stream, directly operates the scene graph node attributes when matching rules, and realizes mapping of event data to visual attributes.

[0025] Preferably, the distributed memory geographic state database adopts a spatial index cooperating with the spatio-temporal event stream processing engine for data partitioning.

[0026] A hybrid index structure combining a hash table index and a spatial index is adopted in each data partition to support point query based on object identifiers and fast retrieval based on spatial ranges, and atomic operations are used to ensure state consistency.

[0027] Preferably, the asynchronous non-blocking rendering pipeline comprises:

[0028] A rendering task queue for asynchronously receiving and buffering rendering tasks encapsulated by the incremental update instructions;

[0029] A rendering work thread pool for obtaining tasks from the rendering task queue, obtaining the latest object state from the distributed memory geographic state database according to the rendering tasks, and calling a graphic API to update only the graphic resources corresponding to the objects whose states have changed;

[0030] A resource synchronization mechanism for safely exchanging the updated graphic resources into the frame cycle of the graphic rendering engine to realize partial redrawing.

[0031] Preferably, the visualization interaction and feedback module comprises:

[0032] An interaction analysis unit for analyzing user input operations into spatial query requests sent to the distributed memory geographic state database, and generating visual feedback instructions according to the returned results and submitting them to the asynchronous non-blocking rendering pipeline;

[0033] A feedback injection unit for encapsulating user correction operations on geographic object attributes as artificial intervention event tuples and feeding them back to the input end of the real-time data stream access and preprocessing module.

[0034] Preferably, the geographic grid index is an index for dividing a three-dimensional geographic space into regular cubic grid.

[0035] The dynamic hybrid tree spatial index is an adaptive tree-shaped spatial index dynamically subdivided according to object distribution.

[0036] In summary, the present application includes at least one of the following beneficial technical effects:

[0037] 1. This invention completely eliminates the reliance on traditional serial batch processing and disk databases by constructing a streaming processing architecture that integrates a real-time data stream access and preprocessing module, a spatiotemporal event stream processing engine, and a distributed in-memory geographic state database. The path of data from sensors to visualization is greatly shortened, and all core processing is completed in memory, eliminating the latency bottlenecks caused by disk input / output and complex data conversion. This enables the system to achieve millisecond-level end-to-end data updates and rendering responses, meeting the stringent real-time requirements of smart cities, real-time traffic monitoring, and other scenarios.

[0038] 2. This invention achieves precise and efficient utilization of computing and rendering resources through the incremental state management unit in the spatiotemporal event stream processing engine and the local redraw mechanism in the asynchronous non-blocking rendering pipeline. The system only processes and updates the object state within the geographic grid cells affected by events, and only redraws visual elements whose state has changed, avoiding redundant computing and wasted graphics processing unit resources caused by the traditional full update method. This optimization strategy based on geospatial locality enables the system to maintain a high frame rate and low resource consumption when processing high-frequency, small-scale update data streams, significantly improving the overall throughput and scalability of the system.

[0039] 3. This invention achieves automated and dynamic mapping between sensor events and 3D geographic object attributes through a geographic object semantic dynamic binding module and its declarative rule base. Users do not need to write and maintain complex script code; they only need to configure semantic tags and binding rules to establish the association between data streams and visualization attributes. This module directly manipulates scene graph nodes in the stream processing pipeline, bypassing the intermediate database layer, further reducing the latency of semantic mapping. It also significantly lowers the development, configuration, and maintenance threshold of the system, enhancing its usability and adaptability. Attached Figure Description

[0040] Fig. 1 This is a flowchart illustrating the three-dimensional geographic information visualization system supporting dynamic interaction proposed in this invention.

[0041] Fig. 2 This is a schematic diagram illustrating the collaborative operation of the spatiotemporal event stream processing engine and the asynchronous non-blocking rendering pipeline in this invention.

[0042] Fig. 3 This is a schematic diagram of the process from real-time data stream access to visual feedback in this invention. Detailed Implementation

[0043] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following description is provided in conjunction with the appendix. Figs. 1-3 The preferred embodiments are described in detail below based on specific implementations of the present invention.

[0044] Embodiment 1

[0045] Reference Fig. 1 As shown in the figure, the embodiment provides a three-dimensional geographic information visualization system supporting dynamic interaction, aiming to realize millisecond-level end-to-end processing from multi-source heterogeneous sensor data to dynamic visualization of three-dimensional scenes, and to overcome the problems of high inherent delay, low resource utilization and rigid semantic mapping of traditional serial batch processing architecture by constructing a full-memory, streaming processing, incremental updating and semantically bindable high-performance pipeline.

[0046] The physical deployment of the system of the present application follows the design principle of separating computation from rendering to realize resource specialization and load isolation.

[0047] Specifically, the system of the embodiment includes a real-time data stream access and preprocessing module, a spatio-temporal event stream processing engine, a geographic object semantic dynamic binding module, and a distributed memory geographic state database, which are integrated and deployed on the same high-performance computing node equipped with large-scale high-speed memory, such as DDR4 or DDR5 memory with a capacity of no less than 128 gigabytes, and running an optimized memory computing engine, such as Apache Flink or a similar custom event stream processing framework.

[0048] In addition, data exchange between all modules, including the transfer of standardized event tuples, the generation and forwarding of incremental update instructions, is completed through shared memory areas or zero-copy memory channels, thereby avoiding the system call overhead caused by cross-process communication and the physical delay introduced by disk I / O operations, ensuring efficient and low-latency data flow in the computing phase.

[0049] On the other hand, an asynchronous non-blocking rendering pipeline is independently deployed on one or more dedicated rendering nodes equipped with high-performance graphics processors (GPUs), and the rendering nodes and the above-mentioned computing nodes are interconnected through low-latency, high-bandwidth networks, such as Ethernet or InfiniBand networks with a rate of no less than 10 Gbps; in terms of network transmission content, the system of the present example is strictly optimized, only transmitting highly compressed incremental update instruction sequences and rendering task packages, and not transmitting large three-dimensional model data, thereby avoiding the network from becoming a performance bottleneck and ensuring that rendering instructions can quickly reach the rendering nodes and trigger local redrawing.

[0050] As can be seen, the above deployment of the system of the present example clearly separates the computation and rendering in the hardware architecture, ensuring both high-speed memory access and low-latency exchange in the data processing phase, and enabling parallel execution of graphics rendering relying on dedicated GPU resources, thus providing a solid underlying support for the system to achieve millisecond-level end-to-end response.

[0051] Based on this, in order to make the specific implementation of the system of the embodiment more clear, the common working process and data flow path between the modules of the embodiment will be described in detail below.

[0052] S1: Real-time data stream access and preprocessing module as the only entrance for the system to interact with the external physical world, its role is to receive, analyze and standardize the raw data stream from multiple heterogeneous sensors in parallel.

[0053] In the embodiment, it is described in detail by including the following steps, specifically:

[0054] S101: Parallel reception and protocol analysis.

[0055] The real-time data stream access and preprocessing module includes multiple parallel protocol adapter subcomponents, each protocol adapter usually runs in the form of an independent software thread or coroutine, and is specially used to listen and process sensor data streams of a specific network protocol or data format.

[0056] Among them, the protocol adapter includes but is not limited to:

[0057] NMEA 0183 protocol adapter for receiving global positioning system trajectory data;

[0058] MQTT protocol adapter for accessing various Internet of Things (IoT) sensors, suitable for low-bandwidth, asynchronous communication scenarios;

[0059] DSRC or C-V2X protocol adapter for processing vehicle-mounted unit data, supporting real-time message exchange in vehicle-road cooperation;

[0060] TCP custom binary stream adapter for receiving remote sensing data streams, suitable for high-speed, high-flow remote sensing data transmission.

[0061] Each protocol adapter independently manages its network connection with the data source, has a line reconnection mechanism, and each protocol adapter internally implements a corresponding syntax parser, which can parse the incoming raw byte stream or text stream according to the predefined format specification, extract the data fields with clear meaning from the raw byte stream or text stream. For example, for a GPS data packet, the syntax parser will extract latitude, longitude, altitude, speed, heading, etc. Information, with an accurate millisecond Coordinated Universal Time (UTC) timestamp, thereby providing a structured data foundation for subsequent processing.

[0062] In addition, if a format error or verification failure is encountered during parsing, the data packet will be discarded and logged to avoid error data polluting the downstream processing flow.

[0063] S102: Coordinate system one and conversion.

[0064] After the protocol parsing step is completed, the parsed data is passed to a shared data processing pipeline, and a uniform coordinate converter subcomponent is called to normalize all source coordinate data. The coordinate converter internally maintains a conversion matrix library containing parameters of various coordinate reference systems, such as conversion parameters from the WGS84 geodetic coordinate system to the system's preset global three-dimensional rectangular coordinate system (such as UTM or a custom projection coordinate system).

[0065] The coordinate converter can automatically match and select the corresponding conversion algorithm according to the specific configuration information attached to the data source itself (such as the coordinate system identifier in the data header, usually using the internationally recognized EPSG code), and if it cannot be matched, it will use the predefined default conversion parameters or trigger an alarm. Then, the original coordinates (usually latitude and longitude or plane coordinates) obtained by parsing are converted into the system's internally unified three-dimensional rectangular coordinates (X, Y, Z) in meters through a series of necessary mathematical transformations (including but not limited to ellipsoid projection, rotation, and translation).

[0066] All the above data from different sensors and coordinate systems are unified under the same spatial reference frame,

[0067] The global three-dimensional rectangular coordinate system serves as the basis for all subsequent spatial calculations and indexing in the system, and its origin position, coordinate axis direction, and unit scale are determined and fixed by loading configuration parameters or initialization scripts at system startup.

[0068] S103: Semantic label attachment.

[0069] After the coordinate system conversion is completed, the module runs the semantic label attachment subcomponent, which accesses a preconfigured semantic label library that supports hot updates during system operation to adapt to changing business needs.

[0070] The semantic label library can use a key-value pair or tree structure in organization, with the "key" used to set the matching rule, usually a combination of data source identifiers, data field names, or specific field values; and the "value" is the corresponding semantic label string, for example, the configuration rule can be defined as:

[0071] When the data source identifier is "intersection radar_001" and the field name is "speed", the "vehicle speed" semantic label is attached to the data;

[0072] When the data source identifier is "weather station_005" and the field name is "humidity", the "environmental humidity" semantic label is attached.

[0073] In actual processing, the system will quickly match the parsed data content with the rules in the semantic tag library according to the rules. The matching process is performed according to the priority order predefined by the rules, or the first matching principle is adopted.

[0074] Each event tuple will be attached with at least one semantic tag. If the data content is complex, multiple rules may be matched, and multiple semantic tags may be attached, forming a tag set, which provides a key index for the subsequent module to understand the data semantics. If no rule can be matched, the system can attach a default tag of "unknown" or data source type to the event.

[0075] S104: Standardized event tuple generation and output.

[0076] After completing the semantic tag attachment, the module encapsulates and outputs all processed information into a standardized data structure, i.e., an "event tuple". Each event tuple is designed to be immutable to ensure its consistency when passing through the processing pipeline.

[0077] A complete event tuple contains at least the following fields:

[0078] A 64-bit integer timestamp for accurately recording the time of event occurrence;

[0079] A three-dimensional double-precision floating-point coordinate representing the geographical location of event occurrence;

[0080] A string array for storing all attached semantic tags.

[0081] In addition, the event tuple can also include a generic data payload field, usually implemented as a key-value dictionary or a specific structure object, to carry other key numerical information in the original data other than coordinates, such as vehicle speed, sensor temperature readings, etc.

[0082] The generated standardized event tuple is continuously and efficiently pushed into a high-throughput in-memory message queue, waiting for downstream modules such as the spatiotemporal event stream processing engine to consume. The in-memory message queue has an upper capacity limit. When the queue is full, the producer can be blocked (back pressure) or the oldest data can be discarded according to the configuration strategy to protect system memory and maintain the stability of the core processing link.

[0083] In summary, through the above steps of S101 to S104, the real-time data stream access and preprocessing module completes the conversion from the original heterogeneous data stream to the internal standardized data structure. It solves the multi-source access problem through parallel adapters, lays the foundation for spatial computing through unified coordinate conversion, and provides a key index for subsequent intelligent association processing through configurable semantic tag attachment.

[0084] S2: The spatio-temporal event stream processing engine, as the computing core of the whole system, is responsible for the stateful and efficient processing of the continuous standardized event tuple stream generated upstream.

[0085] In this embodiment, the spatio-temporal event stream processing engine is implemented based on a geographical grid index incremental state management unit, and the work of the incremental state management unit is based on the spatial grid division completed at the start of the system. Specifically:

[0086] S201: System initialization and geographical spatial grid division.

[0087] At the start of the system, the incremental state management unit will first divide the entire three-dimensional geographical space into a series of regular cubic grid cells with a side length of L according to the preset geographical spatial boundaries (e.g., longitude range, latitude range, and elevation range), and the starting point of the grid division is aligned with the origin of the system's global three-dimensional rectangular coordinate system.

[0088] Among them, the grid side length L is a configurable system parameter, and its specific value is mainly determined by the spatial precision requirements of the application scenario and the distribution density of geographical objects. For example, in the intelligent transportation scenario that requires fine tracking of vehicle trajectories, L can be set to about 50 meters; while in the case of large-scale, low-precision environmental monitoring, setting L to 500 meters may be more appropriate. Generally, the typical value range of L is between 10 meters and 1000 meters.

[0089] After the grid is divided, the system will maintain a list of managed geographical objects for each grid cell, which stores the unique identifiers of all dynamic geographical objects whose geometric centers or key reference points are located within the grid cell. These objects have their corresponding complete state records in the distributed in-memory geographical state database.

[0090] S202: Incremental processing flow of event tuples.

[0091] When a standardized event tuple is taken out from the upstream in-memory queue for processing, the incremental state management unit will perform three processing steps in the following order:

[0092] S202a: Spatial positioning.

[0093] The incremental state management unit first calculates the target grid cell index of the event tuple based on the three-dimensional coordinates (x, y, z) carried in the event tuple through integer division operation. The specific calculation formula is:

[0094] Grid row index i = floor(x / L),

[0095] Grid column index j = floor(y / L),

[0096] Grid layer index k = floor(z / L).

[0097] Here, (x, y, z) is the coordinate converted to global three-dimensional rectangular coordinate system, floor is the floor function, and L is the preset grid length. Through the calculated index (i, j, k), the unit can immediately locate the corresponding grid unit and the "managed geographic object list" maintained thereby, thereby quickly associating the event with the actual geographic local area where the event occurs. If the coordinate value is an integer multiple of L, according to the floor rule, it will be attributed to the adjacent grid unit with a smaller index value.

[0098] S202b: Local iteration and impact determination.

[0099] After locating the target grid, the incremental state management unit only iterates through the geographic object identifiers in the target grid unit list, rather than all objects in the entire scene.

[0100] For each object in the list, the unit calls a system-predefined or configuration rule-generated impact determination function in combination with the semantic label accompanying the current event tuple and the type of the object itself to determine whether the event has an impact on it. The function is usually defined to receive the event semantic label and object type as input and return a Boolean value (true / false) or a structure containing the impact degree (such as a weight coefficient). The function is usually defined in the form of logical rules or scripts and can be updated through the management interface during system operation.

[0101] For example, assuming that the semantic label of an event is "air quality PM2.5 exceeds the standard", the impact determination function may be pre-configured to only affect geographic objects of type "residential area" or "school". The determination function returns "yes" or "no", if "no", the object is skipped; if "yes", the update process is entered. This method strictly limits the calculation to the local spatial range affected by the event.

[0102] S202c: Incremental update instruction generation and state synchronization.

[0103] Once it is determined that an object is affected by the event, the unit begins to process the update of the object. The state of the object (including geometric information, dynamic attributes, and timestamp) is stored in the distributed memory geographic state database in the form of a structure. The incremental state management unit calculates the specific changes that the object state needs to make (such as setting the attribute value to a new value, adding an increment to the original value, or performing a more complex transformation) based on the data payload in the event tuple and the current state of the object through a predefined update logic function.

[0104] For example, for a "road segment" object affected by a "vehicle speed" event, its update logic might be to update the "average vehicle speed" attribute of the road segment to the latest speed value carried in the event data.

[0105] Subsequently, instead of generating a data packet containing the complete state of the object, the incremental state management unit generates a highly compact incremental update instruction, which at least includes the unique identifier of the target object, the name of the attribute that has changed, and the new attribute value (or incremental value).

[0106] At the same time, the incremental state management unit synchronously calls the API of the distributed in-memory geographic state database through an internal call interface (high-speed path) optimized for low latency, to update the attribute value and the last update timestamp of the object in the database in an atomic operation (e.g., with the help of a mutex or compare-and-swap (CAS) instruction). For objects that are not affected, their states remain unchanged in the database and in memory, and no update instruction or network traffic is generated.

[0107] In addition, during processing, if the event coordinates are outside the spatial range managed by the system or the execution of the impact determination function fails, the unit will discard the event tuple and record an error log, ensuring smooth operation of the system processing flow.

[0108] In summary, the spatio-temporal event stream processing engine constructs a spatial index through S201, and implements an efficient processing method of "event-driven, local traversal, incremental update" through S202a to S202c, avoiding the overhead of full calculation and update of all data in traditional schemes, and reducing processing delay and computational resource consumption to a minimum, providing core computing support for millisecond-level response of the system.

[0109] S3: The geographic object semantic dynamic binding module serves as an intelligent routing and assembly link in the stream processing pipeline, responsible for implementing the automatic and dynamic association between sensor events and visual attributes of three-dimensional scene objects.

[0110] In this embodiment, the geographic object semantic dynamic binding module operates based on a dynamically updatable semantic mapping rule library, and its specific workflow includes the following steps:

[0111] S301: Descriptive definition and maintenance of semantic mapping rules.

[0112] This module establishes and maintains a semantic mapping rule library, and each rule in the rule library is written in a declarative domain-specific language (DSL). This language is intuitive and easy to configure. A complete rule mainly includes two parts:

[0113] Trigger condition, a Boolean algebra based logical expression whose judgment basis (i.e. operands) directly comes from the attached semantic tag set in the standardized event tuple, and can extend to reference specific named field values in the event tuple data payload, the logical expression supports basic logical operators (such as AND, OR, NOT) and comparison operators (such as equal, greater than, contain). For example, a trigger condition can be defined as: the semantic tags of the event contain both "fire alarm" AND "high-rise building".

[0114] Execution action, defines the specific operation that needs to be performed when the trigger condition is met, its essence is to assign values to the attribute slots of specific geographic object nodes in the three-dimensional scene graph, specifically:

[0115] Target object selector, used to locate one or more geographic object nodes in the three-dimensional scene graph, the selector syntax supports exact matching based on object unique identifier (ID), category matching based on object type (such as "fire hydrant", "high-rise building"), and range matching based on object spatial attributes (such as "within spatial range R"). These matching conditions can be combined through logical operators. For example, the selector can be defined as:

[0116] Type == "high-rise building" AND spatial range within (x1, y1, z1, x2, y2, z2).

[0117] Property assignment operation, specifies which data value (or value after simple calculation) in the event tuple is assigned to which visual attribute of the target object, in system implementation, each geographic object node maintains an attribute dictionary or a set of pre-defined attribute member variables (collectively referred to as "attribute slots") for controlling its color, transparency, texture, highlight state, label text, etc. visual performance, assignment operation is completed by calling the attribute setting interface of the node object (such as node.setAttribute("heat map intensity", eventData.temperature)).

[0118] S302: Event stream listening and rule matching.

[0119] In system runtime, this module acts as an independent stream processing operator, continuously listening to the standardized event tuple stream from the real-time data stream access and preprocessing module.

[0120] For each incoming event tuple, this module will quickly match the semantic tag set it carries with the trigger conditions of all rules in the rule library, the matching process can use optimization algorithms based on Trie tree or hash table, etc. to achieve a time complexity close to constant.

[0121] S303: Rule triggering and attribute direct injection.

[0122] When the semantic tag set of a certain event tuple meets the trigger condition of one or more rules, the module will immediately (concurrently) execute the corresponding execution actions of these rules.

[0123] The specific process of executing actions is:

[0124] First, according to the target object selector defined in the rule, all target scene graph nodes that meet the conditions are quickly located by querying the spatial index or object identifier index of the three-dimensional scene graph; then, these target nodes are traversed, and for each node, according to the attribute assignment operation defined in the rule, the specific value in the event tuple data payload is directly called to the attribute setting interface of the node, and written into its corresponding attribute slot.

[0125] The entire "matching, triggering, and injecting" process is completely in the memory computing environment, and the geographic object semantic dynamic binding module realizes the direct mapping of event data to object visualization attributes by accessing the three-dimensional scene graph memory structure shared with the asynchronous non-blocking rendering pipeline or directly operating it, without going through the read-write transfer of the distributed memory geographic state database, thus forming a "one-step" low-latency mapping path.

[0126] For example, for the above event that meets "fire alarm and temperature > 80", the action of its associated rule may be:

[0127] The target object selector locates "all objects of type 'high-rise building' and within 500 meters of the event point", and then writes the temperature value in the event directly into the "thermal map intensity" attribute slot of these target nodes through the attribute setting interface.

[0128] In addition, the semantic mapping rule library supports adding, deleting, modifying, and querying during system operation through the management interface, so as to realize the dynamic adjustment of semantic binding relationships without restarting the system or modifying the core code.

[0129] In summary, the geographic object semantic dynamic binding module provides flexible and easy-to-maintain mapping logic through the declarative rule definition in S301; through S302 and S303, it realizes real-time listening, fast matching, and direct attribute injection to event streams, thus freeing users from the work of writing complex binding scripts, reducing the system development and configuration threshold, and further reducing the delay of semantic mapping due to the avoidance of the database intermediate layer.

[0130] S4: The distributed memory geographic state database serves as the "single source of truth" for the entire system, responsible for centrally maintaining the latest state snapshots of all geographic objects in memory, providing high-concurrency and low-latency query and update services for upper-layer applications.

[0131] In this embodiment, the distributed in-memory geo-state database cooperates with the aforementioned spatio-temporal indexing strategy, and its working mechanism includes the following steps:

[0132] S401: Data partitioning based on geographic grid and hybrid indexing structure.

[0133] In order to obtain the fastest query speed, the database adopts the geographic grid index consistent with the spatio-temporal event stream processing engine as its data partitioning strategy. During system initialization, according to the pre-divided geographic grid, an independent logical data partition is created in memory for each geographic grid unit. Each logical data partition is not required to be a continuous physical memory block, but a memory area allocated and managed by the system memory manager, which is used to store the state data of all geographic objects in the grid unit. The system maintains a partition lookup table (for example, a three-dimensional array), which can be directly located to the corresponding logical data partition address through the grid index (i, j, k).

[0134] Inside the database, each data partition adopts a hybrid indexing structure to efficiently manage the data organized in the form of key-value pairs:

[0135] The key is the unique identifier of the geographic object, usually a string or a 64-bit integer.

[0136] The value is the state structure of the object, which typically includes object type, geometry data (such as vertex array), dynamic attribute dictionary (such as storing speed, temperature, state, etc. key-value pairs), and a 64-bit last update timestamp.

[0137] In order to meet different query requirements, each data partition maintains two core indexes at the same time:

[0138] Hash table index, used to support constant time complexity (O(1)) point query based on object identifier, this hash table takes object identifier as key, directly stores or maps to the address pointer of the object state structure in memory.

[0139] Spatial index, used to support fast retrieval based on geographic spatial range, this spatial index is built based on the bounding box of the object, and can use data structures such as skip list (Skip List) or R-tree (R-Tree), each entry of the spatial index contains the bounding box information of the object and the pointer to its state structure (or can be indirectly obtained through the object identifier).

[0140] The hash table index and the spatial index work together, share or point to the same object state data, ensuring data consistency.

[0141] S402: Implementation of efficient query interface.

[0142] The database provides a set of concise and efficient application programming interfaces (APIs). Among them, the most critical and commonly used interfaces are mainly the following two:

[0143] S402a: Get the status based on the identifier.

[0144] This interface is used for precise queries of a single object. When an object identifier is received, the interface logic first quickly locates its corresponding data partition based on the identifier (or the spatial information encoded / attached within it). Specific partition location methods include, but are not limited to, embedding the index information of its corresponding grid in the object identifier's encoding rules; or maintaining a global hash table or mapping table to record the correspondence between each object identifier and its primary partition grid index. After locating the target data partition, the corresponding status structure is directly searched and returned from the hash table within that data partition. Since it primarily involves memory addressing and hash calculations, without disk I / O or complex traversal, the response time is typically completed within microseconds.

[0145] S402b: Query based on spatial range.

[0146] This interface is used for spatial range retrieval. When a spatial range query request is received, the interface logic first calculates the set of indexes of all geographic grid units covered by the range based on the minimum and maximum coordinate values ​​of the range, using the same grid division rules as the spatiotemporal event stream processing engine (i.e., the formula: index = floor(coordinates / grid side length L)).

[0147] Then, subqueries are concurrently initiated for the data partitions corresponding to these grid cells. Each data partition uses its internal spatial index (skip list or R tree) to quickly retrieve objects that intersect with the range of this data partition and returns the result set. Finally, this interface merges the result sets of all data partitions and returns them to the caller.

[0148] S403: High-concurrency write and state consistency guarantee.

[0149] The write operations of the distributed in-memory geographic state database mainly come from the synchronous state updates of the spatiotemporal event stream processing engine. To achieve data security under high concurrency, all write operations are atomic operations on a single key-value pair. This is usually achieved by equipping each key (or the key within each data partition) with lightweight synchronization primitives, such as using a mutex to protect access to the memory region corresponding to the key, or using atomic instructions supported by the processor (such as compare-and-swap, CAS) to directly update specific fields in memory, thereby ensuring the atomicity, consistency and isolation of the state updates of each geographic object in a concurrent environment.

[0150] When the time-space event stream processing engine calculates the new state of an object and generates incremental update instructions, it synchronously calls the database API through an internal channel (high-speed path) designed for low latency. This "high-speed path" is usually implemented as a direct function call or inline function, avoiding complex protocol parsing and network stack overhead. In terms of deployment, since the processing engine and the database are in the same in-memory computing framework, the call is actually a function call to the database management module in shared memory, or an atomic write operation to the target memory address.

[0151] In this way, the state structure of the target object and its last update timestamp are updated atomically, ensuring that the database serves as a unique, consistent, and authoritative source of the entire system's state.

[0152] In summary, the distributed in-memory geographic state database lays the foundation for high-performance access through the partitioning and hybrid indexing design in S401, which works in conjunction with the processing engine; it meets the real-time requirements of point queries and spatial range queries through the two efficient query interfaces provided by S402; and it ensures the consistency of the global state through the atomic write mechanism of S403. It can maintain the dynamic state of massive geographic objects entirely in memory, allowing state queries and updates to completely eliminate the I / O bottleneck of traditional disk databases.

[0153] S5: The asynchronous non-blocking rendering pipeline is responsible for converting dynamically changing geographic conditions into visual images in real time. It achieves high frame rate and low latency visual updates through asynchronous processing and local redrawing.

[0154] In this embodiment, the asynchronous non-blocking rendering pipeline decouples state calculation from graphics rendering and focuses on incremental updates. Its workflow can be achieved through the following steps:

[0155] S501: Asynchronous encapsulation and submission of rendering tasks.

[0156] The main thread of the asynchronous non-blocking rendering pipeline (typically running in conjunction with the spatiotemporal event stream processing engine) continuously listens for and receives incremental update instructions from the spatiotemporal event stream processing engine. The main thread and the spatiotemporal event stream processing engine can be deployed within the same process, communicating efficiently through shared memory or direct function calls. When the processing engine generates an incremental update instruction, it immediately passes the instruction to the rendering pipeline main thread via event notification or by directly calling the engine's interface.

[0157] To avoid blocking upstream event processing, the main thread does not execute rendering immediately. Instead, for each incremental update instruction, the main thread encapsulates its underlying update intent into a lightweight rendering task.

[0158] A typical rendering task data structure includes a list of geographic object identifiers that need to be updated and an enumeration value indicating the type of update (e.g., "update color", "update location", "update texture").

[0159] After encapsulation, the main thread pushes the rendering task object into a rendering task queue and then immediately returns to continue processing subsequent incremental update instructions. This process is non-blocking and takes little time.

[0160] The rendering task queue is a thread-safe queue in a multi-producer single-consumer or multi-consumer pattern, usually implemented based on a lock-free circular buffer to ensure efficient operation under high concurrency.

[0161] S502: Parallel task processing and incremental update of graphics resources.

[0162] On the rendering node side, a rendering worker thread pool (the number of threads is typically configured with the number of GPU cores) continuously retrieves tasks from the rendering task queue, consisting of multiple resident worker threads. Specifically, this includes the following steps:

[0163] S502a: Status data acquisition. The worker thread aggregates multiple identifiers based on the list of object identifiers in the task and sends an efficient batch query request to the distributed in-memory geographic status database to obtain the latest status data of these objects. Due to the optimized design of the distributed in-memory geographic status database, this type of query can obtain a response within milliseconds.

[0164] S502b: Graphics API calls and partial updates. After the worker thread obtains the latest status data, it begins to call the application programming interface (API) of the underlying graphics rendering engine (such as OpenGL, DirectX or Vulkan).

[0165] The key step is that the system maintains a mapping table of object identifiers and graphics resource handles. Based on the object identifier, the worker thread can quickly retrieve the corresponding graphics resource (such as vertex buffer object VBO, uniform buffer object UBO, texture object, etc.) from this mapping table.

[0166] Subsequently, all graphics API calls are strictly limited to updating graphics resources whose states have changed. This includes updating object positions in the vertex buffer, updating color or highlight parameters in the uniform buffer (UBO), binding new textures, or updating specific parameters in the shader program.

[0167] In a 3D scene, the graphics data of most objects that remain unchanged are always stored in the GPU memory, and the corresponding drawing commands remain unchanged, avoiding the overhead of redrawing the entire scene.

[0168] S503: Graphics engine frame looping and local redrawing.

[0169] As the final stage of the entire rendering process, the graphics rendering engine (such as OSG, Unity, or Unreal Engine) works according to its inherent frame cycle. At the beginning of each frame rendering cycle, the graphics rendering engine traverses the 3D scene graph and submits drawing commands.

[0170] To ensure safe collaboration between background thread updates and foreground rendering threads, the system employs a double-buffered or thread-safe resource exchange mechanism. After the asynchronous non-blocking rendering pipeline worker thread completes the update of graphics resources in the background, it "exchanges" the updated resource handles or data pointers with the rendering resource set used by the graphics engine in the current frame through atomic operations or lock protection.

[0171] At this point, because the asynchronous non-blocking rendering pipeline has already updated the graphics data of all changed objects in the background thread and completed resource synchronization with the rendering thread, the graphics rendering engine can iterate through the data in advance.

[0172] For objects whose data has been updated, render them directly using the new graphics data.

[0173] For objects whose state has not changed, the rendering results and GPU state of the previous frame are fully reused.

[0174] The above processing method ensures that the actual rendering workload of the graphics engine in each frame is only proportional to the number of visual elements that change in the scene, and is independent of the total complexity of the entire scene.

[0175] Therefore, even in a massive 3D city scene containing hundreds of thousands of static objects, if there are only a few dozen dynamic vehicles, the system can easily maintain a high refresh rate of over 60 frames per second (FPS), because each frame only needs to redraw these few dozen vehicles and their extremely small affected local areas (such as the illumination range of the headlights), and the static city background is efficiently reused.

[0176] In summary, the asynchronous non-blocking rendering pipeline avoids processing blockage through the asynchronous task encapsulation of S501, greatly reduces the workload of the GPU through the parallel task processing and precise local graphics resource updates of S502, and achieves frame-based local redrawing through the collaboration of S503 and the graphics engine. This ensures that the visualization rendering can respond quickly to data changes while maintaining extremely high rendering efficiency and system smoothness.

[0177] S6: The visualization interaction and feedback module forms a two-way closed-loop channel between the system and the user, which not only supports the user's intuitive exploration of the three-dimensional scene, but also feeds the user's operation back to the system data stream.

[0178] In this embodiment, the working mechanism of the visual interaction and feedback module mainly includes the following two aspects:

[0179] S601: User Interaction Analysis and Visual Feedback.

[0180] The visual interaction and feedback module is responsible for receiving and processing various interactive operations initiated by users through input devices such as mouse, keyboard, and touchscreen, such as viewpoint changes, object selection / box selection, and spatial range queries. Specifically:

[0181] S601a: When a user performs an operation (e.g., clicks the screen), this module first captures the original input event from the operating system (e.g., the screen pixel coordinates (px, py) of the mouse click and the viewport size). Then, this module uses the picking interface provided by the graphics rendering engine, combined with the current camera's view matrix, projection matrix, and viewport parameters, to convert the screen coordinates into a three-dimensional ray emanating from the camera's near plane. The direction of this ray is calculated by projecting the screen coordinates back onto the world coordinate system, and is used for subsequent spatial intersection detection.

[0182] S601b: This module then encapsulates this spatial information (such as ray origin, direction, or the 3D bounding box formed by the selection) into a structured spatial query request object. This object at least includes the query type (such as ray intersection, range query), spatial parameters, and optional filtering conditions (such as object type). For example, for an object selection operation, a "query based on ray intersection" request will be initiated, which is sent to the query interface of the distributed in-memory geographic state database via the internal message bus.

[0183] S601c: The distributed in-memory geographic status database uses its spatial index to quickly return the identifier and detailed information (such as object type and attribute value) of the selected object. After receiving the query results, this module does not modify the core business data in the database, but generates corresponding visual feedback instructions according to the interaction type.

[0184] For example, when an object is selected, a "highlight rendering instruction" is generated. This instruction is a lightweight data structure that includes the target object identifier, highlight style (such as color RGBA value, luminance intensity), and duration (such as continuous highlight or fade-out after clicking). This instruction is submitted to the asynchronous non-blocking rendering pipeline as a special type of rendering task, instructing the asynchronous non-blocking rendering pipeline to temporarily change the visual appearance of the selected object (such as changing the color or adding a halo) to achieve immediate pure visual feedback. This process is handled entirely in the rendering pipeline and does not involve business state updates, thereby ensuring extremely low interaction response latency.

[0185] S602: Manually corrected closed-loop feedback.

[0186] The visualization interaction and feedback module supports direct modification of geographic object attributes by users (e.g., dragging facility locations or modifying building height values ​​in the planning tool). This functionality is provided through interactive editing controls integrated into the 3D scene view (such as draggable anchor points and floating attribute editing panels). When a user selects a geographic object, the visualization interaction and feedback module activates the associated editing controls and listens for the user's editing input. Specifically:

[0187] When a user modifies an object's attributes (such as position coordinates, height value, color code, etc.) through the editing interface and triggers a confirmation operation (such as clicking the "Apply" button, or the editing box losing focus and detecting a change in value), this module will capture all the parameters of this editing operation and encapsulate them into a specially constructed "human intervention event tuple".

[0188] This human intervention event tuple has a similar data structure to the standard event tuple, but includes a special field to identify its source:

[0189] A specific semantic label (such as "user_manual_update") is used to distinguish it from sensor events in subsequent processing;

[0190] The unique identifier of the modified geographic object (obtained from the currently selected object);

[0191] The name of the modified property (corresponding to the object property slot bound to the edit control);

[0192] New attribute value entered by the user;

[0193] A high-precision timestamp generated from the system's current time is used to mark the moment when human intervention occurred.

[0194] This module then uses a dedicated feedback channel to inject this special event tuple as a new data source into the input port of the real-time data stream access and preprocessing module. This feedback channel is logically parallel to the sensor data access port, ensuring that manually intervened events can enter the system's core processing pipeline through the same streaming interface.

[0195] The aforementioned human intervention event tuples will flow into the spatiotemporal event stream processing engine, just like ordinary sensor events. Based on their specific semantic tags, predefined processing logic can be applied (e.g., directly overwriting the corresponding attributes of the target object and recording the update source as the user), triggering incremental state updates. These updates are then reflected in the visualization scene through an asynchronous, non-blocking rendering pipeline. This process ensures that the user's subjective modifications can drive the synchronous update of the entire system's state and visual representation, just like objective sensor data, forming a complete closed loop from user interaction to system data state updates. Simultaneously, through a unified event stream processing framework, the system maintains the consistency of data processing logic and, leveraging the atomic operation characteristics of the distributed in-memory geographic state database, ensures the consistency of state between human modifications and real-time sensor updates in high-concurrency scenarios.

[0196] In summary, the visualization interaction and feedback module achieves seamless conversion of user intent into scene query and visual feedback through S601, enhancing the interactivity of the system; through S602, it constructs a closed loop of "user intervention, data update, and visual synchronization", enabling the system to not only reflect the real world, but also to agilely integrate and present human decision input, greatly enhancing the practical value of the system in planning, simulation and other scenarios.

[0197] Based on this, the data processing logic of this system forms an efficient closed loop, and its specific process is as follows:

[0198] First, the data stream originates from various heterogeneous sensors (such as GPS, IoT devices, etc.). The real-time data stream access and preprocessing modules receive the raw data stream in parallel, perform instant parsing, coordinate unification and semantic tag attachment, and output standardized event tuples with timestamps, three-dimensional geographic coordinates and semantic tags.

[0199] Secondly, the standardized event tuples are consumed in real time by the spatiotemporal event stream processing engine. This engine performs incremental state management based on the geographic grid index, locates the corresponding grid cell according to the event coordinates, only traverses and updates the state of the affected geographic objects within the cell, and generates incremental update instructions describing the state changes.

[0200] Furthermore, the geographic object semantic dynamic binding module operates in parallel, matching predefined declarative rules based on event semantic tags to directly inject event data into the attribute slots of corresponding objects in the 3D scene map, realizing the dynamic association between data and visual attributes; at the same time, the latest state of all objects is saved in a distributed in-memory geographic state database in an atomic manner.

[0201] Furthermore, the asynchronous non-blocking rendering pipeline retrieves the object state specified by the incremental update instruction from the distributed in-memory geographic state database, driving the graphics rendering engine to redraw only the objects whose state has changed and their associated visual regions, while maintaining the rendering results of the rest of the scene, thereby achieving low-latency, high-frame-rate visualization updates.

[0202] Finally, users can interact with the 3D scene through the visualization interaction and feedback module (such as changing the viewpoint and selecting objects). The visualization interaction and feedback module will convert the interaction into query requests and highlight the results in real time. In addition, users' manual correction of object attributes can be encapsulated as special event tuples and fed back to the real-time data stream access and preprocessing module, and re-injected into the processing flow to form a real-time dynamic loop of "perception, processing, presentation, interaction, and feedback".

[0203] In summary, this system achieves millisecond-level end-to-end response from multi-source sensor data to 3D visualization through full-memory processing, incremental updates, and local redrawing strategies, and supports real-time feedback for user interaction, thereby constructing an efficient, scalable, and dynamically interactive 3D geographic information visualization closed-loop system.

[0204] Example 2

[0205] This embodiment provides an alternative implementation scheme for a 3D geographic information visualization system that supports dynamic interaction. The difference lies in that the incremental state management unit of the spatiotemporal event stream processing engine adopts a different spatial index structure than in Embodiment 1, and the partitioning strategy of the distributed in-memory geographic state database that works in conjunction with it is adjusted accordingly to adapt to different data distribution characteristics and query requirements, demonstrating the technical flexibility and scalability of this system. The specific implementation steps are described below:

[0206] Step 1: Use a dynamic hybrid tree spatial index structure.

[0207] In this embodiment, the incremental state management unit no longer uses a regular cubic geographic grid index, but instead adopts a dynamic adaptive hybrid spatial index structure that combines the ideas of quadtrees and octrees (which can be simply referred to as a dynamic hybrid tree index).

[0208] The tree nodes of a dynamic hybrid tree index uniformly contain the following data structures: a three-dimensional spatial bounding box (AABB), a "list of managed geographic objects", and an array of pointers to its child nodes.

[0209] Its "hybrid" characteristics are reflected in its spatial subdivision strategy. The system decides whether to subdivide the current node into a quadrilateral (dividing it into four sub-regions in the horizontal XY plane while keeping the Z-axis range unchanged) or an octagonal (dividing it into eight sub-cubes in three-dimensional space) based on preset rules.

[0210] Decision rules are typically configured based on scene features. For example, octagonal subdivision can be used in densely built-up areas to obtain vertical management granularity, while quadruple subdivision can be used in flat areas where objects are mainly distributed horizontally to reduce the complexity of the tree structure.

[0211] This hybrid spatial indexing structure is particularly suitable for application scenarios where geographic objects are extremely unevenly distributed in three-dimensional space. For example, in smart city applications, the density of buildings and vehicles is very high in the city center, while objects may be very sparse in the suburbs or park areas. If a fixed-size regular grid is used, a large number of idle grid cells will be generated in sparse areas, resulting in memory waste and management overhead. In dense areas, too many objects in a single grid will affect traversal efficiency.

[0212] Dynamic hybrid tree indexes can adaptively adjust the index granularity of different regions through recursive spatial subdivision, thus effectively solving the above problems.

[0213] Step 2: System initialization and index construction.

[0214] During the system startup phase, the incremental state management unit is initialized, specifically as follows:

[0215] The entire three-dimensional geospace to be managed is defined as the spatial bounding box corresponding to a root node.

[0216] For each tree node in the dynamic hybrid tree index, a "managed list of geographic objects" is maintained. Unlike Example 1, where objects belong to only one grid cell, this example employs a storage strategy based on object boundaries and node relationships. Specifically:

[0217] When the bounding box of a geographic object completely contains the spatial range of a tree node, or when it significantly overlaps with the spatial range of a node and the object size is relatively large compared to the node, the object can be recorded in the list of the non-leaf node (or one of its ancestor nodes) according to the configuration strategy, rather than just the final subdivided leaf node. This helps to balance the depth of the index tree with the efficiency of query retrieval and avoids the degraded positioning performance caused by an excessively deep tree structure.

[0218] The specific node where an object is stored is determined by a one-time space calculation and allocation during initialization, and remains unchanged as long as the object's state does not undergo geometric changes.

[0219] Set a termination condition for spatial subdivision. The recursive subdivision process will stop when any of the following conditions are met:

[0220] First, it reaches the preset maximum tree depth (e.g., 10 levels).

[0221] Second, the number of geographic objects managed by the current node is lower than a certain set threshold (e.g., 50).

[0222] These parameters can be adjusted according to the data density of the actual scenario.

[0223] Step 3: Adjust the partitioning strategy of the distributed in-memory geographic status database accordingly.

[0224] Due to the change in spatial index structure, the partitioning strategy of the distributed in-memory geographic state database is no longer bound to geographic grid cells, but is instead associated with leaf nodes (or nodes at a specific level) in the dynamic hybrid tree index. During initialization, the system allocates an independent data partition for each selected tree node (usually a leaf node, or a non-leaf node that meets a certain number of object conditions).

[0225] This data partition is responsible for storing the status data of all objects in the "managed geographic object list" of its associated tree nodes. Each data partition still uses a hybrid index structure that combines skip lists and hash tables (as described in Example 1), but its physical partition boundaries now correspond to the logical node space range of the dynamic hybrid tree.

[0226] Step 4: Event handling process based on dynamic hybrid tree.

[0227] When there are standardized event tuples to process, the incremental state management unit operates according to the following steps:

[0228] Event localization: The incremental state management unit performs recursive spatial inclusion checks starting from the root node of the dynamic hybrid tree index, based on the three-dimensional coordinates (x, y, z) in the event tuple.

[0229] For the current node, determine whether the coordinate point is within its bounding box; if so, determine which child node the coordinate point is located in based on the node's subdivision type (quadrilateral or octagonal) and the spatial range of its child nodes, and recursively enter that child node to continue the determination.

[0230] This recursive process continues until a "target tree node" that satisfies the termination condition in step two is found.

[0231] Local Traversal and Impact Determination: After locating the target tree node, the incremental state management unit only needs to traverse the geographic objects (not all network objects) within the node's "managed geographic object list". Combining the event's semantic tags and object types, it calls a predefined impact determination function to determine which objects in the list will be affected by the current event. Subsequently, depending on the system configuration, it may also be necessary to backtrack upwards and traverse the "managed geographic object list" of the target node's parent node (or even higher-level ancestor nodes) to check for large or cross-boundary objects stored in higher-level nodes that may be affected by the event, ensuring the accuracy and completeness of the traversal range.

[0232] Incremental Update and State Synchronization: For each affected object, the incremental state management unit calculates its state change, generates a concise incremental update instruction (containing the object identifier, changed attributes, and new values), and synchronously updates the object's state in the distributed in-memory geographic state database. At this time, the database locates the corresponding data partition (associated with the dynamic hybrid tree node to which the object belongs) based on the object's identifier through its internal index and performs state updates. The core logic of this step is consistent with that of Implementation Example 1, but the scope of spatial positioning (S401) and object traversal (S402) is precisely limited to the local node set determined by the dynamic hybrid tree index, thus achieving efficient computation as well.

[0233] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0234] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment includes only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A three-dimensional geographic information visualization system supporting dynamic interaction, characterized in that The system comprises: a real-time data stream access and preprocessing module for receiving and standardizing heterogeneous sensor data in parallel and outputting standardized event tuples with timestamps, spatial coordinates and semantic labels; a spatio-temporal event stream processing engine connected with the real-time data stream access and preprocessing module for incrementally managing and updating the standardized event tuples based on a geographic spatial index and generating incremental update instructions; a geographic object semantic dynamic binding module connected with the real-time data stream access and preprocessing module and a three-dimensional scene graph for realizing automatic association of event data and visualized attributes of scene objects through declarative rules; a distributed in-memory geographic state database connected with the spatio-temporal event stream processing engine for storing and querying the states of geographic objects in a high-concurrency in-memory storage mode; an asynchronous non-blocking rendering pipeline connected with the spatio-temporal event stream processing engine and the distributed in-memory geographic state database for driving a graphic rendering engine to perform partial redrawing according to the incremental update instructions; a visualized interaction and feedback module connected with the distributed in-memory geographic state database and the asynchronous non-blocking rendering pipeline for responding to user interactions and supporting user intervention data feedback to the real-time data stream access and preprocessing module.

2. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 1, wherein, The real-time data stream access and preprocessing module comprises: a plurality of protocol adapters arranged in parallel for respectively analyzing sensor raw data in different formats; a coordinate converter for uniformly converting the analyzed coordinate data to a globally preset three-dimensional rectangular coordinate system; a semantic label attaching component for attaching semantic labels to the data according to a preconfigured semantic label library to generate the standardized event tuples.

3. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 1, wherein, The spatio-temporal event stream processing engine comprises: an incremental state management unit constructed based on a geographic grid index or a dynamic hybrid tree spatial index for locating the spatial index unit according to event coordinates, only traversing geographic objects within the spatial index unit, determining objects to be updated through an influence determination function, calculating state changes and generating the incremental update instructions, and synchronously updating the states of corresponding objects in the distributed in-memory geographic state database.

4. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 1, wherein, The geographic object semantic dynamic binding module maintains a semantic mapping rule library, wherein each rule contains a trigger condition based on an event semantic label and an execution action of assigning values to attribute slots of target objects in a three-dimensional scene graph; The geographic object semantic dynamic binding module listens to a standardized event tuple stream and directly operates scene graph node attributes when a rule is matched, realizing mapping of event data to visualized attributes.

5. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 1, wherein, The distributed in-memory geographic state database adopts a spatial index coordinated with the spatio-temporal event stream processing engine for data partitioning; Each data partition adopts a hybrid index structure combining a hash table index and a spatial index to support point queries based on object identifiers and fast retrieval based on spatial ranges, and guarantees state consistency through atomic operations.

6. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 1, wherein, The asynchronous non-blocking rendering pipeline comprises: a rendering task queue for asynchronously receiving and buffering rendering tasks encapsulated by the incremental update instructions; A rendering worker pool is configured to obtain tasks from the rendering task queue, and to call a graphics API to update only graphics resources corresponding to objects whose states have changed, according to the latest object states obtained from the distributed memory geographic state database according to the rendering tasks; A resource synchronization mechanism is configured to safely exchange the updated graphics resources into a frame cycle of a graphics rendering engine, to realize partial redrawing.

7. The three-dimensional geographic information visualization system that supports dynamic interaction of claim 1, wherein, The visualization interaction and feedback module comprises: An interaction analysis unit is configured to analyze a user input operation as a spatial query request and send the spatial query request to the distributed memory geographic state database, and to generate a visual feedback instruction according to a returned result and submit the visual feedback instruction to the asynchronous non-blocking rendering pipeline; A feedback injection unit is configured to encapsulate a user's correction operation on a geographic object attribute as an artificial intervention event tuple, and to feed back the artificial intervention event tuple to an input end of the real-time data stream access and preprocessing module.

8. The three-dimensional geographic information visualization system supporting dynamic interaction of claim 3, wherein, The geographic grid index is an index for dividing a three-dimensional geographic space into regular cubic grids; The dynamic hybrid tree spatial index is an adaptive tree-shaped spatial index dynamically subdivided according to object distribution, and is a four- or eight-subdivision adaptive tree-shaped spatial index.

Images