ODF-based bim file incremental asynchronous saving method and related device

Abstract

The application discloses an ODF-based BIM file incremental asynchronous saving method and a related device, relates to the technical field of data storage, and comprises the following steps: in response to a modification operation of a user on an object in a building information model, setting a dirty mark for the object; in response to a file saving instruction, determining a modified object set according to the dirty mark in a main thread, and adaptively selecting an incremental or full saving strategy based on the proportion of the number of the modified objects in the overall model, and generating a memory snapshot; and writing the memory snapshot data into a target file in an open document format in a background thread, wherein the file stores the building information model in the form of a ZIP file block. The data integrity and storage efficiency are taken into account, and the saving performance of a large BIM model is significantly improved.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a method and apparatus for incremental asynchronous saving of BIM files based on OpenDocument Format (ODF). Background Technology

[0002] Building Information Modeling (BIM) technology is widely used in the field of engineering design. The BIM model of a modern large-scale building project typically contains tens of thousands of building component objects. For example, the BIM model of a large commercial complex may contain more than 10,000 component objects such as beams, columns, slabs, and walls, as well as their complex dependencies.

[0003] However, existing BIM software suffers from severe performance bottlenecks when saving large model files. Taking typical parametric BIM software as an example, when a user modifies an assembly model containing more than 10,000 objects and presses the save button, the traditional saving method requires three steps: serialization, data compression, and file writing. The entire saving process can take tens of seconds or even longer, during which the user interface becomes unresponsive. This severely impacts design efficiency for design workflows that require frequent saving.

[0004] Currently, the main methods for storing large CAD / BIM files are as follows: Full snapshot saving, which serializes all objects and generates a complete memory snapshot each time it is saved; this method is simple to implement but time-consuming and space-intensive; Version control systems, which record the differences in each change; however, for complex binary CAD (Computer-Aided Design) files, the differential algorithm is complex and computationally expensive; Incremental backup algorithms use content-defined block algorithms, but require traversing the entire file to calculate hash values ​​during saving, resulting in high computational overhead. Therefore, there is an urgent need for a BIM file storage method that can guarantee data integrity while achieving efficient and seamless saving experiences. Summary of the Invention

[0005] The purpose of this application is to provide an incremental asynchronous saving method and related apparatus for BIM files based on ODF, which can solve the problems of low saving efficiency and long user waiting time in the prior art.

[0006] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for incremental asynchronous saving of BIM files based on ODF, comprising the following steps: In response to user modifications to objects in the Building Information Model, set the corresponding dirty flag for the objects.

[0007] In response to a file save command, in the main thread, the set of modified objects is determined based on the dirty flags of each object, and an appropriate save strategy is selected to generate a memory snapshot based on the proportion of the number of modified objects in the set to the building information model.

[0008] In a background thread, the data in the memory snapshot is written to the target file in the storage medium; the target file is a file in Open Document Format, used to store the building information model in the form of several ZIP file blocks.

[0009] Optionally, the memory snapshot can be an incremental snapshot or a full snapshot; based on the proportion of the number of modified objects in the modified object set to the building information model, an appropriate saving strategy is selected to generate the memory snapshot, including the following steps: If the proportion of the number of modified objects in the modified object set to the building information model is less than a preset threshold, an incremental snapshot containing the data corresponding to the modified object set will be generated.

[0010] If the proportion of the number of modified objects in the modified object set to the number of objects in the building information model is greater than or equal to a preset threshold, a complete snapshot containing all objects in the building information model will be generated.

[0011] Optionally, writing the data from the memory snapshot to a target file in the storage medium includes the following steps: The data in the memory snapshot is compressed and written to a temporary file.

[0012] After verifying the integrity of the temporary file, identify the ZIP file blocks in the target file that need to be updated, and compress the data in the temporary file and write it into the ZIP file blocks.

[0013] Optionally, after generating a memory snapshot, the method further includes the following steps: Remove dirty tags from all objects in the Building Information Model.

[0014] Optionally, the method further includes the following steps: A multi-version concurrency control mechanism is adopted to isolate the main thread's operation of generating memory snapshots from the user's editing operations on the building information model while the background thread is writing to the file.

[0015] Optionally, in response to user modifications to objects in the building information model, a corresponding dirty flag is set for the object, specifically: For any object in the Building Information Model, when a change in the object's properties is detected through the object's property change callback function, a corresponding dirty flag is set for the object.

[0016] Secondly, this application provides an ODF-based incremental asynchronous saving system for BIM files, used to implement the aforementioned ODF-based incremental asynchronous saving method for BIM files. This system includes the following functional modules: The Modify Object Tagging module is used to respond to user modifications to objects in the Building Information Model by setting corresponding dirty tags for the objects.

[0017] The memory snapshot generation module, in response to file save commands, determines the set of modified objects based on the dirty flags of each object in the main thread, and selects an appropriate save strategy to generate a memory snapshot based on the proportion of the number of modified objects in the modified object set in the building information model.

[0018] The target file saving module is used to write the data in the memory snapshot to the target file in the storage medium in a background thread; the target file is a file in Open Document Format and is used to store the building information model in the form of several ZIP file blocks.

[0019] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the ODF-based incremental asynchronous saving method for BIM files described above.

[0020] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the ODF-based incremental asynchronous saving method for BIM files described above.

[0021] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the ODF-based incremental asynchronous saving method for BIM files described above.

[0022] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides an incremental asynchronous saving method and related apparatus for BIM files based on ODF. This method, in response to user modifications to objects in the Building Information Model (BIM), sets dirty tags for the modified objects, thereby replacing global traversal with a lightweight tag with constant complexity, significantly reducing change identification overhead. In response to a file save command, the main thread determines the set of modified objects based on the dirty tags and adaptively selects an incremental or full save strategy to generate a memory snapshot based on the proportion of these objects in the overall model, compressing the main thread blocking time to 1-2 seconds and enabling rapid release of the user interface. Finally, a background thread writes the memory snapshot data to the target file using Open Document Format (BIM model stored as ZIP file blocks), allowing time-consuming disk writes and user editing to be executed concurrently, achieving a seamless "click-to-save" experience while ensuring data atomicity and integrity. Combined with an adaptive strategy based on the modification proportion, it balances data integrity and storage efficiency, significantly improving the saving performance of large BIM models. Attached Figure Description

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

[0024] Figure 1 This is a schematic diagram illustrating an application scenario of an incremental asynchronous saving method for BIM files based on ODF, provided as an embodiment of this application.

[0025] Figure 2 This is a flowchart illustrating an ODF-based incremental asynchronous saving method for BIM files, provided as an embodiment of this application.

[0026] Figure 3 This is a schematic diagram illustrating the complete technical route of an incremental asynchronous saving method for BIM files based on ODF, provided as an embodiment of this application.

[0027] Figure 4 This is a schematic diagram of the functional modules of an ODF-based incremental asynchronous BIM file saving system provided in an embodiment of this application.

[0028] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Currently, the following three methods are mainly used for saving large CAD or BIM files both domestically and internationally: The first method is to save a full snapshot, serializing all objects each time a save is made to generate a complete memory snapshot. This method is simple to implement and ensures data integrity, but it takes a long time to save and consumes a lot of storage space, which cannot meet the requirements for real-time saving.

[0031] The second method is a version control system, which uses a version control mechanism similar to SVN or Git to record the differences of each change. This method has a small storage space requirement and supports version rollback, but for complex binary CAD files, the difference algorithm is complex, computationally expensive, and prone to errors.

[0032] The third method is an incremental backup algorithm, which uses a content-defined chunking algorithm to dynamically identify changed data blocks. This method reduces network transmission volume and storage costs, but it requires traversing the entire file to calculate hash values ​​during saving, resulting in high computational overhead and making it unsuitable for frequent saving scenarios.

[0033] The core problem with existing technologies is the lack of a real-time incremental saving mechanism for BIM application scenarios, which fails to provide a user experience of saving with a single click while ensuring data integrity.

[0034] Based on the above problems, the present invention aims to provide an incremental asynchronous storage method that can both meet the requirements of large-scale BIM model storage efficiency and achieve a seamless user experience in storage.

[0035] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] The ODF-based incremental asynchronous saving method for BIM files provided in this application can be applied to, for example... Figure 1The application environment shown is illustrated. Terminal 102 runs a BIM editing software client. Users open and edit large BIM model files through this client; these files are stored in an Open Document Format (ODF) data storage system. When a user performs a save operation, terminal 102 responds locally and sends instructions to the server to execute the method provided in the following embodiments of this application, achieving efficient and seamless file saving. The data storage system can store data that needs to be processed by terminal 102 or server 104. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on other servers. Terminal 102 communicates with server 104 via a network.

[0037] The terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0038] In one exemplary embodiment, such as Figure 2 As shown, an incremental asynchronous saving method for BIM files based on ODF is provided. This method includes the following steps: S202. In response to user modifications to objects in the Building Information Model, set the corresponding dirty flag for the objects.

[0039] Specifically, when an object in the BIM model (such as a beam member) is modified by the user, the system automatically sets an internal status flag for that object, namely the "dirty flag," with a value of "true." This dirty flag is used to quickly identify which objects have been modified since the last save in subsequent save operations. The dirty flag setting operation itself is very lightweight, with a time complexity of constant level O(1), and will not cause significant delays to the user's editing operations. Operations that trigger the dirty flag setting include, but are not limited to, modification of object attributes, changes to dependent objects, completion of model recalculation, and manual marking by the user.

[0040] In this embodiment, responding to modifications to a BIM object and setting a dirty flag is achieved through an object attribute change callback function. When a value of an object's attribute changes, the attribute system automatically calls a pre-registered callback function. This callback function detects the object's current state. If the object is not in a "busy" state (e.g., performing other calculations), it triggers an object change signal and sets the corresponding dirty flag status bit to true.

[0041] S204. In response to the file save command, in the main thread, determine the set of modified objects based on the dirty flag of each object, and select an appropriate save strategy to generate a memory snapshot based on the proportion of the number of modified objects in the modified object set in the building information model.

[0042] To flexibly adapt to modification scenarios of different scales, in one embodiment, step S204 includes the following steps: S2041. If the proportion of the number of modified objects in the modified object set to the building information model is less than a preset threshold, then an incremental snapshot containing the data corresponding to the modified object set is generated.

[0043] S2042. If the proportion of the number of modified objects in the modified object set to the building information model is greater than or equal to a preset threshold, then generate a complete snapshot containing all objects in the building information model.

[0044] Specifically, after the user clicks the "Save" button, the software's main thread (i.e. the thread responsible for handling the user interface and interaction) immediately begins processing the save logic.

[0045] First, the main thread will traverse all objects in the current BIM model, and filter out all modified objects by checking the dirty flags set in step S202, forming a set of modified objects.

[0046] Then, calculate the proportion of the number of objects in this modified object set to the total number of objects in the model. Compare this proportion to a preset threshold (e.g., 50%) to determine the saving strategy for this iteration. If the proportion is less than the threshold, it means that the change is small. In this case, an incremental save strategy is adopted, which only serializes the data in the modified object collection and generates an incremental snapshot. If the proportion is greater than or equal to the threshold, it means that the scope of the changes is very large. In this case, the advantage of incremental saving is not obvious, and it may even increase the complexity. Therefore, a full saving strategy is adopted to serialize all objects in the model and generate a complete snapshot.

[0047] Finally, the selected data (modified objects or all objects) is serialized in parallel into a memory buffer, constructing a memory snapshot structure. This memory snapshot forms the basis for subsequent data writes to disk. The main thread releases the user interface after completing this step, and the user-perceived blocking time for the entire process is controlled within 1-2 seconds.

[0048] Through this adaptive strategy, this application adopts lightweight incremental saving in most scenarios with small-scale modifications, while directly adopting full saving when large-scale modifications cause the overhead of incremental and full saving to be comparable, thus avoiding the problems of data fragmentation and increased merging complexity.

[0049] S206. In a background thread, write the data in the memory snapshot to the target file in the storage medium; the target file is a file in Open Document Format, used to store the building information model in the form of several ZIP file blocks.

[0050] To ensure the atomicity of the data writing process and file integrity, in one embodiment, step S206 includes the following steps: S2061. Compress the data in the memory snapshot and write it to a temporary file. The naming convention for this temporary file is, for example, "original filename_timestamp.tmp".

[0051] S2062. After verifying the integrity of the temporary file, identify the ZIP file blocks in the target file that need to be updated, and compress the data in the temporary file before writing it into the ZIP file blocks. For example, by comparing checksums or hash values, if the verification passes, delete the original target file and rename the temporary file to the name of the original target file.

[0052] Specifically, after generating a memory snapshot in step S204, the system creates one or more background threads to perform the actual, time-consuming disk write operations. After starting the background threads, the main thread immediately resumes responding to user actions, allowing the user to continue editing the model.

[0053] The background thread is responsible for reading the data in the memory snapshot, identifying the file blocks that need to be updated based on the structure of the ODF compound file (which is essentially a ZIP archive), compressing the data, and writing it to a temporary file on the storage medium.

[0054] Once all data has been written and confirmed to be correct, an atomic operation is used to replace the temporary file with the original target file. This ensures that even if a system crash or power outage occurs at any stage of the write operation, at least one complete and valid version of the file will exist on the disk, and the original valid file will not be damaged.

[0055] By implementing steps S202 to S206 above, this application avoids the overhead of global traversal through the dirty marking mechanism, frees the user interface from time-consuming operations through the two-stage asynchronous mechanism, and adaptively selects the saving strategy according to the proportion of changes, thereby significantly reducing the user's save waiting time from tens of seconds to 1-2 seconds, and realizing a seamless "click to save" experience.

[0056] In an exemplary embodiment, after step S204 above, that is, after the main thread successfully generates a memory snapshot, the method further includes: S205. Remove the dirty markers from all objects in the BIM.

[0057] Since a snapshot has been successfully created based on the current modified state, and these modifications have been "documented," it is necessary to reset the dirty flags of all objects to "false" values ​​to provide the correct starting point for the next save operation.

[0058] In an exemplary embodiment, in order to ensure that the data edited by the user during asynchronous saving does not conflict with the data being written, the method also employs a multi-version concurrency control mechanism to isolate the main thread's operation of generating a memory snapshot from the user's editing operation of the building information model during the background thread's writing of the file.

[0059] Specifically, when the main thread creates a memory snapshot, it obtains a "read snapshot" of the data, allowing other threads (such as user editing operations) to concurrently read and modify object data in the currently working memory. Snapshot data and real-time editing data are isolated from each other and do not block each other.

[0060] Meanwhile, a "save task queue" is maintained to handle scenarios of continuous and rapid saving: if the user clicks save again while the previous save task is still in the snapshot creation stage (stage one) on the main thread, the new task needs to wait; if the previous task has entered the background writing stage (stage two), the new task can create new snapshots in parallel; however, for write operations on the same file, the system ensures that they are executed serially to avoid resource contention.

[0061] In addition, a debouncing strategy can be implemented, such as saving only one version within 10 seconds to avoid a large number of invalid save operations caused by frequent user clicks.

[0062] Next, the ODF-based incremental asynchronous saving method for BIM files provided in this application will be applied to the saving process of a large assembly BIM model after editing. The specific operation is as follows: A user opens an assembly model containing over 10,000 objects in BIM software, including building components such as beams, columns, slabs, and walls. The user modifies the design parameters of ten objects, representing 0.1% of the total design parameters.

[0063] When the user presses the save button, the system enters a two-stage asynchronous save process. In stage one, the main thread iterates through all objects and identifies ten modified objects using the dirty flag status. Since the modification percentage is less than the 50% threshold, the system adopts an incremental save strategy. The main thread serializes the data of the ten modified objects into a memory buffer in parallel, building an incremental snapshot. This process takes less than one second. After completion, the main thread releases the user interface, allowing the user to continue editing the model.

[0064] In Phase Two, a background thread reads the incremental snapshot, identifies the ZIP file blocks that need updating, compresses the data and writes it to a temporary file, verifies file integrity, and then atomically replaces the original target file. This background thread execution takes 12 seconds, but the user interface is completely released during this time, allowing users to continue editing the model unaffected. After saving, the system clears the dirty flags from all objects, ending the saving process.

[0065] According to the performance test results of this embodiment, the user waiting time has been reduced from 120 seconds for traditional serial full save to 1 second, with a performance improvement of 99.2%, achieving a seamless "click to save" experience.

[0066] The ODF-based incremental asynchronous saving method for BIM files provided in the above embodiments of this application has the following complete technical approach: Figure 3 As shown, during the user's BIM model editing process, dirty flags are set for modified objects in real time via attribute change callbacks. After the user triggers a save operation, a two-stage asynchronous save process is initiated: In the first stage, the main thread identifies the set of dirty flag objects and adaptively selects either incremental or full snapshot strategies based on the proportion of modified objects (threshold 50%). Subsequently, the data is serialized in parallel to a memory buffer to build a memory snapshot. The main thread is blocked for only 1-2 seconds before releasing the user interface and clearing the dirty flags. In the second stage, an asynchronous write is performed by a background thread. Based on the ODF composite file structure, the ZIP file blocks that need to be updated are identified. The memory snapshot data is compressed and written to a temporary file. After integrity verification, the original target file is atomically replaced. If the verification fails, the temporary file is deleted and the user is prompted, thus achieving non-blocking and efficient saving while ensuring data consistency.

[0067] Compared with the prior art, this application has the following beneficial effects: The method provided in this application employs a dirty marking mechanism to mark modified objects in real time, avoiding the overhead of traversing all objects during traditional saving and reducing the analysis time before saving from linear complexity to constant complexity. Furthermore, it uses a two-stage asynchronous saving mechanism in the foreground and background, reducing user waiting time from tens of seconds to one to two seconds, achieving a seamless saving experience. Simultaneously, it adaptively selects incremental or full saving strategies based on the proportion of modified objects, ensuring data integrity while maintaining performance. In addition, a multi-version concurrency control mechanism ensures that snapshot data is isolated from user edits, avoiding data races and conflicts. Finally, an atomic write mechanism is used during file saving to ensure data integrity even in the event of a system crash, preventing file corruption.

[0068] Based on the same inventive concept, this application also provides a system for implementing the ODF-based incremental asynchronous saving method for BIM files described above. The solution provided by this system is similar to the implementation described in the above method. In an exemplary embodiment, such as... Figure 4 As shown, an ODF-based incremental asynchronous saving system for BIM files is provided to implement the ODF-based incremental asynchronous saving method for BIM files described above. This system includes the following functional modules: The object tagging module 402 is used to set the corresponding dirty tag for the object in response to the user's modification operation on the object in the building information model.

[0069] The memory snapshot generation module 404 is used to respond to file save commands. In the main thread, it determines the set of modified objects based on the dirty flags of each object, and selects an appropriate save strategy to generate a memory snapshot based on the proportion of the number of modified objects in the modified object set in the building information model.

[0070] The target file saving module 406 is used to write the data in the memory snapshot to the target file in the storage medium in a background thread; the target file is a file in the Open Document Format and is used to store the building information model in the form of several ZIP file blocks.

[0071] certainly, Figure 4 The architecture shown is merely exemplary; it can be omitted as needed when implementing different functionalities. Figure 4 One or at least two components of the system shown.

[0072] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 5As shown, the computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores target files in an Open Document Format (ODF) architecture. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it can implement the ODF-based incremental asynchronous saving method for BIM files provided in the previous embodiment.

[0073] Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0074] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0075] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0076] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0077] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations and be authorized by the owner of the corresponding device.

[0078] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0079] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

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

[0081] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for incremental asynchronous saving of BIM files based on ODF, characterized in that, include: In response to a user's modification operation on an object in the building information model, when a change in the object's attribute is detected through the object's attribute change callback function, a corresponding dirty flag is set for the object; In response to a file save command, in the main thread, the set of modified objects is determined based on the dirty flags of each object, and an appropriate save strategy is selected to generate a memory snapshot based on the proportion of the number of modified objects in the set of modified objects in the building information model; if the proportion is less than a preset threshold, an incremental snapshot containing the data corresponding to the set of modified objects is generated. If the percentage is greater than or equal to the preset threshold, a complete snapshot containing the original objects in the building information model is generated. In a background thread, the data in the memory snapshot is written to the target file in the storage medium; The target file is an open document format file used to store the building information model in the form of several ZIP file blocks.

2. The incremental asynchronous saving method for BIM files based on ODF according to claim 1, characterized in that, Writing the data from the memory snapshot to a target file in the storage medium includes: The data in the memory snapshot is compressed and written to a temporary file; After verifying the integrity of the temporary file, the ZIP file blocks that need to be updated in the target file are identified, and the data in the temporary file is compressed and written into the ZIP file blocks.

3. The incremental asynchronous saving method for BIM files based on ODF according to claim 1, characterized in that, After generating a memory snapshot, the method further includes: Remove dirty tags from all objects in the building information model.

4. The incremental asynchronous saving method for BIM files based on ODF according to claim 1, characterized in that, The method further includes: A multi-version concurrency control mechanism is adopted to isolate the main thread's operation of generating a memory snapshot from the user's editing operation of the building information model during the background thread's writing of the file.

5. A BIM file incremental asynchronous saving system based on ODF, characterized in that, include: The object tagging module is used to respond to user modification operations on objects in the building information model. When the attribute change of the object is detected by the attribute change callback function of the object, the corresponding dirty tag is set for the object. The memory snapshot generation module is used to respond to file save commands. In the main thread, it determines the set of modified objects based on the dirty flags of each object, and selects an appropriate save strategy to generate a memory snapshot based on the proportion of the number of modified objects in the modified object set in the building information model. If the proportion is less than a preset threshold, an incremental snapshot containing the data corresponding to the modified object set is generated. If the percentage is greater than or equal to the preset threshold, a complete snapshot containing the original objects in the building information model is generated. The target file saving module is used to write the data in the memory snapshot into the target file in the storage medium in a background thread; The target file is an open document format file used to store the building information model in the form of several ZIP file blocks.

6. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the ODF-based incremental asynchronous saving method for BIM files according to any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the ODF-based incremental asynchronous saving method for BIM files as described in any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the ODF-based incremental asynchronous saving method for BIM files as described in any one of claims 1-4.

Images