A full-cycle space-time digital backplane dynamic maintenance and data fusion method

Abstract

The application discloses a full-cycle space-time digital bottom plate dynamic maintenance and data fusion method, comprising: preprocessing full-cycle data; based on a rule base, adopting geometric topology matching and attribute intelligent binding double-drive conversion, automatically matching BIM and CIM and binding attributes, generating standardized data; full-amount writing establishes a bottom plate, and incremental writing of change data is generated to store version nodes in a version chain; space coding and business association keys are configured and dynamic binding is established, and bidirectional conduction mapping between stages is established; based on the mapping, when space or business data changes, the other party is triggered to update and consistency check synchronously, through integrated storage and message pushing persistence, the bottom plate dynamic maintenance and fusion are completed. The application realizes full-process automatic management and traceable cooperation, and solves the problems of automation, integration and traceability of full-process management.

Description

Technical Field

[0001] This application relates to the field of architectural city model fusion technology, and in particular to a method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital base plate. Background Technology

[0002] The entire construction cycle encompasses planning, design, construction, delivery, and operation and maintenance. BIM is used for building component-level modeling, CIM focuses on the representation of urban spatial foundations and geographic elements, and the spatiotemporal digital baseboard aims to integrate multi-source data to provide a unified benchmark for digital twin applications. Existing BIM and CIM data processing solutions involve manually importing BIM models and CIM geographic data separately, manually performing coordinate system calibration, format conversion, topology repair, and lightweighting, and then storing them separately in the database and displaying them through layer overlay. The spatiotemporal digital baseboard is built once, and subsequent updates rely on manual re-import and overwriting.

[0003] The lack of standardized mapping rules and automatic conversion algorithms between BIM components and CIM elements means that component-element mapping relies on manual processes, resulting in low conversion efficiency, inconsistent accuracy, and poor consistency. The preprocessing of multi-source data is fragmented, with operations such as coordinate system transformation, topology repair, and lightweighting operating independently, lacking a unified pipeline scheduling, leading to lengthy processing flows and high error rates. The spatiotemporal digital baseplate is statically fixed and cannot be dynamically updated with different project stages. It lacks both incremental update mechanisms and version management and historical traceability, causing the baseplate data to lag behind the actual project data.

[0004] The aforementioned deficiencies result in the isolation of BIM / CIM model data, business management data, and IoT sensing data, lacking a unified integration architecture and standardized interaction logic. Data from planning, design, construction, delivery, and operation and maintenance stages cannot be interconnected, and spatial data and business data cannot be linked for updates and collaborative applications. The spatiotemporal digital base lacks dynamic correlation and integrated storage with business systems, and upper-level digital twin and collaborative management applications lack a reliable and consistent data foundation, making it difficult to guarantee the accuracy and timeliness of decision-making information.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a method for dynamic maintenance and data fusion of spatiotemporal digital base plates throughout the entire life cycle, which aims to solve the technical problem that multi-source heterogeneous data in the entire life cycle of existing engineering construction cannot achieve automation, integration and traceability in the whole process governance.

[0007] To achieve the above objectives, this application proposes a method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard, the method comprising: Acquire full-cycle data for the project construction and preprocess the full-cycle data; In the preset component element classification mapping rule base, a dual-drive conversion algorithm combining geometric topology matching and attribute intelligent binding is adopted to automatically match the spatial contour, topological relationship and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data. Batch bind the successfully matched BIM component attributes to CIM feature attribute fields to generate standardized feature data; The standardized element data is fully written to establish a spatiotemporal digital baseboard. Change capture and difference calculation are performed on the subsequently changed standardized element data to separate the changed parts. The changed parts are incrementally written to the current spatiotemporal digital baseboard, and version nodes are generated and persistently stored in a unidirectional version chain. Based on the standardized element data in the spatiotemporal digital base, a spatial unique code is configured for the spatial data in the standardized element data, a business association key is configured for the associated business data, and a dynamic binding relationship is established between the spatial unique code and the business association key. Through the dynamic binding relationship, a bidirectional data transmission mapping is established between each stage of the entire life cycle of the project construction. The bidirectional transmission mapping includes a top-down hierarchical mapping and a bottom-up hierarchical implementation. Based on the bidirectional data transmission mapping, when spatial data or business data changes, the other party is automatically triggered to synchronize and verify consistency according to the dynamic binding relationship, and the changes are persisted through integrated storage and change message push mechanism to complete the dynamic maintenance and data fusion of the spatiotemporal digital base.

[0008] In one embodiment, the step of acquiring full-cycle data of the engineering construction project and preprocessing the full-cycle data includes: Coordinate system identification is performed on the BIM component data and CIM element data in the full-cycle data respectively, and the corresponding seven-parameter transformation algorithm is matched from the pre-configured coordinate system transformation rule library to convert the local coordinate system into the national geodetic coordinate system and the national elevation datum. A filtering algorithm is used to remove noise from the data after coordinate system transformation, and then an interpolation algorithm is used to fill in the missing data values. The graph theory-based topology reconstruction algorithm automatically identifies and repairs errors in the data such as overlaps, breakpoints, dangling points, unclosed surfaces, and topological conflicts. Based on the preset viewing distance threshold and model detail level, dynamic precision adjustment is performed on the repaired data, preserving high-precision geometry and texture in close-up shots and compressing the number of model faces in distant shots.

[0009] In one embodiment, the step of automatically matching the spatial contour, topological relationship, and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data using a dual-drive conversion algorithm combining geometric topology matching and intelligent attribute binding in a preset component element classification mapping rule base includes: Configure the component element classification mapping rule base to include standard correspondences between multiple types of BIM components and multiple types of CIM elements; Extract the spatial outline boundary, topological adjacency relationship and elevation range of BIM components, and compare the similarity with the spatial outline, topological relationship and elevation range of CIM elements, and output candidate elements that meet the preset matching requirements. Based on the matching results, the professional type, unique identifier code, material grade, construction status and design parameters of BIM components are batch filled into the corresponding CIM element attribute table, and the layer style and spatial code are updated simultaneously.

[0010] In one embodiment, the steps of fully writing the standardized element data to establish a spatiotemporal digital baseboard, performing change capture and difference calculation on subsequently changed standardized element data to extract the changed portion, and incrementally writing the changed portion into the current spatiotemporal digital baseboard include: During the first full write, a globally unique identifier is assigned to each standardized feature data and the initial version number and timestamp are recorded. During subsequent operation, by monitoring change events of the BIM collaboration platform or IoT sensing system, standardized element data that has been modified, added or deleted can be captured in real time. The captured change data is compared field by field with the corresponding historical data in the current base plate to extract the attribute fields and geometric elements that cause the difference, forming a change increment package containing only the difference information. The change increment package is committed to the baseboard database in a transactional manner to cover the differences.

[0011] In one embodiment, after the step of generating version nodes and persistently storing them in a one-way version chain, the method further includes: In response to a version rollback request sent by a user or an upper-layer application, the target version identifier carried in the version rollback request is parsed, the corresponding version node is found by traversing the unidirectional version chain, and the full data snapshot or incremental change sequence associated with the version node is retrieved from the archive area of ​​the spatiotemporal digital base corresponding to the version node, and the complete spatiotemporal digital base state of the version corresponding to the target version identifier is reconstructed. In response to the version comparison request, extract the spatiotemporal digital base status corresponding to the two different version nodes, perform item-by-item difference analysis on the spatial data geometric elements and business data attribute fields in the two statuses, and output a difference comparison report; In response to a rollback request, the current baseboard state is completely replaced with the baseboard state associated with the specified historical version node, and a new version node is generated to record this rollback operation.

[0012] In one embodiment, the step of establishing a bidirectional data transmission mapping between different stages of the entire lifecycle of engineering construction through the dynamic binding relationship includes: Based on the unified coding inheritance relationship between each stage of the entire life cycle of engineering construction, a hierarchical mapping between output data and input data between adjacent stages is established. Through this step-by-step mapping, the output data of the upstream stage is transmitted sequentially along the life cycle direction as the input data of the downstream stage, and the result data of the downstream stage is fed back to the upstream stage, forming a two-way mapping link that transmits data step-by-step from top to bottom and implements data step-by-step from bottom to top.

[0013] In one embodiment, the step of automatically triggering the other party to synchronize and update and verify consistency based on the dynamic binding relationship when spatial data or business data changes, and persisting the changes through an integrated storage and change message push mechanism, includes: When it is determined that the location, geometry, or spatial range of a component in the spatial data has changed, the corresponding business data record is located through the unique spatial code, the associated spatial coordinate field, the region identifier, and the spatial constraint status in the business data record are automatically updated, and the data consistency check of the business system is triggered. When it is determined that there is a delay in progress, an abnormality in quality, an overspending of investment, or a change in the status of operation and maintenance alarms in the business data, the corresponding spatial component is located through the business association key, the spatial component is automatically highlighted in the spatiotemporal digital baseboard, an early warning prompt is pushed, and the spatial component is focused and located in the three-dimensional view. During bidirectional synchronization, a distributed transaction protocol is used to ensure atomic operations between the spatial database and the business database, and a message queue is used to asynchronously notify all upper-layer applications that have subscribed to the changes to refresh the display.

[0014] In one embodiment, the step of automatically triggering the other party to synchronize and update and verify consistency based on the dynamic binding relationship when spatial data or business data changes, and persisting the changes through an integrated storage and change message push mechanism, includes: The spatial data, business data and IoT sensing data in the spatiotemporal digital base plate are uniformly written into the same spatial database or graph database, sharing the same access interface and transaction management unit. After each change is successfully submitted, a standardized change event is generated, which includes the change type, the unique identifier of the changed object, the change timestamp, and the values ​​before and after the change. The standardized change events are pushed to preset message topics, which can be subscribed to and consumed on demand by digital twin applications, collaborative management and control systems, construction supervision platforms and operation and maintenance management systems, so that each upper-layer application maintains real-time consistency with the spatiotemporal digital base.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: Acquire full-cycle data for the engineering construction and preprocess the data. Using a dual-drive conversion algorithm combining geometric topology matching and intelligent attribute binding within a pre-defined component element classification mapping rule base, automatically match the spatial contours, topological relationships, and elevation ranges of BIM component data and CIM element data in the preprocessed full-cycle data. Batch bind the successfully matched BIM component attributes to CIM element attribute fields to generate standardized element data. Write the standardized element data in full to establish a spatiotemporal digital baseboard. For subsequently changed standardized element data, perform change capture and difference calculation to extract the changed portions. Incrementally write the changed portions into the current spatiotemporal digital baseboard, generate version nodes, and persist them using a unidirectional version chain. The system stores and stores data based on standardized element data in the spatiotemporal digital base. It assigns unique spatial codes to spatial data within the standardized element data, configures business association keys for associated business data, and establishes a dynamic binding relationship between the unique spatial codes and the business association keys. Through this dynamic binding relationship, it establishes a bidirectional data transmission mapping between all stages of the entire project lifecycle. This bidirectional transmission mapping includes top-down hierarchical mapping and bottom-up hierarchical implementation. Based on this bidirectional data transmission mapping, when spatial data or business data changes, the system automatically triggers synchronous updates and consistency checks on the other side according to the dynamic binding relationship. This is persisted through an integrated storage and change message push mechanism to complete the dynamic maintenance and data fusion of the spatiotemporal digital base.

[0016] Through the above-mentioned technical means, this application achieves dynamic traceability of the base plate and real-time linkage between space and business while ensuring conversion accuracy and processing efficiency. It solves the technical problems of manual dependence, process fragmentation, static base plate and data silos, and completes the technical leap from open-loop manual processing to closed-loop automated collaboration, and from static isolated storage to dynamic traceable base plate. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method of this application; Figure 2 This is a detailed process diagram based on step S10 in the first embodiment; Figure 3 This is a detailed process diagram based on step S20 in the first embodiment; Figure 4 This is a detailed schematic diagram of step S40 based on the first embodiment; Figure 5 This is a detailed schematic diagram of step S60 in the first embodiment; Figure 6 This is a detailed process diagram based on step S70 in the first embodiment; Figure 7 This is a schematic diagram of another detailed process based on step S70 in the first embodiment; Figure 8 This is a schematic diagram of the overall architecture; Figure 9 Timing diagram of a pipeline for efficient preprocessing of multi-source heterogeneous data; Figure 10 A flowchart illustrating the integrated conversion process between BIM components and CIM elements; Figure 11 A timeline diagram for dynamic maintenance and version traceability of the spatiotemporal digital base plate during engineering construction; Figure 12 A data connectivity architecture diagram for the entire lifecycle and multiple stages of engineering construction; Figure 13 A timeline diagram for the bidirectional linkage and updating of the spatiotemporal digital baseboard and engineering construction business data; Figure 14 This is a schematic diagram of the equipment structure of the hardware operating environment involved in the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] In the field of data governance throughout the entire construction lifecycle, existing BIM and CIM integration solutions mainly rely on manual import, decentralized preprocessing, and static base plate technology. These solutions involve manual coordinate system calibration, format conversion, topology repair, and lightweighting, which are then stored in the database and displayed through layer overlay. The base plate is built once, and subsequent updates rely on manual re-import. While this may work in scenarios with small data volumes and single phases, it is essentially an open-loop, fragmented processing paradigm: lacking standardized component-element mapping rules and automatic conversion algorithms, resulting in low conversion efficiency and poor accuracy; independent preprocessing steps, leading to lengthy processes and high error rates; and static, fixed base plates without incremental updates or version management, causing data to lag behind the actual engineering entity and failing to support full-lifecycle traceability.

[0023] The core dilemma of the above-mentioned technical approach lies in the fact that the data governance method, which relies on manual conversion, decentralized preprocessing, and static baseboards, suffers from a lack of rules, a broken pipeline, and a lack of dynamic iteration. This fundamentally contradicts the inherent requirements of the entire engineering construction cycle for automation, integration, traceability, and collaboration.

[0024] To address the aforementioned shortcomings, this application proposes a method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard. This is achieved by constructing an integrated preprocessing pipeline (adaptive coordinate system transformation, quality check, topology repair, and hierarchical lightweighting), a dual-driven transformation algorithm based on geometric topology matching and intelligent attribute binding using a mapping rule base, real-time incremental capture and version chain management, and bidirectional binding of spatial unique codes and business association keys, along with full-cycle bidirectional transmission mapping, forming a closed-loop data governance system. Specifically, this includes: multi-source data being preprocessed to generate standardized element data; initial full-volume writing to establish the initial baseboard; subsequent changes being captured and differentially calculated before incremental writing to generate version nodes; and establishing dynamic binding of spatial codes and business association keys, along with bidirectional transmission mapping at each stage, to achieve spatial-business linked updates and integrated persistence.

[0025] Through the above-mentioned technical means, this application achieves dynamic traceability of the base plate and real-time linkage between space and business while ensuring conversion accuracy and processing efficiency. It solves the technical problems of manual dependence, process fragmentation, static base plate and data silos, and completes the technical leap from open-loop manual processing to closed-loop automated collaboration, and from static isolated storage to dynamic traceable base plate.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] Based on this, embodiments of this application provide a method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital backplane, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method of this application. In this embodiment, the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method includes steps S10~S40: Step S10: Obtain full-cycle data of the project construction and preprocess the full-cycle data; During the data governance process throughout the entire construction project lifecycle, data from multiple sources and in various formats is integrated. This lifecycle data includes at least Building Information Modeling (BIM) component data, City Information Modeling (CIM) element data, construction business management data, and IoT sensing data. BIM component data typically originates from 3D modeling software used in the design phase, such as Revit, Bentley, or ArchiCAD. The data format is primarily Industrial Basic Class (IFC), but may also include proprietary software formats. BIM component data contains a wealth of detailed information, such as the geometric dimensions, spatial location, material properties, construction phase parameters, and equipment codes of building components like walls, beams, slabs, and columns. CIM element data originates from the Urban Geographic Information System (GIS), and data formats include Shapefile, GeoJSON, CityGML, or 3DTiles. Its content covers road centerlines, site boundaries, existing building outlines, underground pipeline networks, green areas, and terrain elevation models. Business management data refers to non-spatial information generated during the engineering construction process, such as design change orders, construction schedules, quality acceptance records, detailed investment estimates, and operation and maintenance inspection work orders. This data is typically stored in relational databases. IoT sensing data comes from various sensors deployed on-site, including but not limited to stress strain gauges, displacement sensors, temperature and humidity meters, and video surveillance equipment. The data is uploaded in real time via message queue telemetry transmission protocols or narrowband IoT protocols.

[0028] After acquiring the aforementioned full-cycle data, a unified preprocessing operation is performed. This preprocessing operation is organized into an automated pipeline, which sequentially includes four stages: adaptive coordinate system transformation, data quality check, automatic topology consistency repair, and hierarchical lightweighting. In the adaptive coordinate system transformation stage, the system first identifies the original coordinate system information associated with each piece of input data, such as a local engineering coordinate system, a city-independent coordinate system, or a geographic coordinate system. For BIM component data, a local Cartesian coordinate system defined by the modeling software is typically used, with the origin set at a corner of the building. For CIM feature data, it may already be in the national geodetic coordinate system, but data from different sources may use coordinate systems from different generations, such as the Xi'an 80 coordinate system, the Beijing 54 coordinate system, and the 2000 national geodetic coordinate system promoted in recent years. The system has a pre-built coordinate system transformation rule library, which stores seven-parameter Bursa transformation parameters or polynomial fitting parameters between various coordinate systems. When it is detected that the coordinate system of a certain data is inconsistent with the predefined target coordinate system, namely the 2000 National Geodetic Coordinate System and the 1985 National Elevation Datum, the pipeline automatically matches the corresponding transformation parameters from the rule base, calls the open-source geographic data processing library or professional coordinate transformation engine to perform batch transformation, and unifies all spatial data to the same geodetic datum and elevation datum.

[0029] Next comes the data quality inspection stage. This stage automatically scans the data after coordinate system transformation, checking for data integrity, attribute standardization, and logical consistency. For example, it checks whether BIM components are missing key attribute fields, such as unique component identifiers or material grades; whether CIM surface features are closed; and whether primary keys in business data tables are duplicated or whether foreign keys point to non-existent records. For automatically correctable issues, such as missing default attribute values, the system fills them in according to preset default rules. For issues that cannot be automatically corrected, the system generates a quality inspection report and pushes it to a manual review interface, where technical personnel can quickly confirm or correct them using visual tools, thus forming a quality assurance mechanism that combines machine and human inspection.

[0030] After quality checks, the pipeline enters the automatic topology consistency repair stage. This stage primarily targets spatial data, especially geometric models converted from BIM and CIM geographic features obtained from surveying. Common topology errors include dangling points (endpoints) of line features not being correctly connected to other lines, undue overlaps or gaps between polygon features, non-coincident boundaries of adjacent polygons, and conflicts in penetration or containment relationships between 3D components. A graph-based topology reconstruction algorithm is used to abstract spatial features into a graph structure, with nodes representing geometric vertices and edges representing connections or adjacencies. By searching for outlier nodes and edges in the graph, missing connections are automatically added, overlapping areas are trimmed, or closed boundaries are generated through interpolation. After this repair, all spatial data meets the topology correctness requirements for subsequent fusion.

[0031] The final step is hierarchical lightweighting. Considering the massive amount of data throughout the entire construction cycle, a complete BIM model of an industrial plant or urban area may contain millions of components, and CIM terrain data may reach tens of gigabytes. To achieve smooth visualization and interaction on browsers or mobile devices, the repaired data undergoes dynamic precision adjustment. Specifically, multiple detail levels are preset for each model, with different levels corresponding to different viewing distance thresholds. During close-up observation, the system retains the complete geometric details and high-definition texture maps of the components; as the viewing distance increases, the system automatically switches to a lower detail level, at which point small components are removed, adjacent faces are merged, and texture resolution is compressed, thus significantly reducing the number of model faces. This lightweighting operation does not modify the backup of the original data; it only generates a derived version for real-time rendering. The original high-precision data remains intact in the archive area of ​​the base plate for subsequent high-precision analysis. By sequentially executing these four steps, efficient and standardized preprocessing of the entire lifecycle data is completed, laying the data foundation for subsequent automatic conversion and fusion. The complete logic of the above preprocessing pipeline can be viewed... Figure 9 , Figure 9 A timing diagram of an efficient preprocessing pipeline for multi-source heterogeneous data.

[0032] Step S20: In the preset component element classification mapping rule library, a dual-drive conversion algorithm combining geometric topology matching and attribute intelligent binding is used to automatically match the spatial contour, topological relationship and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data. After completing the above preprocessing, the integrated automatic conversion between BIM components and CIM elements begins. The core of this conversion process is a pre-built component element classification and mapping rule base. This rule base is not a simple static lookup table, but a knowledge system containing hierarchical semantic correspondences and spatial matching logic. During the construction of the rule base, technical personnel establish many-to-many mapping relationships between common BIM component types and CIM element types in engineering practice, based on industry standards such as Building Information Modeling (BIM) classification and coding standards and geographic information classification and coding rules. Taking the architectural field as an example, BIM building component categories include walls, columns, beams, slabs, doors, and windows; structural component categories include foundations, frame beams, and secondary beams; and MEP component categories include air ducts, water pipes, and cable trays. CIM element categories include roads, plots, building ground projections, underground pipelines, green belts, and site surfaces. The rule base records which CIM element category each type of BIM component should be mapped to, and the priority differences that mapping rules may have in different contexts.

[0033] Based on the aforementioned rule base, a dual-drive transformation algorithm combining geometric topology matching and intelligent attribute binding is employed to automatically match preprocessed BIM component data and CIM feature data. The first step of this algorithm is to extract the spatial outline, topological relationships, and elevation range of the BIM components. The spatial outline refers to the two-dimensional projection boundary or three-dimensional envelope of the component in geographic space. For wall components, their spatial outline can be simplified to a rectangular strip extending a certain thickness along the wall's centerline; for column components, their spatial outline is typically a rectangular or circular envelope circle around the column base. Topological relationships describe the connection, inclusion, or adjacency between the component and other surrounding components and the terrain. For example, the two ends of a beam overlap the tops of two columns, or a room is enclosed by four walls. The elevation range is the distance between the bottom and top of the component relative to a unified elevation datum. For example, the elevation of a basement floor slab is negative, while the parapet wall of a roof is at a higher position.

[0034] The algorithm extracts the spatial contours, topological relationships, and elevation ranges corresponding to CIM elements. Building element contours in CIM typically originate from topographic mapping and are closed polygonal boundaries; road element contours are strip-shaped areas buffered outwards from their centerlines; and pipeline element contours are their centerlines plus the pipe diameter radius. After extraction, the algorithm calculates pairwise similarity between BIM components and CIM elements. The similarity calculation integrates three dimensions: the proportion of overlapping spatial contours, the consistency of topological relationships, and the proportion of overlapping elevation intervals. For example, if a standard floor column component in BIM has a horizontal projection contour that significantly overlaps with the boundary of a construction site in CIM, and the column's elevation range is near the average elevation of the site, then the column has a high matching score with that site. The algorithm outputs a candidate CIM element list for each BIM component, sorting them from highest to lowest matching score, retaining only candidates with a matching score exceeding a preset threshold. This threshold can be dynamically adjusted according to project requirements and is generally set above 70%.

[0035] After geometric topology matching is completed, the intelligent attribute binding stage begins. This stage utilizes the matching results to automatically populate the rich attribute information carried by the BIM components into the corresponding CIM element attribute tables. Specific operations include: reading the attribute fields of successfully matched BIM components, such as professional type (architecture or structural engineering), unique identifier code (globally unique within the BIM model), material grade (e.g., concrete strength grade C30 or steel grade Q345), construction status (completed, under construction, or awaiting demolition), and design parameters (e.g., design load value, fire resistance rating). Based on predefined attribute mapping relationships in the rule base, the algorithm batch-writes these attribute values ​​into the specified extended attribute fields of the CIM elements. For example, the material grade of the BIM component will be mapped to the "Structural Material" field of the CIM element, and the unique identifier code will be mapped to the "Source Model ID" field for subsequent traceability. Simultaneously, the layer style and spatial code of the CIM elements are automatically updated. The layer style controls the rendered appearance of the element in the 2D and 3D maps, such as using different colors or textures depending on the material. Spatial codes are short identifiers used internally by the CIM platform for rapid retrieval and spatial indexing. During the binding process, they are regenerated based on the mapping results, ensuring a clear and traceable correspondence between the coding system and the BIM source. Through the dual-driven collaborative work of geometric topology matching and intelligent attribute binding, high-precision, fully automated, and integrated conversion from BIM components to CIM elements is achieved, providing semantically unified and spatially accurate standardized element data for subsequent foundation slab construction. The dual-driven conversion process based on geometric topology matching and intelligent attribute binding can be viewed... Figure 10 . Figure 10 A flowchart for the integrated conversion of BIM components and CIM elements.

[0036] Step S30: Batch bind the successfully matched BIM component attributes to the CIM feature attribute fields to generate standardized feature data; After the automatic matching of spatial contours, topological relationships, and elevation ranges is completed, the next stage is attribute batch binding and standardized element data generation. The core task of this stage is to transform the correspondence established in the aforementioned matching process into substantial data fusion, that is, to migrate the refined attribute information contained in BIM components to the corresponding CIM elements, thereby forming standardized element data that possesses both macro-geo-spatial characteristics and carries micro-engineering attributes.

[0037] First, paired records that have passed similarity filtering are retrieved from the matching results database. Each pair of records contains a unique identifier for a BIM component and unique identifiers for one or more candidate CIM elements, with the highest match being selected as the final binding target. Next, the complete attribute set of the BIM component is loaded. This attribute set may contain dozens or even hundreds of fields, covering geometric parameters, material parameters, design parameters, construction parameters, and operation and maintenance parameters. Geometric parameters include the component's length, width, height, volume, surface area, and center of gravity coordinates; material parameters include concrete grade, rebar grade, steel grade, and insulation layer thickness; design parameters cover design load, fire resistance rating, and sound insulation performance; construction parameters include construction start date, completion date, construction unit name, and quality inspection conclusion; and operation and maintenance parameters include equipment number, maintenance cycle, and last maintenance time. The types of attributes carried by BIM components from different professional fields vary significantly. Instead of rigidly limiting attribute types, all available attribute fields of the component are read through a dynamic reflection mechanism.

[0038] Next, based on the predefined attribute mapping table in the component element classification mapping rule base, the aforementioned BIM attributes are mapped one by one to the target fields of the CIM elements. The attribute mapping table is essentially a collection of key-value pairs, where the key is the standard name of the BIM attribute, and the value is the column name in the CIM element attribute table. For example, the rule base defines that the BIM attribute "structural material concrete grade" maps to the CIM element attribute "material grade," the BIM attribute "fire resistance rating" maps to the CIM element attribute "fire resistance rating," and the BIM attribute "construction stage code" maps to the CIM element attribute "construction status." For attributes not explicitly defined in the rule base, a default processing strategy is adopted: no automatic binding is performed; instead, they are stored in the extended attribute JSON field of the CIM element, retaining the original data for subsequent manual review or application layer parsing. This design ensures the efficiency of automatic filling of commonly used attributes while avoiding information loss due to incomplete rules.

[0039] The attribute binding process employs batch transaction operations. First, an attribute update mapping table is constructed in a temporary memory area using the unique identifier of the CIM feature as the key. For each matching record, the corresponding BIM attribute value is extracted, and after necessary unit conversions (e.g., converting millimeters in BIM to meters required by CIM) and data type normalization, it is filled into the update mapping table. A CIM feature may match multiple BIM components simultaneously; for example, a plot of land may correspond to column components of multiple building units. In this case, the system needs to aggregate the attributes, for example, taking the highest value of all component material grades as the material grade of the plot, or concatenating the unique identifiers of all components into a list and storing it in the "Associated Component List" field of the CIM feature. Aggregation rules are also pre-configured in the rule base, allowing for different strategies such as maximum, minimum, average, merging lists, or retaining the first value, depending on project needs.

[0040] After attribute binding is complete, standardized feature data is generated immediately. Standardized feature data is a unified data object that includes the original geospatial information of the CIM feature, the converted spatial geometric information, and the engineering attribute information bound from BIM. The geometric information, such as feature boundary polygons, centerlines, and elevation values, is stored in a common geographic data format, such as geometric objects in GeoJSON or geometric entities in CityGML. The attribute information is stored as a collection of key-value pairs. The keys use standardized naming conventions, such as "sourceModelId", "constructionStatus", and "materialGrade", while the values ​​can be strings, numbers, dates, or structured arrays. A globally unique identifier is generated for each piece of standardized feature data. This identifier is cross-referenced with the original BIM component identifier and the original CIM feature identifier to allow for reverse tracing of the data source during subsequent basement updates and traceability.

[0041] Finally, the standardized feature data is written to the intermediate storage area, awaiting the next full write operation. Before writing, an integrity check is performed to check whether required attribute fields are empty, whether spatial geometry is valid, and whether reference relationships are closed loops. For records that fail the check, the system marks them as pending exceptions and outputs detailed error logs, but does not interrupt the entire conversion process, ensuring that other normal data can continue to advance to the baseboard construction stage. Through the above steps, the batch, configurable, and traceable binding conversion from BIM component attributes to CIM feature attributes is completed, generating standardized feature data with unified semantics, rich attributes, and spatial accuracy, providing high-quality data raw materials for the spatiotemporal digital baseboard.

[0042] Step S40: Write the standardized element data in full to establish a spatiotemporal digital baseboard, and perform change capture and difference calculation on the standardized element data that has changed subsequently to separate the changed part. Write the changed part incrementally into the current spatiotemporal digital baseboard, generate version nodes and persistently store them in a unidirectional version chain. After obtaining standardized element data, the spatiotemporal digital baseline is constructed and dynamically maintained. The spatiotemporal digital baseline is a specially designed large-scale spatial database. Its physical storage can be based on a relational database with spatial expansion, or on a next-generation spatial database or graph database. The core feature of this baseline is its ability to store the entire data lifecycle and support high-frequency incremental updates and complete version tracking.

[0043] The first step is to perform a full data write to establish the initial version. Upon receiving standardized element data for a project for the first time, a full import operation is performed. This standardized element data set is written to the baseline table area of ​​the baseboard database. During the write process, an internal storage identifier is assigned to each standardized element data record, and the timestamp of the first write is recorded. Additionally, an initial version node is generated. This version node is an independent metadata record containing a version number (usually an auto-incrementing integer or timestamp encoding), version creation time, version description (e.g., "Initial version, from the design phase BIM and CIM integration"), and an associated data snapshot identifier. The version node is persisted to the version management table and serves as the head node of a unidirectional version chain. After the full write is complete, the spatiotemporal digital baseboard has a complete initial state, and upper-level applications can query and visualize this version.

[0044] As construction progresses, standardized element data will change. This could involve adding new component models for the construction phase, modifying the routing parameters of an underground pipeline, or deleting a demolished building element. Two mechanisms are used to capture these changes: proactive monitoring and periodic scanning. Proactive monitoring involves connecting to the change event interface of the BIM collaboration platform. When designers submit model modifications in the BIM software, the platform sends a message containing the changed component ID and change type (addition, modification, or deletion). Upon receiving this message, the corresponding standardized element data update process is immediately triggered. Periodic scanning addresses changes driven by IoT sensing data. For example, if sensors detect abnormal pressure in a pipeline section, the system analyzes the data and determines that the pipeline needs to be marked as alarming, thus triggering changes in business data. A scheduled task scans the change log table of the business data source every few minutes to capture new change records. These two mechanisms work together to ensure the real-time nature and reliability of change capture.

[0045] Once a change is detected, a difference calculation is performed. The core of this calculation is comparing the changed standardized feature data with the corresponding version of the same feature data on the current baseboard to identify the specific differences. A field-by-field comparison is used: for spatial geometry fields, the difference and union of geometric objects are calculated; for attribute fields, each attribute value is compared for equality. The results of the difference calculation are packaged into a change increment package, which contains only the changed fields or geometric parts, without carrying any unchanged redundant information. For example, if a BIM component only modifies its material grade attribute while its geometry and all other attributes remain unchanged, the increment package will only record the component's identifier, the modified attribute name, and the old and new values. This fine-grained difference extraction compresses the amount of update data, enabling efficient incremental writes.

[0046] Incremental writing is the process of applying the aforementioned incremental change package to the current baseboard. Instead of simply overwriting the original records, it writes by appending versions. Specifically, for each standardized feature data that has changed, a new record is inserted into the baseboard's change history table. This record includes the change time, change type, a reference to the data snapshot before the change or a complete copy of the data after the change, and the associated version node number. Simultaneously, the current data pointer in the base table is updated to point to the latest record version. Therefore, the baseboard always retains data from all historical versions, while current queries return the latest version by default. During the writing process, database transactions are used to ensure atomicity; either all modifications in the incremental change package are successfully committed, or all are rolled back, avoiding data inconsistencies caused by partial updates.

[0047] After each incremental write, a new version node is generated. This version node is also persisted to the version management table and linked to the tail of the unidirectional version chain in chronological order. Each version node records summary information about the change, such as the number of data entries involved, the source of the change (i.e., which change capture event), and the user or system identifier of the change operation. Version nodes are linked together by pointers to the previous version. This unidirectional linked list design ensures that the backtracking direction of versions is unique and clear, facilitating reverse traversal of history starting from the latest version.

[0048] Simultaneously, a version index table is maintained, using the version number as the key to quickly locate the storage location of version nodes. Through the complete process of full write, change capture, difference calculation, incremental write, and version node linking described above, a fundamental transformation of the spatiotemporal digital baseboard has been achieved from static one-time storage to dynamic iterative evolution. This allows the baseboard to update in real time following changes in the engineering entity, while ensuring that the state at every moment is traceable and rollbackable. Based on the complete logic of the above dynamic maintenance and version traceability, you can view... Figure 11 , Figure 11A timeline diagram for dynamic maintenance and version traceability of the spatiotemporal digital baseboard for engineering construction.

[0049] In addition, after the step of generating version nodes and persistently storing them in a one-way version chain, the method further includes: In response to a version rollback request sent by a user or an upper-layer application, the target version identifier carried in the version rollback request is parsed, the corresponding version node is found by traversing the unidirectional version chain, and the full data snapshot or incremental change sequence associated with the version node is retrieved from the archive area of ​​the spatiotemporal digital base corresponding to the version node, and the complete spatiotemporal digital base state of the version corresponding to the target version identifier is reconstructed. In response to the version comparison request, extract the spatiotemporal digital base status corresponding to the two different version nodes, perform item-by-item difference analysis on the spatial data geometric elements and business data attribute fields in the two statuses, and output a difference comparison report; In response to a rollback request, the current baseboard state is completely replaced with the baseboard state associated with the specified historical version node, and a new version node is generated to record this rollback operation.

[0050] After incremental writing and version node generation are completed on the spatiotemporal digital baseboard, and persistent storage is achieved via a unidirectional version chain, comprehensive version management capabilities are further provided for upper-layer applications and operations personnel. These version management capabilities include three core functions: version rollback, version comparison, and version revert. All of these functions are implemented based on a unidirectional version chain data structure, which records the entire change history from the initial version to the current latest version. Each version node holds a pointer to the previous version node, as well as the full data snapshot or incremental change sequence associated with that version node.

[0051] For the version rollback function, the system first receives a version rollback request from a user or upper-layer application. This request is a structured instruction object carrying a target version identifier. The target version identifier can be an integer version number, such as version 7, or a timestamp version tag, such as a snapshot built on December 1, 2025. Upon receiving the request, the system starts from the latest version node and traverses backward along the unidirectional version chain. During the traversal, the number of each version node is compared with the target version identifier. The traversal stops when a version node that completely matches the target version identifier is found. Next, the system reads the associated data content from the spatiotemporal digital baseboard archive area corresponding to that version node. The archive area is a specially designed cold and hot separated storage area that retains two optional storage formats for each version node: a full data snapshot or an incremental change sequence. A full data snapshot is a complete backup of all standardized feature data at a given moment in time. It typically requires a large amount of storage space but offers fast reconstruction. An incremental change sequence is a log collection of all change operations from the previous version to the current version. It requires less space, but reconstruction requires a step-by-step replay starting from the baseline version. Depending on the configured backtracking performance strategy, either a full snapshot or an incremental sequence is selected. If an incremental sequence is used, it starts from the initial version or a recent full snapshot version, sequentially applying all incremental operations from that version to the target version until the complete state of the target version is restored. After reconstruction, the complete spatiotemporal digital baseboard state is loaded into a read-only query instance for visualization or data analysis by upper-layer applications, without affecting the currently used latest baseboard instance.

[0052] For the version comparison function, a version comparison request is received. This request carries two different version identifiers, such as version 3 and version 5, or version 2 and the current latest version. The complete spatiotemporal digital baseboard states corresponding to the two versions are independently extracted according to the version backtracking process described above, and these two states are loaded into two comparison caches in memory. The comparison engine then performs a point-by-point difference analysis on the spatial data geometric elements and business data attribute fields in the two states. The difference analysis of spatial geometric elements includes: comparing the position coordinates, contour boundaries, topological connections, and elevation values ​​of components with the same spatial code in the two versions, and calculating geometric changes such as displacement distance and area change rate. The difference analysis of business attribute fields includes: comparing attribute values ​​field by field, identifying which fields have been added, modified, or deleted, and recording the old and new values. The results of the difference analysis are packaged into a difference comparison report, which uses a structured format such as JSON or an HTML table. This report includes the following sections: a change summary (total number of data items involved, distribution of change types), a detailed change list (spatial code, field name, old value, new value, and change timestamp for each change), and visual aids (e.g., parameters that can generate a comparison view overlaying the two version models). This difference comparison report is then output to the requesting party, which can be a web-based front-end page, an automated test script, or a data quality auditing tool.

[0053] For the rollback function, a rollback request is received. This request carries an identifier for a specified historical version node, indicating that the user wishes to restore the currently running spatiotemporal digital baseboard to the state of that historical version. Before executing the rollback operation, a security check is performed first. The security check includes: verifying that the target version node does exist in the unidirectional version chain, confirming that the rollback operation will not disrupt critical transactions of upper-layer applications that depend on the current baseboard state, and recording the permissions and reasons for the operation by the current operator. After the security check passes, a distributed transaction is started, which spans multiple tables in the baseboard database. The first step within the transaction is to back up the full data of the current baseboard state to a temporary recovery area so that it can be quickly restored in case of rollback failure or the need to undo the rollback. The second step is to load the complete state data from the archived data associated with the target historical version node. The loading process is the same as the reconstruction logic of the version rollback function. The third step is to overwrite all base tables in the current baseboard database with the loaded historical state data, including spatial data tables, business data association tables, and some metadata of version management tables. The overwrite operation employs an atomic replacement approach, first writing new data to the shadow table and then instantly switching tables by renaming them, thus minimizing the impact on upper-layer applications' read / write operations. The fourth step involves generating a new version node after the rollback is complete. This new version node's version number is incremented based on the current latest version number, and its change description field explicitly records that this was a rollback operation, noting the target version identifier, the rollback initiator, the rollback time, and the security check conclusions. This new version node is also linked to the tail of the unidirectional version chain, making the rollback operation itself a traceable historical record. It's important to note that the rollback operation does not delete or overwrite the rolled-back version nodes; these nodes remain in the unidirectional version chain, allowing users to revert to them later. Through the complete implementation of version backtracking, version comparison, and rollback functions, enterprise-level version management capabilities are provided for the spatiotemporal digital baseboard. This enables precise restoration of the baseboard's state at any point in the entire project construction cycle, quantitative analysis of differences between any two versions, and safe reversal of erroneous changes without loss of historical data.

[0054] Step S50: Based on the standardized element data in the spatiotemporal digital base plate, configure a spatial unique code for the spatial data in the standardized element data, configure a business association key for the associated business data, and establish a dynamic binding relationship between the spatial unique code and the business association key. Building upon the existing spatiotemporal digital baseboard with dynamic update capabilities, the next step is to establish precise relationships between spatial data and related business data within the baseboard. The core technical approach at this stage involves configuring unique spatial codes for spatial data, configuring business association keys for related business data, and establishing a dynamic binding relationship between the two.

[0055] The configuration process for the spatial unique code is as follows: It iterates through all standardized element data in the spatiotemporal digital base, extracting data records belonging to the spatial scope. This includes all building, structure, and equipment models converted from BIM components, as well as geographical elements such as plots, roads, pipelines, and green spaces directly incorporated from CIM elements. For each spatial data record, a globally unified code generator is invoked to generate a unique string identifier that is never repeated within the project scope or even on the city-level platform. The string identifier is constructed using a hierarchical segmentation method. For example, the first segment represents the project code, the second segment represents the data category (e.g., building, road, or pipeline), the third segment represents the serial number within that category, and the fourth segment may contain version year information. User-defined code prefixes are also supported to meet the coding habits of different engineering management systems. The generated code is not only written to a dedicated code field in the spatial data record but also stored in a spatial code index table. This index table uses the spatial code as the primary key and records the corresponding data storage location and data type.

[0056] Configuring business association keys establishes a similar identification system for data in the business management system. Business management data may already carry key values ​​assigned by the Enterprise Resource Planning (ERP) system or project management system, such as work order numbers, contract numbers, and material batch numbers. Instead of forcibly replacing these existing key values, a standard business association key is configured for them. Specifically, all business records that need to be associated with spatial data are extracted from the business database, such as design change orders, construction schedule items, quality acceptance records, and maintenance work orders. For each business record, it is checked whether a compliant association key field already exists. If it does, it is used directly; if it does not exist or the format is not standardized, a supplementary association key is generated based on the business record type and creation timestamp. All business association keys are also recorded in a business index table, which maintains the mapping relationship between business association keys and the original primary keys of the business data.

[0057] Establishing a dynamic binding relationship between spatial unique codes and business association keys is crucial in this step. Two binding modes are provided: automatic matching and manual binding. In automatic matching mode, the system automatically establishes the binding based on pre-defined mapping rules. For example, a rule can be defined as: when the spatial unique code of a BIM component and the business association key of the construction schedule item associated with that component have the same substring in name, or when their creation times are close and their spatial locations overlap, a binding is automatically established. A more reliable automatic matching method utilizes the bidirectional data transmission mapping to be established throughout the entire lifecycle. Within this transmission mapping framework, data encoding is inherited hierarchically from the planning stage to the design stage, and then to the construction and operation and maintenance stages. For example, the spatial control code obtained by a building unit in the planning stage will be inherited as a prefix into the spatial unique code of every BIM component in the design stage, and the business association key of the construction process corresponding to these BIM components will contain some fields of the aforementioned spatial code. Utilizing this encoding inheritance relationship, the binding between spatial codes and business association keys is automatically completed through string matching or regular expressions.

[0058] In manual binding mode, a visual binding management interface is provided. This interface displays unbound spatial data records and unbound business data records in a list format, and allows users to associate a spatial data record with one or more business data records by dragging and dropping or selecting. Manually established binding relationships are also recorded in the binding relationship table.

[0059] After the binding relationship is established, a dynamic binding relationship table is maintained. The core fields of this table include: spatial unique code, business association key, binding type, binding effective time, binding expiration time, and binding strategy parameters. The binding type distinguishes whether the binding is permanently valid or only valid during a certain project phase; for example, a binding during the construction phase may expire after delivery. The binding strategy parameters specify whether business data is automatically updated when spatial data changes, or vice versa, and whether the update direction is unidirectional or bidirectional. The above binding relationship is not static; a dynamic management interface for binding relationships is provided, allowing bindings to be added, modified, or deleted as needed during project construction. Simultaneously, changes to binding relationships are monitored, and the binding cache in memory is updated in real time to ensure that subsequent linked update operations can quickly find the corresponding code association. Through the above configuration, a flexible, configurable, and dynamic bridge is built between spatial data and business data, laying the foundation for the next step of full-cycle phase mapping and real-time linked updates.

[0060] Step S60: Through the dynamic binding relationship, establish a bidirectional data transmission mapping between each stage of the entire life cycle of the project construction. The bidirectional transmission mapping includes a top-down hierarchical mapping and a bottom-up hierarchical implementation. With the dynamic binding relationship between spatially unique codes and business association keys already established, this binding relationship is further utilized to construct a bidirectional data transmission mapping that spans all stages of the entire project lifecycle. These lifecycle stages include planning, design, construction, delivery, and operation and maintenance. The core function of this mapping is to enable seamless data flow between different stages, supporting both forward transmission from upstream to downstream stages and reverse feedback from downstream stages to upstream stages.

[0061] First, a unified coding inheritance system is established. At the project's inception, during the planning phase, a top-level code is generated for each spatial control unit, such as a plot of land to be developed or a planned road. This code adopts a hierarchical structure, including a project identifier, a region identifier, and a unit sequence number. This top-level code is written into the CIM element attributes corresponding to the spatial control unit and serves as the coding prefix for all subsequent derived data. When the project enters the design phase, when designers create the BIM model, each component in the model automatically inherits the top-level code of its spatial control unit and adds a component type code and serial number, forming a unique spatial code for that component. For example, a control unit with the top-level code PJ01-BLK02 might have a column with the code PJ01-BLK02-COL-001. Similarly, task packages, quality acceptance points, and equipment ledgers in the construction phase all require referencing the corresponding unique spatial code or its derived code as part of the business association key during creation. By setting up a coding rule engine at the data entry point of each phase, the above inheritance rules are enforced, thereby ensuring a traceable coding lineage between data entities in different phases.

[0062] Based on the aforementioned coding inheritance system, a top-down hierarchical mapping is established. The specific implementation mechanism of this mapping is as follows: During the planning phase, spatial control indicators, such as land boundary lines, maximum floor area ratio, building height limits, and green space ratio requirements, are stored in the planning database in parametric form, and these indicators are bound to their corresponding spatial control codes. When personnel in the design phase begin building the BIM model, the mapping engine automatically reads the control indicators stored in the planning phase and locates the control unit to which the current design component belongs through the spatial control code.

[0063] Subsequently, the engine transforms planning indicators into design constraints. For example, it uses the land boundary line as the inviolable area for site layout in the BIM model, and converts the floor area ratio limit into a total building area limit constraint. It also checks in real time whether design parameters exceed these constraints, issuing warnings when they do. Furthermore, component information from the design phase, such as component geometry, material requirements, and connection methods, is automatically mapped to construction phase process nodes and quality acceptance standards. Specifically, when creating a construction task, the construction management system uses the component code to find the corresponding BIM component, reads its attributes, and automatically generates a construction process list, a required material list, and actual measurement standards for quality acceptance for that component.

[0064] Simultaneously, a bottom-up, hierarchical mapping system is established. This mapping is responsible for transmitting the execution results and feedback data from downstream stages back to upstream stages. For example, during the construction phase, on-site quality inspection personnel input the actual finished dimensions of a component, concrete rebound strength values, and photos of concealed works via mobile terminals. This data carries a unique spatial code for the component. The feedback engine periodically scans newly entered inspection data in the construction database, parses its associated component codes, and then writes the inspection conclusions, such as qualified or unqualified, and actual dimensional deviations, back into the corresponding attribute fields of the design BIM model, allowing designers to visually see the construction feedback in the BIM software. Similarly, equipment failure information, maintenance history, and energy consumption data recorded during the operation and maintenance phase are back-linked to the as-built model in the delivery phase through equipment codes, and further linked to the original parameters in the design phase, forming a complete equipment history file. Design defects or construction legacy issues discovered during the operation and maintenance phase can also be submitted to the responsible parties in the design or construction phases through reverse mapping, forming a closed-loop quality improvement process.

[0065] The top-down, hierarchical mapping and the bottom-up, hierarchical implementation together constitute a bidirectional transmission mapping. These mapping rules are configured in a mapping rule engine, which is based on an encoding inheritance system and indexed by spatially unique codes and business association keys, supporting user-defined mapping logic. Mapping rules can be simple field copying or complex calculation transformations, such as converting concrete grades from the design stage to mix proportion parameters in the construction stage, or calculating the deviation between measured data and theoretical design values ​​in the construction stage and storing it in a quality dashboard.

[0066] In addition, a mapping execution log function is provided, recording the source data identifier, target data identifier, mapping time, and execution result for each mapping operation, facilitating the troubleshooting of data inconsistencies. Through this bidirectional data transfer mapping, data at each stage of the entire engineering construction lifecycle is no longer an isolated island, but forms an organic whole. Data can flow forward along the coding inheritance chain to generate value, and can also be aggregated and fed back to optimize the source design. Based on the above architecture of bidirectional data transfer mapping between all stages of the entire lifecycle, you can view... Figure 12 , Figure 12 A data connectivity architecture diagram for the entire lifecycle and multiple stages of engineering construction.

[0067] Step S70: Based on the bidirectional data transmission mapping, when spatial data or business data changes, the other party is automatically triggered to synchronize and verify consistency according to the dynamic binding relationship, and the changes are persisted through integrated storage and change message push mechanism to complete the dynamic maintenance and data fusion of the spatiotemporal digital base.

[0068] After completing the above operations, the closed-loop control of dynamic maintenance and data fusion of the spatiotemporal digital baseboard is finally achieved. The core of this step is that when any changes occur in spatial data or business data, the synchronous update and consistency verification of another type of data can be triggered based on the established dynamic binding relationship and bidirectional transmission mapping. This data is then persisted through integrated storage and change message push mechanisms, thereby ensuring that the baseboard always reflects the latest engineering reality, while all upper-layer applications can also receive change notifications in a timely manner.

[0069] First, the triggering source of the change must be clearly defined. Changes can originate from the spatial data side, such as a component being moved five meters by the designer in the BIM collaboration platform, or the geometry of a CIM element changing due to terrain resurvey. Changes can also originate from the business data side, such as the construction progress management system updating the status of a process from "in progress" to "completed," or an IoT platform reporting that a pressure sensor reading for a pipeline exceeds a threshold, triggering an alarm. A unified change interceptor is set up in the access layer of the spatiotemporal digital base plate. This interceptor monitors all write operations to the base plate spatial database and business database, regardless of whether they originate from the user interface, API interface, or background tasks; all such operations are intercepted and enter the linkage processing flow.

[0070] When the interceptor captures a change to spatial data, the following linkage logic is executed. First, by means of the unique spatial code carried in the change record, all business association keys related to the spatial data are quickly found in the dynamic binding relationship table. If no binding is found, the linkage process is terminated, and only conventional incremental writing and version recording are performed. If one or more bindings are found, for each business association key, the corresponding business data record is located, and then the association field in the business data is automatically updated according to the update rules specified in the binding strategy parameters. For example, the unique spatial code of a road component is bound to the business association keys of multiple drainage wells. When the geometric shape of the center line of the road component is offset, the linkage engine automatically calculates the new position coordinates of each drainage well and updates the positioning field of the drainage well in the business database. At the same time, it triggers the data consistency check of the business system, for example, checking whether the new position of the drainage well is still within the red line of the road and whether there is a spatial conflict with underground pipelines. If the check fails, a warning will be generated and the spatial change will be rolled back. The above update operation also adopts database transactions to ensure atomicity, ensuring that the spatial data change and the business data update either succeed or fail at the same time.

[0071] When the interceptor captures a change to business data, reverse linkage logic is executed. The business association key in the changed business data record is extracted, the binding relationship table is reversely searched to obtain the associated unique spatial code, and then the corresponding spatial data record is located. According to the binding strategy, visual changes to spatial components are automatically performed on the spatio-temporal digital base plate. Visual changes include, but are not limited to: highlighting the component in a three-dimensional model with colors, where red represents high risk, yellow represents warning, and green represents normal; pushing a prompt message on the early warning panel of the interface, which contains the specific description of the business change and suggested handling measures; if the upper-level application supports three-dimensional view focusing, the linkage engine will also send an instruction to move the camera view to the center position of the component, which facilitates operators to quickly locate the problem area. For example, when the operation and maintenance system records a pipeline leakage alarm event, the business association key finds the corresponding pipeline component through the binding relationship, immediately renders the pipeline section as flashing red in the three-dimensional view of the base plate, and simultaneously pops up an alarm details box displaying the leakage position, occurrence time and emergency handling suggestions.

[0072] After each bidirectional update, a persistence operation is performed. Persistence is divided into two layers. The first layer is unified storage, where spatial data and business data are written to the same spatial or graph database. Unlike traditional solutions that store spatial and business data in separate databases, leading to difficulties in cross-database transactions, this approach chooses a transactional database that supports spatial data types, such as PostgreSQL with PostGIS extensions, or a graph database like Neo4j. Spatial geometric data is stored as a special attribute directly in the same table, alongside business attribute fields. This allows updates to both spatial and business data to be included in the same database transaction, avoiding the complexity and performance overhead of distributed transactions. The second layer is change message pushing. After each successful transaction commit, the change message generator constructs a standardized change event based on the committed content. This event is a structured data object containing the following fields: change type (add, modify, or delete), unique identifier of the changed object (spatial code or business association key), change timestamp (accurate to milliseconds), hash digest of the value before the change, and a complete snapshot of the data after the change. The standardized event is serialized into JSON format and then pushed to a preset message topic. The message middleware can be an open-source message queue system such as Kafka or RabbitMQ.

[0073] Upper-layer applications, including the digital twin visualization platform, collaborative management and control system, construction progress monitoring system, and operation and maintenance management system, pre-subscribe to the aforementioned message topics. When a new change event arrives, these applications consume the event according to their respective business logic, refreshing the interface display, updating statistical charts, or triggering subsequent business processes. For example, after the digital twin platform subscribes to a pipeline leak alarm event, it immediately plays particle effects of leak diffusion in the 3D scene; after the construction monitoring system subscribes to a progress change event, it recalculates the critical path and sends a reminder to the project manager. Through the above-mentioned integrated storage and change message push mechanism, real-time consistency between the spatiotemporal digital baseboard and all upper-layer applications is achieved, completing a closed-loop process from change occurrence to baseboard update to application response, thereby truly solving the ultimate problem of spatial and business disconnect and difficulty in dynamic collaboration in the data governance of the entire engineering construction cycle.

[0074] Based on the above-mentioned two-way linkage update process between spatial data and business data, you can view... Figure 13 , Figure 13 A timeline diagram for bidirectional linkage and updating of spatiotemporal digital baseboard and engineering construction business data.

[0075] Furthermore, you can also view Figure 2 , Figure 2 This is a schematic diagram illustrating the detailed process of step S10 in the first embodiment. Figure 2The steps of acquiring full-cycle data of the project construction and preprocessing the full-cycle data include S11~S12: Step S11: Perform coordinate system identification on the BIM component data and CIM element data in the full-cycle data respectively, and match the corresponding seven-parameter transformation algorithm from the pre-configured coordinate system transformation rule library to convert the local coordinate system into the national geodetic coordinate system and the national elevation datum. Step S12: Use a filtering algorithm to remove noise from the data after coordinate system transformation, and then use an interpolation algorithm to fill in the missing data values. Step S13: Automatically identify and repair errors in the data such as overlap, breakpoints, dangling, unclosed surfaces, and topological conflicts based on graph theory topology reconstruction algorithm; Step S14: Based on the preset viewing distance threshold and model detail level, perform dynamic precision adjustment on the repaired data, retaining high-precision geometry and texture in close-up shots and compressing the number of model faces in distant shots.

[0076] In the process of acquiring data throughout the entire engineering construction cycle and performing overall preprocessing operations, each step of the preprocessing pipeline was refined to possess the technical characteristics of automatic execution, configurability, and traceability. The aforementioned preprocessing pipeline executes four sub-steps in sequence: coordinate system identification and transformation, data denoising and missing value imputation, automatic topology error repair, and hierarchical lightweighting.

[0077] First, coordinate system identification and transformation. Coordinate system analysis is performed separately for BIM component data and CIM feature data in the full-cycle data. BIM component data usually comes from modeling software such as Revit, Bentley, or ArchiCAD. These software programs use a custom local Cartesian coordinate system, whose origin is often set at a corner point or grid intersection of the building. The coordinate unit is millimeters, and the coordinate values ​​are small, for example, the coordinates of a column base are (15000, 8000, -3000). CIM feature data may come from surveying results from different eras. Common coordinate systems include the Xi'an 80 coordinate system, the Beijing 54 coordinate system, and the 2000 National Geodetic Coordinate System. The elevation datum may be the 1956 Yellow Sea Elevation System or the 1985 National Elevation Datum. When accessing the data, the coordinate system metadata in the header of the data file is read first. If the metadata is missing, it is automatically inferred from the spatial reference library. For example, the range and distribution characteristics of the coordinate values ​​are used to determine whether it is latitude and longitude or projected coordinates, and whether it is millimeter-level local coordinates or meter-level geographic coordinates. After identification, the transformation parameters between the source and target coordinate systems are retrieved from a pre-configured coordinate system transformation rule base. This rule base contains dozens of common coordinate system transformation relationships, stored in a seven-parameter Bursa model or a three-dimensional four-parameter model. For local coordinates in BIM, the local coordinates are first mapped to the engineering-independent coordinate system using reference points marked in the data, and then transformed to the 2000 National Geodetic Coordinate System using the seven-parameter transformation. The vertical direction is uniformly transformed to the 1985 National Elevation Datum. During the transformation process, the projection engine in the open-source geographic data processing library is called to perform coordinate transformation on each spatial point feature, while retaining the coordinate values ​​before and after the transformation for subsequent verification. After the transformation is completed, all spatial data achieves spatial alignment at a macro-geographic scale, and the positioning error is controlled within the acceptable range for the project.

[0078] Next, data denoising and missing value imputation are performed. The data after coordinate system transformation includes noise introduced by sensor acquisition, outliers generated during model transformation, and null values ​​due to missing data records. First, filtering algorithms are used to denoise the data. Multiple filtering strategies are provided for different types of noise: for high-frequency random noise in sensor time-series data, Kalman filtering is used for state estimation, suppressing measurement noise while preserving the true trend of signal change; for isolated noise points in laser scanning point clouds, bilateral filtering or statistical outlier filtering is used, analyzing the distance distribution between each point and its neighbors to remove outliers far from the average distance; for minor jagged boundaries in the BIM model caused by format conversion, Gaussian filtering is used to smooth the vertex coordinates. The parameters of the above filtering algorithms, such as the noise covariance matrix of Kalman filtering, and the spatial and color bandwidth of bilateral filtering, can be adjusted through configuration files to adapt to the quality characteristics of different data sources. After denoising, missing value imputation is performed. Data loss can be caused by transmission packet loss, sensor malfunction, or manual input omissions. Interpolation algorithms are used for data imputation: For time-series data, such as continuous monitoring values ​​reported by IoT sensors, linear interpolation or cubic spline interpolation is used to calculate estimated values ​​based on the valid values ​​of adjacent times before and after the missing point; for spatially discrete point data, such as the elevation of geological exploration boreholes, inverse distance weighted interpolation or kriging interpolation is used to predict values ​​based on the spatial distribution and attribute values ​​of surrounding points; for missing fields in the attribute table, such as the material grade of BIM components not being filled in, default values ​​are filled in according to the component type and the general standards of the engineering area, and a flag field is added to the attribute to indicate that the value is an inferred result rather than the original value. After imputation, the data records remain complete and continuous, meeting the requirements of subsequent topology analysis and fusion.

[0079] Then, topological errors are automatically corrected based on graph theory-based topology reconstruction algorithms. This step specifically addresses geometric consistency defects in spatial data. Common topological errors include: dangling points of line features, where the endpoint of a line does not intersect with any other line, such as the end of a water pipe being suspended and not connected to a valve; overlaps or gaps between polygon features, where the boundaries of two adjacent plots should not overlap but instead intersect, or a building outline that should be closed has a small opening; and node mismatches, where the coordinates of the boundaries representing the same geographic entity in different data layers are inconsistent at their intersections. First, the spatial feature set to be corrected is converted into a graph structure: geometric vertices are the nodes of the graph, and the lines connecting or adjacent edges between vertices are the edges. Simultaneously, the original feature identifier and spatial semantic type of each edge are recorded.

[0080] Then, the algorithm searches for abnormal patterns in the graph structure. For dangling points, the algorithm traverses all endpoints, checking if they are endpoints of other lines or points on the same line within the tolerance distance. If so, it automatically adds connecting lines or moves the endpoints to the overlapping positions. For overlapping faces, the algorithm calculates the intersection of the overlapping areas and decides which face to retain, trim, or merge based on the priority of the features, such as the ownership level of the land parcel or the timeliness of the data. For face gaps, the algorithm extracts the gap boundaries and interpolates to generate new edges to connect the two faces. For tiny openings caused by coordinate rounding, the algorithm automatically closes polygons whose endpoint distances are less than a threshold. All of the above repair operations are completed within the graph framework. The system records the type of each repair and the identifiers of the features involved, generating a topology repair log for quality auditors to review. After automatic repair by the graph theory topology reconstruction algorithm, the spatial data that originally had conflicts and errors reached the topological consistency level required for GIS analysis.

[0081] Finally, a tiered lightweighting mechanism is implemented based on the viewing distance threshold and the model's level of detail. The data volume of the spatiotemporal digital baseboard throughout the entire engineering construction cycle is enormous; directly loading all details would cause rendering lag or even crashes on browsers or mobile devices. To address this issue, a tiered lightweighting mechanism was designed. Specifically, multiple levels of detail are preset for each 3D model or 2D vector element. The level numbers, from low to high, represent from coarse to fine. For example, LOD0 displays only the outline boundaries, LOD1 displays the main structure and compresses textures, LOD2 displays medium detail, and LOD3 retains all geometry and the highest precision textures. Each level is associated with a viewing distance threshold, which indicates that when the distance between the user's viewpoint and the model's center exceeds this threshold, the system automatically switches to a lower level of detail. During the preprocessing stage, dynamic precision adjustments are performed on the repaired data according to the above rules: For close-up views (areas observed by the user at close range), the complete geometric details of the components are preserved, including all vertices, edges, faces, and high-resolution texture maps; as the viewing distance increases, small components with minimal impact on visual effects, such as bolts and decorative lines, are gradually removed; adjacent coplanar patches are merged, combining multiple small patches into a large polygon; texture resolution is compressed, for example, downsampling a 2048×2048 pixel texture to 512×512. A set of configurable detail level parameter templates is provided, allowing users to balance visual effects and rendering performance according to the application scenario, such as using LOD0 to LOD1 for the flight overview mode and LOD2 to LOD3 for the apron inspection mode. The above lightweight operations do not modify the underlying original data backup; the system stores multiple derived versions of detail levels for the same element and dynamically calls them according to the current view state. Through hierarchical lightweighting, the spatiotemporal digital baseboard significantly reduces the rendering load while ensuring necessary visual information, enabling smooth interaction of large engineering scenes on ordinary workstations or tablets. By executing the above steps sequentially, the entire preprocessing process from raw multi-source data to high-quality, standardized, and lightweight spatial data is completed.

[0082] Furthermore, you can also view Figure 3 , Figure 3 This is a detailed process diagram based on step S20 in the first embodiment. Figure 3 The step of automatically matching the spatial contour, topological relationship, and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data using a dual-drive conversion algorithm combining geometric topology matching and intelligent attribute binding in the preset component element classification mapping rule base includes S21~S23: Step S21: Configure the component element classification mapping rule base to include standard correspondences between multiple types of BIM components and multiple types of CIM elements; Step S22: Extract the spatial outline boundary, topological adjacency relationship and elevation range of BIM components, and compare the similarity with the spatial outline, topological relationship and elevation range of CIM elements, and output candidate elements that meet the preset matching requirements. Step S23: Based on the matching results, batch fill the professional type, unique identifier code, material grade, construction status and design parameters of BIM components into the corresponding CIM element attribute table, and update the layer style and spatial code simultaneously.

[0083] After preprocessing the full-cycle data, the core transformation operation of automatic matching and attribute binding is performed on BIM components and CIM features. This transformation operation relies on a pre-built component feature classification mapping rule base and is implemented through a dual-drive algorithm of geometric topology matching and intelligent attribute binding. The transformation process is further refined into three sequentially executed sub-steps: rule base configuration, similarity comparison and candidate feature output, and batch attribute filling and style updating.

[0084] First, the component element classification mapping rule base is configured to include standard correspondences between various types of BIM components and various types of CIM elements. This rule base is not a static two-dimensional lookup table, but a dynamically expandable knowledge base that stores semantic mapping links between common component types and geographic element types in the engineering construction field. When constructing the rule base, based on national standards such as the Building Information Modeling (BIM) classification and coding standards and geographic information classification and coding rules, and combined with practical engineering experience, BIM components are classified according to functional attributes into building components (e.g., walls, columns, beams, slabs, doors and windows), structural components (e.g., foundations, supports, frames), mechanical and electrical components (e.g., air ducts, water pipes, cable trays, equipment), and categories such as decoration components, HVAC components, water supply and drainage components, fire protection components, and low-voltage electrical components. CIM elements are classified according to urban spatial composition into categories such as roads, plots, building ground projections, underground pipelines, green belts, site surfaces, and water bodies. The rule base establishes a standard correspondence between each pair of potentially mapping BIM component categories and CIM feature categories, recording the confidence level, applicable stage (e.g., valid only in the design phase or throughout the entire lifecycle), and attribute mapping templates for this correspondence. For example, the rule base defines that a BIM component of category "structural column" should be mapped to a CIM feature of category "building foundation," with a high confidence level; the mapping template aggregates the column outline into a building foundation polygon. Another example is that a BIM component of "water supply pipeline" is mapped to an "underground pipeline" feature, while retaining pipe diameter and material as extended attributes. This rule base is stored in JSON or XML format, allowing users to perform CRUD operations in a graphical interface and import / export between different projects, enabling knowledge reuse. When the conversion process starts, the rule base is first loaded into memory and compiled into an efficient hash mapping table for subsequent rapid retrieval of the corresponding CIM feature type and mapping rules based on the BIM component type.

[0085] Next, the spatial outline boundary, topological adjacency, and elevation range of the BIM components are extracted, and a similarity comparison is performed with the spatial outline, topological relationship, and elevation range of CIM elements. Candidate elements whose matching degree meets preset requirements are output. First, each BIM component to be converted is traversed, and its spatial features are extracted in multiple dimensions. The spatial outline boundary refers to the two-dimensional projection polygon of the component on the horizontal plane. For vertical components such as columns and walls, the bottom outline is taken; for horizontal components such as beams and slabs, the top or bottom outline is taken. During extraction, the actual position and rotation angle of the component need to be considered, converting the model's local coordinates into the true outline after geographic coordinates. Topological adjacency describes the spatial connection status of the component with its surrounding components or terrain. For example, whether both ends of a beam are connected to a column, whether a wall forms a closed room with adjacent walls, or whether a piece of equipment is attached to a wall. The elevation range is the vertical distance range between the lowest point of the component's bottom and the highest point of its top, with the unit consistent with the elevation datum.

[0086] After extracting the above features, candidate CIM features within the same geographic area are selected from the CIM dataset based on the CIM feature categories corresponding to the BIM component categories determined in the rule base. For each candidate CIM feature, its spatial outline boundary, topological relationships, and elevation range are also extracted. The spatial outline is usually a buffer zone of polygonal or linear features obtained from surveying; the topological relationships record the connection between the feature and adjacent plots and roads; and the elevation range comes from the digital elevation model or the elevation attributes of the feature itself.

[0087] Next, a similarity comparison is performed. The similarity comparison uses a weighted scoring mechanism, combining three dimensions: the ratio of the overlapping area of ​​the spatial outline to the outline area of ​​the BIM component (a higher ratio indicates a better spatial match); the consistency of topological relationships (e.g., if the BIM component indicates "two columns connected at both ends," while the candidate CIM element shows two columnar features at that location, the topological matching score is high); and the overlap ratio of elevation intervals (the intersection length of the elevation range of the BIM component and the elevation range of the CIM element divided by the union length). Each dimension is assigned a weight, which can be dynamically adjusted according to the project stage and data characteristics. For example, the elevation weight is lower in the planning stage and higher in the construction stage. The weighted sum is then used to obtain a comprehensive matching score between 0 and 100. For each BIM component, the matching score of all candidate CIM elements is calculated and sorted in descending order. Only candidates with a matching score exceeding a preset threshold, such as 70%, are retained, forming a candidate element list. If the candidate list is empty, the component is marked as a failed match, triggering a manual intervention process; if the list is not empty, the candidate with the highest matching degree is selected as the final binding target, while the second highest candidate is reserved for conflict resolution.

[0088] Then, based on the matching results, the professional type, unique identifier code, material grade, construction status, and design parameters of the BIM components are batch-populated into the corresponding CIM element attribute tables, and the layer styles and spatial codes are updated simultaneously. Once the binding relationship between BIM components and CIM elements is determined, the batch attribute population stage begins. The core of this stage is the attribute mapping executor. The attribute mapping executor reads the attribute mapping template predefined for the BIM component category from the rule base. The template lists the correspondence between source fields (BIM attribute names) and target fields (CIM attribute names), as well as the necessary conversion functions. For example, the mapping template specifies: mapping the BIM "structural material" field value to the CIM "material" field, while converting "C30" to the standardized description of "concrete grade C30"; mapping the BIM "globally unique ID" to the CIM "source component code" field for traceability; and mapping the BIM "construction stage identifier," such as "main construction," to the CIM "construction status" field. For attributes not mapped in the template, they are packaged into a single JSON extended field and stored in the attribute table of the CIM feature to ensure no loss of original information. The population operation uses a batch transaction approach: all successfully matched binding records within a batch are collected, and batch update SQL statements are constructed or the database's batch import interface is directly called to update a large number of CIM feature attributes at once.

[0089] Simultaneously, the layer styles and spatial codes of CIM elements are updated. Layer styles determine the rendered appearance of the element in 2D and 3D maps, such as color, transparency, and icons. The system matches corresponding style rules from the style library based on the professional type and material grade of the BIM component: for example, structural components use gray solid materials, MEP pipelines use lines of different colors, and fire protection equipment uses red warning icons.

[0090] After the style is updated, the map view automatically refreshes, ensuring that the visual style of the elements converted from BIM is consistent with the surrounding CIM background layer. Spatial codes are short strings used internally by the CIM platform for rapid retrieval and spatial indexing. During attribute population, the spatial codes of CIM elements are recalculated and updated based on binding relationships and coding generation rules in the rule base, ensuring they reflect information from the BIM source, such as the floor and system type of the BIM component, facilitating subsequent spatial queries and analysis. Through close collaboration, previously isolated BIM components and CIM elements are deeply integrated at both semantic and spatial levels, completing the automated conversion from raw data to standardized element data, providing an accurate, rich, and directly usable data foundation for the construction of a spatiotemporal digital base.

[0091] Furthermore, you can also view Figure 4 , Figure 4This is a detailed process diagram based on step S40 in the first embodiment. Figure 4 The steps of fully writing the standardized element data to establish a spatiotemporal digital baseboard, performing change capture and difference calculation on subsequently changed standardized element data to extract the changed portion, and incrementally writing the changed portion into the current spatiotemporal digital baseboard include S41~S44: Step S41: During the first full write, assign a globally unique identifier to each standardized feature data and record the initial version number and timestamp; Step S42: In the subsequent operation, by monitoring change events of the BIM collaboration platform or IoT sensing system, the standardized element data that has been modified, added or deleted is captured in real time. Step S43: Compare the captured change data with the corresponding historical data in the current base plate field by field, extract the attribute fields and geometric elements that cause differences, and form a change increment package containing only the difference information. Step S44: Submit the change increment package to the baseboard database in a transactional manner to cover the differences.

[0092] After generating standardized element data, the spatiotemporal digital baseboard is constructed and dynamically maintained. This operation is broken down into four sequential sub-steps: assigning identifiers and version records during the initial full write, capturing change events in real time, comparing fields one by one to form incremental packages, and committing differences in a transactional manner.

[0093] First, during the initial full write, a globally unique identifier is assigned to each standardized element data record, and an initial version number and timestamp are recorded. When all standardized element data for a project is received for the first time, the full import process is initiated. In this process, each standardized element data record is traversed, and a distributed unique identifier generator is invoked to assign a unique string identifier to the record that is never repeated within the project scope or across project platforms. The identifier generation rule can use the snowflake algorithm, combining the timestamp, machine node sequence number, and serial number into a 64-bit integer, then encoding it as a hexadecimal string; alternatively, a hierarchical segmentation method can be used, such as "project code-data type-serial number-version". After assigning the identifier, it is written to the primary key field of the data record. Simultaneously, an initial version number, typically starting from 1 and incrementing, and an initial timestamp, accurate to the millisecond level, are registered for the record. The version number and timestamp together mark the moment the data first enters the database. This metadata is stored in the same database row as the standardized element data, or in a separate metadata table, linked by the identifier. After the full write is completed, the spatiotemporal digital baseboard has a complete initial state, and all data can be accurately retrieved and referenced through a globally unique identifier.

[0094] Next, during subsequent operation, standardized element data that has been modified, added, or deleted is captured in real time by monitoring change events on the BIM collaboration platform or IoT sensing system. Throughout the entire construction cycle, data evolves dynamically. Designers adjusting component positions, modifying material properties, or adding equipment models in BIM software, the construction management system updating progress status, and IoT sensors reporting anomaly alarms all trigger changes to standardized element data. These changes are captured in real time through two parallel monitoring mechanisms. The first is proactive monitoring of the change event interface of the BIM collaboration platform. Modern BIM collaboration platforms, such as Autodesk BIM 360 or Glodon collaboration platform, typically provide Webhook or message queue interfaces. When a model is modified, added, or deleted, the platform pushes a notification message containing the changed component ID, change type, and operation timestamp.

[0095] Upon startup, monitoring endpoints are registered with these platforms. Upon receiving notifications, the system immediately retrieves the latest component data from the platform based on the component ID, converts it to a standardized element data format, and marks it as pending change data. The second monitoring mechanism targets IoT sensing systems. IoT platforms report sensor data in real-time via MQTT or Kafka message queues, such as pipeline pressure values ​​and structural displacement. Subscribing to these data topics, when received data exceeds a preset threshold or its status changes, the system determines that the corresponding standardized element data needs updating; for example, changing the health status of a pipeline segment from "normal" to "alarm." Furthermore, it supports change data capture technology for business databases. By parsing the database's transaction logs, data changes can be captured without modifying the business system code. Through the combination of these multiple monitoring methods, real-time and comprehensive capture of standardized element data changes is achieved, with latency controlled to the second or even millisecond level.

[0096] Then, the captured change data is compared field by field with the corresponding historical data in the current base plate, extracting the attribute fields and geometric elements that cause differences, forming a change increment package containing only the difference information. When a change data is captured, it is not directly written to the base plate, but the difference calculation is performed first. First, based on the globally unique identifier carried by the change data, the latest version record corresponding to that identifier is queried in the historical database of the current base plate.

[0097] Then, the changed data is compared field by field with the retrieved historical records. For attribute fields, the name and value of each field are compared one by one. For example, the old value "C30" and the new value "C35" of the "Material Grade" field are compared, and "Not Started" and "In Progress" of the "Construction Status" field are compared. For geometric fields, a spatial geometric comparison algorithm is used to calculate the differences between the geometric objects before and after the change. Specifically, if the geometric object is a polygon, the symmetric difference between the two polygons is calculated to obtain the newly added and deleted areas; if the geometric object is a line, the node sequence of the line is compared to find the newly added, deleted, or moved nodes. After the comparison is completed, all the changed fields and geometric parts are extracted and packaged into a change increment package. This increment package does not contain any information that has not changed, so the data volume is much smaller than the complete standardized feature data. For example, a BIM component contains hundreds of attribute fields. If only the material grade is modified, the increment package only records the component's identifier, the field name "Material Grade", the old value "C30", and the new value "C35". If the geometry has not changed, the geometric part is empty. This sophisticated difference extraction mechanism reduces the amount of data transferred and the database load in subsequent write operations, making high-frequency incremental updates possible.

[0098] Finally, the incremental change package is committed to the base database in a transactional manner to overwrite the differences. The generated incremental change package is encapsulated as a database transaction. This transaction includes the following operations: locating the target data record, and updating only the changed fields and geometric parts based on the difference information in the incremental package, without affecting other fields. For modifications to attribute fields, the SQL UPDATE statement is used to specify the field assignment; for modifications to geometric fields, the database's spatial update function is called to replace a portion of the geometric object; for newly added records, an INSERT operation is performed to fill in the complete data; for deleted records, a DELETE operation is performed or a logical deletion flag is set. Before the transaction is committed, an integrity check is performed, such as checking whether the updated data satisfies foreign key constraints and whether spatial topology rules have been violated. If the check passes, the transaction is committed, and the changes are persisted to disk; if the check fails, the transaction is rolled back, an error log is recorded, and the system from which the change originated is notified to revert the change or resend the corrected data. It is worth noting that the "overwrite the differences" approach is used here instead of a full replacement, i.e., only the changed data blocks are modified, which relies on the database's row-level locking and partial update capabilities. For example, in PostgreSQL, for JSONB type fields, the `jsonb_set` function can be used to update only the value of a nested key; for spatial geometry fields, functions such as `ST_SetPoint` can be used to modify only a node in the geometric object. In this way, the write operation overhead of the base plate database is minimized while ensuring data atomicity and consistency. Through the close coordination of the above processes, a complete closed loop is achieved from the initial full database creation to continuous incremental updates, enabling the spatiotemporal digital base plate to dynamically evolve along with changes in the engineering entity with extremely low resource consumption.

[0099] Furthermore, you can also view Figure 5 , Figure 5 This is a schematic diagram illustrating the detailed process of step S60 in the first embodiment. Figure 5 The step of establishing a bidirectional data transmission mapping between different stages of the entire lifecycle of the project construction through the dynamic binding relationship includes S61~S62: Step S61: Based on the unified coding inheritance relationship between each stage of the entire life cycle of the project construction, establish a hierarchical mapping between output data and input data between adjacent stages; Step S62: Through the step-by-step mapping, the output data of the upstream stage is transmitted sequentially along the life cycle direction as the input data of the downstream stage, and the result data of the downstream stage is fed back to the upstream stage, forming a bidirectional mapping link that transmits data step-by-step from top to bottom and implements data step-by-step from bottom to top.

[0100] After establishing a dynamic binding relationship between spatially unique codes and business association keys, the above binding relationship and a unified coding inheritance system are further utilized to construct a bidirectional data transmission mapping between each stage of the entire project lifecycle. The establishment process of this mapping is broken down into two sub-steps: establishing a hierarchical mapping between adjacent stages based on the unified coding inheritance relationship; and realizing a bidirectional link of top-down transmission and bottom-up implementation through this hierarchical mapping.

[0101] First, based on the unified coding inheritance relationship between each stage of the entire engineering construction lifecycle, a hierarchical mapping between output and input data between adjacent stages is established. The coding inheritance relationship serves as the link throughout the planning, design, construction, delivery, and operation and maintenance stages. A set of coding generation rules is defined for each engineering entity at project initiation. Taking a bridge as an example, the project code generated during the planning stage is "BRIDGE-2025-001". When entering the design stage, when designers create the BIM model, they automatically set the prefix of all bridge component codes to the aforementioned planning code, and append the component type and serial number; for example, "BRIDGE-2025-001-PIER-01" represents pier number 01.

[0102] When the construction phase begins, the construction management system requires that the task order numbering rules reference the corresponding component code or its derived code when creating the construction task order for the bridge pier. The same applies to the operation and maintenance phase; the equipment codes in the equipment ledger must inherit the aforementioned coding path. This inheritance logic is enforced by setting a coding rule engine at the data entry point of each phase. Based on this, a hierarchical mapping between adjacent phases is established. Specifically, the mapping engine scans the spatial control code of each record in the output data table of the planning phase and the design code of each record in the input data table of the design phase, finding the corresponding relationship through string prefix matching, and then establishing mapping rules: the red line boundary field of the planning phase maps to the site boundary field of the design phase, and the plot ratio index of the planning phase maps to the total area verification rule of the design phase. Similarly, the component geometry information of the design phase maps to the bill of quantities field of the construction phase, the acceptance conclusion of the construction phase maps to the as-built model attribute field of the delivery phase, and the equipment parameters of the delivery phase maps to the inspection plan field of the operation and maintenance phase. These mapping rules are stored in the mapping rule base in the form of key-value pairs. Each rule contains the source phase table name, source field name, target phase table name, target field name, and transformation function. Conversion functions handle differences in data formats and units, such as converting meters in the design phase to millimeters in the construction phase, or converting concrete grades in the design phase to mix proportions in the construction phase.

[0103] Then, through the aforementioned hierarchical mapping, the output data of the upstream stage is passed sequentially along the lifecycle direction as the input data of the downstream stage, and the result data of the downstream stage is fed back to the upstream stage, forming a two-way mapping link of top-down hierarchical transmission and bottom-up hierarchical implementation. Once the mapping rules are established, the data transmission engine begins to actively execute data push and pull operations. In the top-down transmission direction, the engine periodically scans the data tables of the upstream stage. Once a new or modified record is found, it immediately generates the input data required by the downstream stage according to the mapping rules. For example, when the planning department adjusts the land use boundary of a plot in the land planning system, the transmission engine captures this change and automatically converts the coordinate string of the boundary line into a site boundary constraint that the BIM software can recognize in the design stage, writing it into the site configuration file of the design project. When the designer opens the BIM model, this boundary will be displayed as a red warning line, and any component placement operation exceeding the boundary will be prevented. As another example, when the entire structural model of a bridge is completed in the design stage, the transmission engine automatically extracts the geometric dimensions and material information of each component and directly writes it into the material requirements plan table of the construction management system through the API interface, eliminating the need for manual data entry. In the bottom-up implementation direction, the transmission engine also monitors data changes in the downstream stage and feeds them back to the upstream stage. For example, during the construction stage, if the actual strength value entered by the quality inspector via a mobile terminal after pouring the bridge pier concrete is lower than the design requirement of C35, the transmission engine automatically maps this non-compliance information back to the BIM model in the design stage, adds a "insufficient strength" warning label to the bridge pier component, and notifies the designers for review. Simultaneously, this information is also transmitted back to the investment estimation system in the planning stage, triggering an additional reinforcement cost budget. Analysis of bridge vibration data collected during the operation and maintenance stage reveals an abnormal natural frequency in a certain bridge pier. The transmission engine feeds this anomaly back to the as-built archives in the construction stage, locating the corresponding construction logs and material batches to help analyze the root cause of the problem. This bidirectional transmission is not a simple data copy, but a complex process involving value transformation, constraint verification, and triggering actions. A rule executor is integrated into the transmission engine, supporting user-defined script extensions. All transmission operations are recorded in the transmission log, including source data identifier, target data identifier, transmission time, values ​​before and after transformation, and execution results, facilitating full-process traceability. Through the above collaborative work, data silos at each stage of the entire life cycle of the project construction were successfully connected into an organic whole. Data can flow forward along the coding inheritance chain to provide accurate input to the downstream, and can also be aggregated in reverse to provide real-time feedback to the upstream, forming a truly two-way closed-loop data governance system.

[0104] Furthermore, you can also view Figure 6 , Figure 6 This is a detailed schematic diagram of step S70 based on the first embodiment. Figure 6The step of automatically triggering the other party to synchronize and update and verify consistency based on the dynamic binding relationship when spatial data or business data changes, and persisting the changes through an integrated storage and change message push mechanism, includes S71~S73: Step S71: When it is determined that the position, geometry or spatial range of the component in the spatial data has changed, the corresponding business data record is located by the unique spatial code, the associated spatial coordinate field, the region identifier and the spatial constraint status in the business data record are automatically updated, and the data consistency verification of the business system is triggered. Step S72: When it is determined that there is a delay in progress, quality abnormality, investment overrun, or change in the operation and maintenance alarm status in the business data, the corresponding spatial component is located through the business association key, the spatial component is automatically highlighted and a warning is pushed in the spatiotemporal digital baseboard, and the spatial component is focused and located in the three-dimensional view. Step S73: During the bidirectional synchronization process, a distributed transaction protocol is used to ensure atomic operations between the spatial database and the business database, and all upper-layer applications that have subscribed to the changes are asynchronously notified to refresh the display through a message queue.

[0105] After establishing the bidirectional data transmission mapping, a real-time linkage and update mechanism between spatial data and business data was implemented. This mechanism ensures that changes on either side automatically trigger synchronous updates, consistency checks, and real-time responses from upper-layer applications. The aforementioned linkage and update process is broken down into three sub-steps: spatial data changes triggering business data updates and checks, business data changes triggering visual linkage of spatial data, and atomicity guarantees and message notifications during the bidirectional synchronization process.

[0106] First, when changes occur in the location, geometry, or spatial extent of components in the spatial data, the system locates the corresponding business data record using a unique spatial code. This automatically updates the associated spatial coordinate fields, region identifier, and spatial constraint status in the business data record, triggering a data consistency check in the business system. A unified change monitor is set up in the access layer of the spatiotemporal digital baseboard. This monitor tracks all write operations in the spatial database in real time. When it detects a shift in the location of a spatial component (e.g., the coordinates of a pipeline centerline), a modification of the geometry (e.g., the outline boundary of a building), or a change in the spatial extent (e.g., the area of ​​a plot of land), the monitor immediately extracts the unique spatial code involved in the change, along with the specific values ​​before and after the change. Then, based on this unique spatial code, a rapid search is performed in the dynamic binding relationship table to find all business association keys associated with the spatial data. If one or more business association keys are found, the system locates the corresponding business data record for each key, such as a construction schedule item, quality acceptance record, maintenance work order, or asset ledger.

[0107] Then, based on the pre-configured update rules in the binding strategy parameters, the relevant fields in these business data records are automatically updated. Updating the associated spatial coordinate field means synchronizing the spatial location information stored in the business data with the changed component coordinates; for example, updating the latitude and longitude fields in the drainage well's business record to the new coordinates. Updating the regional identifier means that if a change in the spatial extent of a component leads to a change in its administrative region or management grid, the regional code in the business data is automatically corrected to ensure the accuracy of statistics and permission allocation. Updating the spatial constraint status means that when a component's location changes, the system recalculates the spatial relationship between that component and other components, such as whether it intrudes into a restricted area or conflicts with adjacent pipelines, and writes the constraint satisfaction or violation status into the business data. After completing the above updates, the data consistency verification of the business system is immediately triggered. The verification rules are pre-defined by the business system, such as checking whether the updated drainage well coordinates are still within the road red line, whether the pipeline slope meets design specifications, and whether the equipment installation height meets safety clearance requirements. The verification interface provided by the business system is called, using the updated business data records as input, to obtain the verification results. If the verification passes, the entire update process continues; if the verification fails, the spatial data change is rolled back, and a detailed conflict report is generated and sent back to the user. This proactive, linked update and verification mechanism ensures the accuracy of spatial data and prevents logical errors in business data.

[0108] When it is determined that there are delays in progress, quality anomalies, investment overruns, or changes in the status of operation and maintenance alarms in the business data, the corresponding spatial components are located through the business association key. The spatial components are automatically highlighted in the spatiotemporal digital baseboard, and early warning prompts are pushed. The components are also focused and located in the 3D view.

[0109] Additionally, when the construction management system changes the progress status of a process from "normal" to "delayed," or the quality management system enters a non-compliant acceptance record, or the investment control system detects that the actual cost of a sub-project exceeds the budget, or the IoT platform reports an equipment failure alarm, the change interceptor captures these business data changes. It extracts the business association key from the change record; this key can be a process number, acceptance point code, cost item code, or equipment ID. Then, it searches the dynamic binding relationship table for the spatial unique code associated with that business association key. After finding the corresponding spatial component, it executes a series of visual linkage operations in the spatiotemporal digital baseboard. Highlighting color refers to assigning different rendering colors to spatial components based on the type and severity of the business change: delayed progress uses a yellow flashing border, quality anomalies use orange semi-transparent fill, investment overruns use a purple diagonal texture, and maintenance alarms use red pulsating highlighting. Push notification alerts refer to the system generating a structured message in the interface's notification panel. This message includes the business type of the change, the name of the affected spatial component, a detailed description of the change, and suggested handling measures. For example, when the maintenance system records a pipeline leak alarm, the warning message is: "Pipeline PIPE-089 experienced a sudden pressure drop at 14:23:25, suspected leak. Please proceed to the site immediately." In the 3D view, focused positioning refers to the linkage engine automatically adjusting the 3D camera's perspective, aligning the view center with the spatial component, and setting appropriate viewing distance and tilt angles. This allows operators to see the specific location of the problem in the 3D scene immediately, without manual searching. This visualized linkage operation is simultaneously pushed to multiple terminals, including large-screen monitoring systems on PCs, mobile inspection applications on tablets, and augmented reality headsets, ensuring that personnel in different roles can obtain intuitive spatial location information in a timely manner. Through this step, previously abstract business data changes are transformed into intuitive, locatable, and operable spatial visualization events, improving anomaly response efficiency.

[0110] During bidirectional synchronization, a distributed transaction protocol is used to ensure atomic operations between the spatial database and the business database. A message queue asynchronously notifies all upper-layer applications subscribing to the changes to refresh the display. Linked updates involve write operations across multiple database systems. For example, when spatial data changes, multiple tables in the business database need to be updated synchronously, and vice versa, the rendering attributes of the spatial database need to be updated. Distributed transaction protocols, such as two-phase commit or a eventually consistent scheme based on reliable messaging, are used to ensure data consistency across database operations. In the two-phase commit mode, a "ready" request is first sent to all databases involved in the change, requiring each database to reserve resources and perform pre-operations without committing. Once all databases return a "ready" state, a "commit" instruction is sent, and all databases simultaneously commit the transaction. If any database fails to prepare, a rollback instruction is sent, and all databases undo their pre-operations. While this protocol incurs a slight performance penalty, it guarantees a high degree of data consistency in critical business scenarios. For scenarios with relatively low real-time requirements, an eventual consistency scheme based on message queues is adopted: the change operation is encapsulated as a message and sent to a reliable message queue. Each database consumes the message and executes a local transaction. The message retry and dead-letter queue mechanism ensure that the state of all databases is eventually consistent.

[0111] After each successful linked update transaction is completed, a change message generator constructs a standardized change event based on the submitted content. This event is a structured data object that includes the following fields: change type, such as addition, modification or deletion; unique identifier of the changed object, such as a unique space code or service association key; change timestamp accurate to milliseconds; summary or complete old value before the change, and complete data snapshot after the change. The standardized event is serialized into JSON or Protobuf format, and then pushed to a preset message topic. Message topics can be divided according to service types, such as the "space-geometry change" topic, "service-progress change" topic, and "early warning-alarm event" topic. Upper-layer applications, such as digital twin visualization platforms, collaborative management and control systems, construction progress systems, and operation and maintenance management systems, subscribe to their respective interested topics through message queue clients when starting. When a new change event reaches the broker node of the message queue, the broker pushes the event to all online subscribers using the publish-subscribe pattern. After receiving the event, each upper-layer application consumes it according to its own service logic: the digital twin platform refreshes the color and status of components in the 3D scene, the construction progress system redraws the critical path of the Gantt chart, and the operation and maintenance management system adds an alarm record to the dashboard. The asynchronous feature of the message queue decouples change notification from database submission, which will not block the persistence operation of the base board due to slow processing of a certain application. Meanwhile, the reliable delivery of notifications is guaranteed through message acknowledgement and persistent storage mechanisms. Through the above close connection, real-time two-way linkage between spatial data and service data is realized, distributed transactions ensure data consistency, and message queues ensure real-time and reliable event notification, ultimately completing the full-link closed-loop dynamic maintenance and integration of the spatiotemporal digital base board.

[0112] Further, it is also possible to view Figure 7 , Figure 7 which is another schematic diagram of the refinement process based on step S70 in the first embodiment. Based on Figure 7 , when spatial data or service data changes, automatically triggering synchronous update and consistency check of the other party according to the dynamic binding relationship, and the step of performing persistence through integrated storage and change message push mechanism includes S74 to S76: Step S74: uniformly writing the spatial data, service data and Internet of Things perception data in the spatiotemporal digital base board into the same set of spatial database or graph database, and sharing the same access interface and transaction management unit; Step S75: after each change submission succeeds, generating a standardized change event including the change type, the unique identifier of the changed object, the change timestamp, and the values before and after the change; Step S76: Push the standardized change event to a preset message topic, so that the digital twin application, collaborative management and control system, construction supervision platform and operation and maintenance management system can subscribe and consume it as needed, so that each upper-layer application can maintain real-time consistency with the spatiotemporal digital base.

[0113] Building upon the bidirectional linkage and updating of spatial and business data, a further integrated storage and change message push mechanism ensures real-time consistency between the spatiotemporal digital baseboard and various upper-layer applications. This mechanism is broken down into three sub-steps: unified writing to the same spatial or graph database, generating standardized change events, and pushing messages for multiple systems to subscribe to and consume.

[0114] Spatial data, business data, and IoT sensing data from a spatiotemporal digital baseboard are uniformly written into a single spatial database or graph database, sharing the same access interface and transaction management unit. Traditional solutions typically store spatial data in a spatial database, business data in a relational database, and IoT data in a time-series database, resulting in complex and inefficient cross-database queries and transactions.

[0115] In addition, a transactional database that supports spatial data types is selected as the unified storage engine. This database can be PostgreSQL with PostGIS spatial extensions, a relational database with native spatial support, or a graph database such as Neo4j. In the unified storage model, spatial data is no longer stored in a separate spatial field, but as a regular column in the table, stored alongside other business fields. For example, in the "Pipeline" table, there are business attribute fields such as pipe diameter, material, and pressure rating, as well as a spatial field of type geometry to store the three-dimensional line geometry of the pipeline. Business data and IoT sensing data are also stored as fields in the same table or related tables. Pressure and temperature values ​​collected by IoT sensors can be directly appended to the corresponding device records as time-series fields, or they can be stored as a separate time-series table but still linked to the device table via a foreign key, and reside in the same database instance.

[0116] Through the above methods, all data access can be completed using the same database connection and query language, eliminating the need for cross-database data aggregation. The transaction management unit is also simplified: when spatial and business data need to be updated simultaneously, only a single local database transaction needs to be started, update statements executed sequentially, and finally committed or rolled back; the entire process does not require a complex distributed transaction coordinator. Unified storage also brings management convenience; backup, recovery, access control, and security auditing can all be configured and executed uniformly on the same database platform, reducing operational costs. Furthermore, a combined optimization strategy of spatial and temporal indexes is enabled on this database, ensuring efficient execution plans for both spatially and temporally range-based queries. Through this integrated storage, spatial data, business data, and IoT sensing data achieve true physical fusion, laying a solid foundation for subsequent change event generation and message push.

[0117] After each successful change commit, a standardized change event is generated, containing the change type, a unique identifier for the changed object, a change timestamp, and the values ​​before and after the change. The change event generator is triggered immediately after a unified database transaction is successfully committed. This generator captures the newly committed changes through the database's trigger mechanism or transaction log monitor. There are two specific implementation methods: one is to create AFTER INSERT, AFTER UPDATE, and AFTER DELETE triggers on each table in the database, with the triggers internally writing the change information to a dedicated event log table; the other is to deploy a change data capture process that parses the database's transaction log file in real time and extracts the change records. Regardless of the method used, the generator extracts four core elements from the change records. The first element is the change type, categorized as insert, update, and delete. For update operations, the generator further refines them into attribute modifications and geometric modifications. The second element is the unique identifier for the changed object. For spatial data, this identifier is the assigned spatial unique code; for business data, this identifier is the business association key. The generator extracts this identifier from the field values ​​of the change record. The third element is the change timestamp, accurate to milliseconds, typically taken from the database transaction commit time or the system clock. The fourth element is the values ​​before and after the change. For modification operations, the generator saves both the old value before the modification and the new value after the modification; for addition operations, the old value is empty, and the new value is a complete data snapshot; for deletion operations, the old value is a snapshot of the deleted data, and the new value is empty. To control event size, hash digest processing is supported for large fields such as long text or large geometric objects, storing only the hash value rather than the complete content. Detailed data is then retrieved from the database again using the identifier. These four elements are encapsulated into a standardized data structure in JSON or Avro format, ensuring easy parsing for upper-level applications using different programming languages. The event also includes an auto-incrementing event sequence number to ensure message order and deduplication. Through this step, every minor data change is transformed into a structured, transitive, and auditable event object.

[0118] Standardized change events are pushed to preset message topics, allowing digital twin applications, collaborative management systems, construction supervision platforms, and operation and maintenance management systems to subscribe to and consume them on demand, ensuring real-time consistency between these upper-layer applications and the spatiotemporal digital base. Generated events do not remain internally in the database but are broadcast to all upper-layer applications interested in the change. A message queue middleware is used as the event transmission hub; commonly used message queues include Kafka, RabbitMQ, or message services provided by cloud vendors. Upon system startup, several message topics are created based on the configuration file, such as "Baseboard - Spatial Change," "Baseboard - Business Change," and "Baseboard - IoT Alarm." After generating events, the change event generator selects one or more topics for publication based on the change type and the attributes of the target object.

[0119] Additionally, the publish operation invokes the message queue client SDK to send the serialized event object to the corresponding topic. After receiving the event, the message queue's broker node persists it to disk to ensure reliability and returns an acknowledgment to the publisher. Simultaneously, each upper-layer application, such as the digital twin visualization platform, collaborative management system, construction supervision platform, and operation and maintenance management system, creates its own consumer client upon startup and subscribes to topics of interest from the message queue. Subscription can employ several modes: in exclusive consumption mode, each message is received by only one consumer instance, suitable for load-balanced task distribution scenarios; in broadcast mode, each consumer subscribing to the topic receives a copy of the message, suitable for scenarios requiring synchronized updates from all applications. Broadcast mode is typically used because each upper-layer application operates independently and needs to be aware of the latest status of the underlying infrastructure. When the message queue broker node receives a new event, it immediately pushes it to all online subscribers in parallel. Upon receiving an event, the consumer executes corresponding refresh logic based on the change type and identifier in the event: the digital twin platform reloads the latest geometry and attributes of the component according to the spatial code, updating the display of the 3D scene; the collaborative management system refreshes the progress bar and color status on the task dashboard according to the business association key; the construction supervision platform converts alarm events into pop-up prompts and records them in the log; the operation and maintenance management system retrieves the latest maintenance plan according to the equipment code and reschedules. The message queue also supports message retry and dead-letter queue mechanisms: if a consumer fails to process the message, the message queue will re-push the message after a delay until success or the maximum number of retries is reached. The final failed message will be moved to the dead-letter queue for manual analysis.

[0120] Through the aforementioned message push and subscription mechanism, all upper-layer applications can obtain every change to the baseboard in real time without frequently polling the database, significantly reducing the database query load. Simultaneously, the data displayed by each application remains consistent with the latest state of the baseboard. Combined with integrated storage and standardized event generation, a complete high-performance, highly reliable, and real-time change distribution system has been constructed, thoroughly solving the problems of difficult data synchronization and poor consistency among multiple systems throughout the entire engineering construction cycle.

[0121] Furthermore, you can also view Figure 8 , Figure 8 This is a schematic diagram of the overall architecture, based on Figure 8 The system architecture shown in this embodiment constructs a five-layer data processing system. Each layer is sequentially connected according to the data flow, jointly completing the entire process from raw data access to underlying application support. The first layer is the sensing access layer, which is responsible for connecting to various data sources throughout the entire engineering construction cycle. This includes BIM model data accessed via IFC or Revit interfaces, CIM element data obtained via standard geographic information service interfaces, business management data synchronized from enterprise resource planning systems or project management systems, and IoT sensing data received in real time via message queue telemetry transmission protocols or narrowband IoT gateways. All of the above data retains its original format and coordinate system during access, without any conversion, to maintain the original traceability of the data.

[0122] The second layer is the preprocessing pipeline layer. This layer receives the raw data from the sensing access layer and processes it sequentially according to the following steps: adaptive coordinate system transformation, data quality check, automatic topology consistency repair, and hierarchical lightweighting. Coordinate system transformation unifies data from different sources to the National Geodetic Coordinate System and the National Elevation Datum; quality check uses a collaborative approach of machine and human inspection to automatically detect and mark integrity and consistency defects in the data; topology repair automatically eliminates spatial errors such as overlaps, breakpoints, and hanging based on graph theory algorithms; hierarchical lightweighting dynamically adjusts the model's detail level according to the visibility distance, preserving high-precision geometric textures in the foreground and significantly compressing the polygon count in the background. After the above pipeline processing, all data reaches a standard state of unified spatiotemporal reference, correct topology, and lightweighting.

[0123] The third layer is the data fusion layer. This layer receives preprocessed data and performs three fusion operations: model fusion aligns BIM components and CIM elements semantically and spatially using a component-element classification mapping rule base and a dual-drive conversion algorithm to generate standardized element data; business fusion encodes and associates business management data from each stage of engineering construction with spatial data; and IoT fusion binds the temporal characteristics of IoT sensing data to corresponding spatial components. The fourth layer is the spatiotemporal base layer. This layer uses a unified spatial database or graph database as a carrier to store the standardized data output by the data fusion layer, while also implementing incremental update, version chain management, and traceability services. Incremental updates only capture and write the changed parts, and the version chain records each change in a unidirectional linked list, supporting backtracking, comparison, and rollback operations. The fifth layer is the application support layer. This layer encapsulates the data services, version services, and linkage services in the base layer into callable modules through standardized application programming interfaces. The digital twin platform, collaborative management and control system, construction supervision system, and operation and maintenance management system build their respective business functions based on these interfaces. The five-layer architecture described above forms a complete closed loop from data acquisition to application services. Data flows unidirectionally between layers, and each layer has clear input and output specifications, ensuring the scalability and maintainability of the system.

[0124] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dynamic maintenance and data fusion method of the full-cycle spatiotemporal digital base plate of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0125] This application provides a full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method in the above embodiment 1.

[0126] The following is for reference. Figure 14 The diagram illustrates a structural schematic of a dynamic maintenance and data fusion device for a full-cycle spatiotemporal digital backplane suitable for implementing embodiments of this application. The dynamic maintenance and data fusion device for a full-cycle spatiotemporal digital backplane in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 14The illustrated full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0127] like Figure 14 As shown, the full-cycle spatiotemporal digital backplane dynamic maintenance and data fusion device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the full-cycle spatiotemporal digital backplane dynamic maintenance and data fusion device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the full-cycle spatiotemporal digital backplane dynamic maintenance and data fusion equipment to exchange data wirelessly or via wired communication with other devices. Although various full-cycle spatiotemporal digital backplane dynamic maintenance and data fusion devices are shown in the figures, it should be understood that implementation or possession of all of them is not required. More or fewer may be implemented alternatively.

[0128] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0129] The full-cycle spatiotemporal digital base plate dynamic maintenance and data fusion device provided in this application, employing the full-cycle spatiotemporal digital base plate dynamic maintenance and data fusion method described in the above embodiments, can solve the technical problem that existing engineering construction processes cannot achieve automation, integration, and traceability collaboration in the governance of multi-source heterogeneous data throughout the entire lifecycle. Compared with the prior art, the beneficial effects of the full-cycle spatiotemporal digital base plate dynamic maintenance and data fusion device provided in this application are the same as those of the full-cycle spatiotemporal digital base plate dynamic maintenance and data fusion method provided in the above embodiments, and other technical features in this full-cycle spatiotemporal digital base plate dynamic maintenance and data fusion device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0130] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0131] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0132] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon. The computer-readable program instructions are used to execute the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method in the above embodiments.

[0133] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be executed by instructions, used by devices, or used in conjunction with them. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0134] The aforementioned computer-readable storage medium may be included in the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion equipment; or it may exist independently and not be assembled into the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion equipment.

[0135] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion device, the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion device realizes the technical content of the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method embodiment shown above.

[0136] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using dedicated hardware-based implementations that perform the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0138] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0139] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method. This solves the technical problem that existing engineering construction processes cannot achieve automation, integration, and traceability / collaboration in the governance of multi-source heterogeneous data throughout the entire lifecycle. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the full-cycle spatiotemporal digital baseboard dynamic maintenance and data fusion method provided in the above embodiments, and will not be elaborated upon here.

Claims

1. A method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard, characterized in that, The method includes the following steps: Acquire full-cycle data for the project construction and preprocess the full-cycle data; In the preset component element classification mapping rule base, a dual-drive conversion algorithm combining geometric topology matching and attribute intelligent binding is adopted to automatically match the spatial contour, topological relationship and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data. Batch bind the successfully matched BIM component attributes to CIM feature attribute fields to generate standardized feature data; The standardized element data is fully written to establish a spatiotemporal digital baseboard. Change capture and difference calculation are performed on the subsequently changed standardized element data to separate the changed parts. The changed parts are incrementally written to the current spatiotemporal digital baseboard, and version nodes are generated and persistently stored in a unidirectional version chain. Based on the standardized element data in the spatiotemporal digital base, a spatial unique code is configured for the spatial data in the standardized element data, a business association key is configured for the associated business data, and a dynamic binding relationship is established between the spatial unique code and the business association key. Through the dynamic binding relationship, a bidirectional data transmission mapping is established between each stage of the entire life cycle of the project construction. The bidirectional transmission mapping includes a top-down hierarchical mapping and a bottom-up hierarchical implementation. Based on the bidirectional data transmission mapping, when spatial data or business data changes, the other party is automatically triggered to synchronize and verify consistency according to the dynamic binding relationship, and the changes are persisted through an integrated storage and change message push mechanism to complete the dynamic maintenance and data fusion of the spatiotemporal digital baseboard. The step of establishing a bidirectional data transmission mapping between different stages of the entire lifecycle of the project construction through the dynamic binding relationship includes: Based on the unified coding inheritance relationship between each stage of the entire life cycle of engineering construction, a hierarchical mapping between output data and input data between adjacent stages is established. Through this step-by-step mapping, the output data of the upstream stage is transmitted sequentially along the life cycle direction as the input data of the downstream stage, and the result data of the downstream stage is fed back to the upstream stage, forming a two-way mapping link that transmits data step-by-step from top to bottom and implements data step-by-step from bottom to top.

2. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, The steps of acquiring full-cycle data for project construction and preprocessing the full-cycle data include: Coordinate system identification is performed on the BIM component data and CIM element data in the full-cycle data respectively, and the corresponding seven-parameter transformation algorithm is matched from the pre-configured coordinate system transformation rule library to convert the local coordinate system into the national geodetic coordinate system and the national elevation datum. A filtering algorithm is used to remove noise from the data after coordinate system transformation, and then an interpolation algorithm is used to fill in the missing data values. The graph theory-based topology reconstruction algorithm automatically identifies and repairs errors in the data such as overlaps, breakpoints, dangling points, unclosed surfaces, and topological conflicts. Based on the preset viewing distance threshold and model detail level, dynamic precision adjustment is performed on the repaired data, preserving high-precision geometry and texture in close-up shots and compressing the number of model faces in distant shots.

3. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, The step of automatically matching the spatial contour, topological relationship, and elevation range of BIM component data and CIM element data in the preprocessed full-cycle data using a dual-drive conversion algorithm combining geometric topology matching and intelligent attribute binding in the preset component element classification mapping rule base includes: Configure the component element classification mapping rule base to include standard correspondences between multiple types of BIM components and multiple types of CIM elements; Extract the spatial outline boundary, topological adjacency relationship and elevation range of BIM components, and compare the similarity with the spatial outline, topological relationship and elevation range of CIM elements, and output candidate elements that meet the preset matching requirements. Based on the matching results, the professional type, unique identifier code, material grade, construction status and design parameters of BIM components are batch filled into the corresponding CIM element attribute table, and the layer style and spatial code are updated simultaneously.

4. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, The steps of fully writing the standardized element data to establish a spatiotemporal digital baseboard, performing change capture and difference calculation on subsequently changed standardized element data to extract the changed portion, and incrementally writing the changed portion into the current spatiotemporal digital baseboard include: During the first full write, a globally unique identifier is assigned to each standardized feature data and the initial version number and timestamp are recorded. During subsequent operation, by monitoring change events of the BIM collaboration platform or IoT sensing system, standardized element data that has been modified, added or deleted can be captured in real time. The captured change data is compared field by field with the corresponding historical data in the current base plate to extract the attribute fields and geometric elements that cause the difference, forming a change increment package containing only the difference information. The change increment package is committed to the baseboard database in a transactional manner to cover the differences.

5. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, After the step of generating version nodes and persistently storing them in a unidirectional version chain, the method further includes: In response to a version rollback request sent by a user or an upper-layer application, the target version identifier carried in the version rollback request is parsed, the corresponding version node is found by traversing the unidirectional version chain, and the full data snapshot or incremental change sequence associated with the version node is retrieved from the archive area of ​​the spatiotemporal digital base corresponding to the version node, and the complete spatiotemporal digital base state of the version corresponding to the target version identifier is reconstructed. In response to the version comparison request, extract the spatiotemporal digital base status corresponding to the two different version nodes, perform item-by-item difference analysis on the spatial data geometric elements and business data attribute fields in the two statuses, and output a difference comparison report; In response to a rollback request, the current baseboard state is completely replaced with the baseboard state associated with the specified historical version node, and a new version node is generated to record this rollback operation.

6. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, The step of automatically triggering the other party to synchronize and update and verify consistency based on the dynamic binding relationship when spatial data or business data changes, and persisting the changes through an integrated storage and change message push mechanism, includes: When it is determined that the location, geometry, or spatial range of a component in the spatial data has changed, the corresponding business data record is located through the unique spatial code, the associated spatial coordinate field, the region identifier, and the spatial constraint status in the business data record are automatically updated, and the data consistency check of the business system is triggered. When it is determined that there is a delay in progress, an abnormality in quality, an overspending of investment, or a change in the status of operation and maintenance alarms in the business data, the corresponding spatial component is located through the business association key, the spatial component is automatically highlighted in the spatiotemporal digital baseboard, an early warning prompt is pushed, and the spatial component is focused and located in the three-dimensional view. During bidirectional synchronization, a distributed transaction protocol is used to ensure atomic operations between the spatial database and the business database, and a message queue is used to asynchronously notify all upper-layer applications that have subscribed to the changes to refresh the display.

7. The method for dynamic maintenance and data fusion of a full-cycle spatiotemporal digital baseboard as described in claim 1, characterized in that, The step of automatically triggering the other party to synchronize and update and verify consistency based on the dynamic binding relationship when spatial data or business data changes, and persisting the changes through an integrated storage and change message push mechanism, includes: The spatial data, business data and IoT sensing data in the spatiotemporal digital base plate are uniformly written into the same spatial database or graph database, sharing the same access interface and transaction management unit. After each change is successfully submitted, a standardized change event is generated, which includes the change type, the unique identifier of the changed object, the change timestamp, and the values ​​before and after the change. The standardized change events are pushed to preset message topics, which can be subscribed to and consumed on demand by digital twin applications, collaborative management and control systems, construction supervision platforms and operation and maintenance management systems, so that each upper-layer application maintains real-time consistency with the spatiotemporal digital base.

Images