Building information model data storage method, device, equipment, medium and product

Abstract

This application discloses a method, apparatus, device, medium, and product for storing Building Information Modeling (BIM) data, relating to the field of information storage technology. The method includes: acquiring model files drawn by the user; classifying the model files according to preset rules to obtain data files of different categories; the data file categories include non-geometric and geometric types; splitting the geometric type data files according to a preset structure and storing each independent data block as a corresponding geometric block BRP file; generating corresponding XML files for the non-geometric type data files according to the ODF standard format; and packaging and compressing all the geometric block BRP files, the XML files of different functions, and related auxiliary resource files to generate an ODF file compressed package. This application can effectively reduce the overall file size, improve data transmission efficiency, and enhance the cross-platform compatibility of data.

Description

Technical Field

[0001] This application relates to the field of information storage technology, and in particular to a method, apparatus, equipment, medium and product for storing building information model data. Background Technology

[0002] Building Information Modeling (BIM), as a core digital modeling technology, has been widely applied in the engineering and construction industry. Currently, BIM data storage primarily uses three formats: IFC, RVT, and DGN. IFC, an internationally accepted standard format, uses STEP text storage, which suffers from drawbacks such as large file redundancy, complex internal architecture, and high parsing costs, and does not support incremental replacement of local data. RVT and DGN are vendor-specific proprietary formats, limited by software vendor technical barriers, resulting in binding and locking issues, hindering cross-platform data interoperability, and failing to guarantee long-term archiving of engineering data. Therefore, existing BIM data storage is mostly in custom formats, lacking versatility, and there is an urgent need for a BIM file storage solution with smaller file sizes and higher versatility. Summary of the Invention

[0003] In view of the above-mentioned defects or deficiencies in the related technologies, the purpose of this application is to provide a method, apparatus, equipment, medium and product for storing building information model data, which can effectively reduce the overall file size, improve data transmission efficiency and data cross-platform universality.

[0004] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides a method for storing building information model (BIM) data, comprising: acquiring model files drawn by a user; classifying the model files according to preset rules to obtain data files of different categories; the categories of the data files include non-geometric types and geometric types; splitting the geometric type data files according to a preset structure, and storing each independent data block after splitting as a corresponding geometric block brp file; generating corresponding function XML files for the non-geometric type data files according to the ODF standard format; and packaging and compressing all the geometric block brp files, the XML files of different functions, and related auxiliary resource files to generate an ODF file compressed package.

[0005] Optionally, the method further includes: classifying the model file according to preset rules to obtain data files of different categories, including: parsing and splitting the model file into geometric data, attribute data, material data, metadata, and component relationship data according to preset rules; wherein, the geometric data is used to describe the shape of the model, including the spatial coordinates, vertices, edges, faces, solids, shape contours, spatial positions, and orientations of the components; the attribute data includes non-geometric business information of the components; the material data includes the appearance information of the components; the metadata includes engineering document management information; and the component relationship data includes the hierarchical subordinate relationship, spatial attachment relationship, assembly relationship, and binding relationship between components and corresponding attributes and materials.

[0006] Optionally, the method further includes: generating corresponding XML files for non-geometric data files according to the ODF standard format, comprising: extracting the structured attributes corresponding to the attribute data, the material data, the metadata, and the component association data, and generating corresponding XML files according to the ODF standard format; wherein, the attribute data generates content.xml for storing basic model information; the material data generates styles.xml for storing model style information; the metadata generates meta.xml for storing document information; and the component association data generates settings.xml for storing model association configuration.

[0007] Optionally, the method further includes: packaging and compressing all geometric block BRP files, XML files with different functions, and related auxiliary resource files to generate an ODF file compressed package, including: collecting, sorting, and cataloging XML files with different attributes, all geometric block BRP files, and related auxiliary resource files according to the standard directory structure and packaging specifications of the ODF international open document format, and performing packaging and compression using the ZIP compression algorithm to generate the ODF file compressed package.

[0008] Optionally, the method further includes: detecting user-side modifications to the model file, determining the XML file and brp file to be updated based on the modifications; updating the XML file and brp file to be updated to obtain the current XML file and the current brp file, while keeping other files in the ODF file archive unchanged; updating the version information and modification time in the index file based on the current XML file and the current brp file to obtain the current index file; and generating the current ODF file archive or directly replacing the corresponding files in the ODF file archive based on the current XML file, the current brp file, and the current index file.

[0009] Optionally, the method further includes: parsing the obtained IFC file according to the mapping rules between the IFC data model and the ODF data model to obtain a parsed IFC file; extracting the geometric data, attribute data, material data, metadata, and component relationship data from the parsed IFC file, and splitting the geometric data to generate BRP files corresponding to each independent data block; converting the attribute data, material data, metadata, and component relationship data according to the ODF standard format to generate XML files with different functions; and generating an ODF file compressed package based on all BRP files, XML files with different functions, and related auxiliary resource files.

[0010] Secondly, this application provides a storage device for building information model data, comprising: The file acquisition module retrieves the model files drawn by the user. The file classification module is used to classify the model files according to preset rules to obtain data files of different categories; the categories of the data files include non-geometric types and geometric types; The splitting and generation module is used to split geometric data files according to a preset structure and store each split independent data block as a corresponding geometric block brp file; The file generation module is used to generate XML files with corresponding functions from non-geometric data files according to the ODF standard format. The compression generation module is used to package and compress all geometric block BRP files, XML files with different functions, and related auxiliary resource files to generate an ODF file archive.

[0011] 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 method for storing building information model data as described in the first aspect.

[0012] 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 method for storing building information model data as described in the first aspect.

[0013] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method for storing building information model data as described in the first aspect.

[0014] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, device, medium, and product for storing Building Information Modeling (BIM) data. It involves classifying user-drawn BIM model files to obtain different categories of data files; these categories include non-geometric and geometric types. Geometric data files are split according to a preset structure, and each independent data block is stored as a corresponding geometric block BRP file. Non-geometric data files are processed according to the ODF standard format to generate corresponding functional XML files. All geometric block BRP files, functional XML files, and related resource files are packaged and compressed to generate an ODF file archive. Compared with existing technologies, this application builds a storage system based on the ODF international open standard. On the one hand, it splits and manages model data by type, and stores geometric data in independent blocks, effectively reducing the overall file size and improving data transmission and loading efficiency. On the other hand, it uses a universal XML format to describe various attribute information, eliminating the need to develop dedicated parsing tools and significantly lowering the threshold for software adaptation and secondary development. At the same time, the standardized directory structure and index files enable unified data management, supporting independent access to local data and subsequent incremental updates. This avoids the vendor lock-in problem of traditional proprietary formats, ensuring cross-platform use and long-term secure archiving of BIM engineering data, and significantly improving universality, flexibility, and practicality. Attached Figure Description

[0015] 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.

[0016] Figure 1 This is an application environment diagram of a method for storing building information model data according to an embodiment of this application; Figure 2 A flowchart illustrating a method for storing building information model data according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an ODF file compressed package provided in an embodiment of this application; Figure 4 A functional module diagram of a building information model data storage device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0017] 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.

[0018] 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.

[0019] The method for storing building information model data provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 101 communicates with server 102 via a network. A data storage system can store the data that server 102 needs to process. The data storage system can be set up independently, integrated into server 102, or placed in the cloud or on another server. Terminal 101 can send user-drawn model files to server 102. After receiving the model files, server 102 classifies them according to preset rules, obtaining different categories of data files; extracts the attributes of each category of data files, generating XML files corresponding to different attributes; splits the geometric data files according to a preset structure, storing each independent data block as a corresponding geometric block BRP file; and packages and compresses the XML files with different attributes, all geometric block BRP files, and related auxiliary resource files to generate an ODF file archive. In addition, in some embodiments, the method for storing building information model data can also be implemented separately by server 102 or terminal 101. For example, terminal 101 can directly store the model file drawn by the user in ODF format, or server 102 can obtain the model file drawn by the user from the data storage system and store the model file drawn by the user in ODF format.

[0020] The terminal can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, etc. The server 102 can be implemented by a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0021] In one exemplary embodiment, such as Figure 2 As shown, a method for storing building information model (BIM) data is provided. This method is executed by a computer device. In this embodiment, the method is applied to... Figure 1 Taking server 102 as an example, the explanation includes the following steps S201 to S205. Wherein: Step S201: Obtain the model file drawn by the user.

[0022] In the example implementation, the model file drawn by the user is the original BIM model source file that the end user has completed drawing and editing in the modeling software; the model file contains a complete set of original modeling data such as the complete shape, parameters, materials, project information, and component assembly logic of the building components; the model file source includes proprietary format files exported by modeling software such as Revit and Bentley, as well as IFC general intermediate format files.

[0023] Step S202: Classify the model files according to preset rules to obtain data files of different categories; the categories of data files include non-geometric types and geometric types.

[0024] In the example embodiment, the preset rule is a pre-defined BIM data dimension division standard, which uses the functional purpose of the information carried by the data as the division basis. The specific division determination rule is as follows: If BIM data is only used to describe the spatial shape, dimensions, and orientation of a component, it is classified as geometric data; if BIM data contains non-geometric business information such as component engineering parameters, numbering specifications, and business indicators, it is classified as attribute data; if BIM data contains appearance information such as component color, texture, transparency, and rendering parameters, it is classified as material data; if BIM data contains project management information such as project name, modeler, version, creation time, and modification history, it is classified as metadata; if BIM data is used to record component hierarchical subordination, spatial attachment, assembly combination, and the binding relationship between components and attributes and materials, it is classified as component association data.

[0025] Optionally, step S202 above includes: parsing and splitting the model file's data across the entire domain according to preset rules, splitting the model file into geometric data, attribute data, material data, metadata, and component relationship data; wherein, geometric data is used to describe the model's shape information, including the component's spatial coordinates, vertices, edges, faces, solids, shape contours, spatial position, and orientation; attribute data includes the component's non-geometric business information; material data includes the component's appearance information; metadata includes engineering document management information; and component relationship data includes the hierarchical subordinate relationship, spatial attachment relationship, assembly relationship, and binding relationship between components and their corresponding attributes and materials.

[0026] It should be noted that this application divides the aforementioned geometric data, attribute data, material data, metadata, and component relationship data into two main categories: non-geometric types and geometric types. Non-geometric types include attribute data, material data, metadata, and component relationship data. By dividing BIM data into two main categories and five subcategories, a foundation is provided for the subsequent generation of XML and BRP files with different attributes. Furthermore, by defining the model files in a refined manner, the content boundaries and uses of each type of data are clarified, achieving structured data management and facilitating faster identification of the scope of modifications without having to traverse all five types of data to screen for changes.

[0027] Step S203: Split the geometric data file according to a preset structure, and store each independent data block as a corresponding geometric block brp file.

[0028] In the example implementation, the preset structure refers to the pre-defined dimensions for splitting geometric data, providing three optional splitting criteria that can be used individually or in combination. The first is splitting the structure by floor level, where geometric data blocks are divided based on building floors, and the geometric information of all components within the same floor is collected into a single BRP file. The second is splitting the structure by component type, where different components such as walls, beams, columns, floor slabs, doors, and windows are divided into independent blocks based on component type. The third is splitting the structure by spatial area, where geometric data is divided according to planning zones, axial intervals, and functional blocks for large-scale models such as large parks, complexes, and factories.

[0029] Optionally, step S203 may include: dividing the geometric data into multiple independent geometric data blocks according to preset splitting rules by floor, component type, or spatial region; assigning a unique identifier to each geometric data block and encoding it in a format; and storing each encoded independent geometric data block as a corresponding brp file to obtain the corresponding geometric block brp file.

[0030] It should be noted that the splitting follows the principle of spatial continuity of geometric information and close association of components within the same data block. After the splitting is completed, each group of independent geometric data blocks is separately packaged to generate a BRP file.

[0031] Step S204: Generate an XML file with corresponding functions from non-geometric data files according to the ODF standard format.

[0032] In the example embodiment, the ODF standard format refers to the international standard for open document formats. It uses XML-based syntax to define document structure, tag system, and directory encapsulation rules, and features standardized root nodes, namespaces, hierarchical tags, and character encoding specifications. This application follows the ODF 1.2 and above specifications, uses UTF-8 encoding, relies on the ODF preset document node framework, and customizes extended business tags for BIM non-geometric data without disrupting the native ODF compatibility system. The ODF specification stipulates that the root directory contains the main XML document, the META-INF directory stores the manifest.xml index list, and the entire document is archived using ZIP archives. It is a universal, open, and copyright-free document storage standard.

[0033] Optionally, step S204 above may include extracting the structured attributes corresponding to the attribute data, material data, metadata, and component association data respectively, and generating corresponding XML files according to the ODF standard format; wherein, the attribute data generates content.xml for storing basic model information; the material data generates styles.xml for storing model style information; the metadata generates meta.xml for storing document information; and the component association data generates settings.xml for storing model association configuration.

[0034] Understandably, the process involves traversing all non-geometric data to distinguish four sub-data sets: attribute data, material data, metadata, and component relationship data. Four types of blank XML documents are initialized according to the ODF standard, with unified configuration of the ODF standard namespace, UTF-8 encoding declaration, and root node basic tags. For attribute data, business information such as component number, engineering parameters, and dimensions is filled in, ODF-compatible extension tags are inserted, and content.xml is generated. For material data, appearance information such as color, texture, transparency, and rendering parameters are filled in, and style class standard tags are written to generate styles.xml. For metadata, management information such as project name, design unit, modeler, version, and time is filled in, and ODF meta information nodes are matched to generate meta.xml. For component relationship data, floor hierarchy, component assembly, and BRP file binding mapping relationships are filled in, configuration class tags are configured, and settings.xml is generated. The tag hierarchy and format syntax of the four XML files are verified to fully comply with the ODF specification, redundant and invalid fields are removed, and standardized XML file output is completed.

[0035] It should be noted that by storing geometric data in independent blocks as BRP files, data redundancy is reduced, file size is compressed, and transmission and loading efficiency is improved. Converting attribute data, material data, metadata, and component relationship data into standard XML files reduces the difficulty of data parsing, eliminating the need for customized parsing tools. Furthermore, this application adheres to the ODF international open standard, avoiding the risk of vendor lock-in associated with proprietary formats. The geometric block design also supports on-demand access and partial updates, enabling cross-platform use and long-term secure archiving of engineering BIM data, significantly improving practicality and versatility.

[0036] Step S205: Package and compress all geometric block brp files, XML files with different functions, and related auxiliary resource files to generate an ODF file compressed package.

[0037] In the example implementation, the related auxiliary resource files are supporting files attached to the main BIM model data, auxiliary model display, and project archiving. Specifically, they include the following types: Image materials: model preview thumbnails, component texture maps, real-world reference images, and construction drawing screenshots; Document attachments: design specifications, material quality assurance documents, change orders, quantity calculation drafts, and technical disclosure documents; Auxiliary configuration files: rendering parameter configurations, view preset files, section view configurations, and collision detection reports; Audio and video materials: model explanation videos, on-site construction videos, and design communication recordings; Other auxiliary files: font files, unit conversion configurations, coordinate reference parameters, and verification log files.

[0038] Optionally, step S205 includes collecting, sorting, and cataloging XML files with different attributes, all geometric block BRP files, and related auxiliary resource files according to the standard directory structure and encapsulation specifications of the ODF international open document format, and performing packaging and compression using the ZIP compression algorithm to generate an ODF file compressed package.

[0039] Understandably, all content.xml, styles.xml, meta.xml, settings.xml, and all split geometric block BRP files and project-related resource files are compiled, categorized and archived according to the ODF standard directory structure. Various XML files are placed in the root directory of the compressed package, all geometric block BRP files are grouped into the Configurations2 directory, and thumbnails and attachment resources are placed into the attachments directory, ensuring neat file partitioning and type isolation. Files within the directories are sorted and organized, empty and redundant files are removed, and file correspondence, data integrity, and naming conventions are verified. A ZIP compression algorithm is used to compress the entire directory structure and all files, preserving the complete directory hierarchy and file relationships. This generates an ODF file compressed package that meets international ODF standards, has a unified structure, and is cross-platform readable.

[0040] For example, such as Figure 3 As shown, create a root directory and subdirectories according to the preset ODF directory structure. Place content.xml, styles.xml, meta.xml, and settings.xml in the root directory of the compressed package. Store all BRP geometry block files in the Configurations2 subdirectory. Store thumbnails, project attachments, documentation, and other auxiliary resource files in the attachments subdirectory. Store the manifest.xml index file in the META-INF subdirectory. Perform lossless ZIP compression on all files that have completed directory archiving to generate a standard compressed package file with the suffix .bim-odf.

[0041] It should be noted that, based on the standard ODF directory system, XML files, geometric block BRP files, and auxiliary resources are uniformly collected, archived, and compressed as a whole, achieving structured, standardized, and hierarchical storage of BIM model data. Through categorized and partitioned archiving, text-based non-geometric data, binary geometric block data, and auxiliary resource data are isolated from each other, resulting in a clear and orderly file structure that facilitates rapid retrieval, location, and partial replacement updates. The use of universal ZIP lossless compression effectively eliminates data redundancy, significantly reduces the overall file size, and saves server storage space and network transmission costs. Furthermore, it fully complies with the international open ODF standard for encapsulation, ensuring that the final generated files have strong cross-platform and cross-software compatibility, overcoming the vendor lock-in problem of traditional proprietary BIM formats, and guaranteeing long-term readability, reusability, and archiving of engineering model data, significantly improving the universality, stability, and engineering practicality of BIM files.

[0042] By implementing steps S201 to S205, the BIM model files drawn by the user are classified to obtain data files of different categories. The data file categories include non-geometric and geometric types. The geometric type data files are split according to a preset structure, and each independent data block is stored as a corresponding geometric block BRP file. The non-geometric type data files are generated into XML files with corresponding functions according to the ODF standard format. All geometric block BRP files, XML files with different functions, and related auxiliary resource files are packaged and compressed to generate an ODF file compressed package. Compared with the prior art, this application builds a storage system based on the ODF international open standard. On the one hand, it splits and manages model data according to type, and stores geometric data independently in blocks, effectively reducing the overall file size and improving data transmission and loading efficiency. On the other hand, it uses the general XML format to describe various attribute information, eliminating the need to develop dedicated parsing tools and significantly reducing the threshold for software adaptation and secondary development. Meanwhile, the standardized directory structure and index files enable unified data management, support independent access to local data and subsequent incremental updates, avoid the vendor lock-in problem of traditional proprietary formats, ensure cross-platform use and long-term secure archiving of BIM engineering data, and significantly improve versatility, flexibility and practicality.

[0043] Furthermore, compared with plain text storage in IFC format, this application uses ZIP compression, XML semantic description, and BRP binary files (optional ASCII text file type), which can reduce file size and achieve lightweight file storage, significantly reducing storage and transmission costs. Non-geometric data is stored in the standard XML format, which can be read directly using a general XML parser. It is easy to parse and does not require the development of a dedicated parser, thus lowering the technical threshold for software development. Large geometric data can be divided into blocks and stored as multiple independent BRP files, enabling on-demand loading and reading only the required data blocks, thus improving data access efficiency. When some data in the model file changes, only the corresponding XML and brp files are updated, without having to regenerate the entire file, which significantly reduces update time and computational resource consumption. Based on the ODF international standard (ISO / IEC26300), the file format is ensured to be open, avoiding vendor lock-in risks and guaranteeing long-term data accessibility; the XML extension mechanism is adopted to support custom elements and attributes, and the data model can be flexibly extended according to different application scenarios.

[0044] In other embodiments, the above method further includes the following steps S301 to S304, namely: Step S301: Detect the modifications made to the model file by the user, and determine the XML file and brp file to be updated based on the modifications. Step S302: Update the XML file and brp file to be updated to obtain the current XML file and the current brp file, while keeping other files in the ODF file archive unchanged; Step S303: Update the version information and modification time in the index file based on the current XML file and the current brp file to obtain the current index file; Step S304: Based on the current XML file, the current brp file, and the current index file, generate the current ODF file archive or directly replace the corresponding file in the ODF file archive.

[0045] It should be noted that only the modified XML files and BRP block files are located, and the entire model data is not traversed indiscriminately, which greatly reduces the data comparison and calculation overhead; only the target files are refreshed, and the unmodified files in the compressed package are completely preserved, ensuring the stability of the overall file structure and that the original data is not overwritten or tampered with.

[0046] In other embodiments, in order to convert the IFC file to generate an ODF file compressed package, the above method further includes the following steps S401 to S403, namely: Step S401: According to the mapping rules between the IFC data model and the ODF data model, the obtained IFC file is parsed to obtain the parsed IFC file; Step S402: Extract and parse the geometric data, attribute data, material data, metadata, and component relationship data of the IFC file, and split the geometric data to generate brp files for each independent data block; convert the attribute data, material data, metadata, and component relationship data according to the ODF standard format to generate XML files with different functions. Step S403: Generate an ODF file compressed package based on all BRP files, XML files with different functions, and related auxiliary resource files.

[0047] Understandably, the mapping rules between the IFC data model and the ODF data model are based on a pre-defined four-layer matching standard: semantic correspondence, data splitting, format conversion, and file archiving. Using IFC native entities, attribute sets, and relationships as input, it matches one-to-one with the five types of data carriers (brp geometric blocks, content.xml, styles.xml, meta.xml, and settings.xml) of the ODF storage system in this application. It is fully compatible with the ODF 1.2 international specification and the IFC4 standard, ensuring no information loss and semantic consistency during conversion. The overall system is divided into five sub-rules: geometric data mapping, attribute data mapping, material data mapping, metadata mapping, and component relationship mapping. 1. The geometric data mapping rules are as follows: 1) Extract all geometric entity data, including IfcShapeRepresentation, IfcExtrudedAreaSolid, IfcCartesianPoint, etc., from the IFC file, including shape, coordinates, facets, and orientation; 2) Cut the data into independent geometric blocks according to the preset splitting structure (floor / component type / spatial area); 3) Do not write the geometric blocks into XML text, but encode them uniformly and store them separately as .brp binary block files; 4) Record the unique ID, floor to which each brp file belongs, and the corresponding component GlobalId in the index manifest.xml.

[0048] 2. The attribute data mapping rules are as follows: 1) Extract the direct attributes, IfcPropertySet parameter set, quantity, strength grade, size specifications and other business parameters of the component entities (IfcWall, IfcBeam, IfcDoor, etc.) in the IFC file; 2) Fill all the structured data into the main content node of the ODF standard content.xml; 3) Use the ODF standard namespace, expand the BIM-specific business tags, and use the component GlobalId as the unique associated primary key.

[0049] 3. The material data mapping rules are as follows: 1) Parse the IfcMaterial, IfcMaterialLayer, and IfcRelAssociatesMaterial material association entities in the IFC file, and extract appearance parameters such as color, texture map, transparency, rendering thickness, and material type; 2) Write them uniformly into the style definition node of the ODF style document styles.xml; 3) Components reference the corresponding material style in styles.xml through the style-name attribute, which is consistent with the native ODF style reference logic.

[0050] 4. The metadata mapping rules are as follows: 1) Extract the IFC top-level IfcProject project information, IfcOwnerHistory creation / modification records, modelers, project name, version, unit baseline, coordinate origin and other project management information; 2) Fully match and fill in the ODF standard meta.xml metadata nodes, and reuse the ODF native author, time and project tag fields; 3) Supplement the conversion log, IFC source file path and other extended management fields.

[0051] 5. The component association mapping rules are as follows: 1) Parse IFC associated entities: IfcRelAggregates (floor-component dependency), IfcRelContainedInSpatialStructure (spatial dependency), IfcRelConnects (component assembly), IfcRelAssociates (component binding material / attribute); 2) Map all hierarchical dependency, spatial affiliation, assembly pairing, component-brp file binding, and component-material style binding to the settings.xml configuration node; 3) Create the component GlobalId in settings.xml. brp file name, component GlobalId A bidirectional index mapping table for style names.

[0052] 6. The mapping rules for encapsulation and archiving are as follows: 1) The generated content.xml, styles.xml, meta.xml, and settings.xml files are placed in the root directory of the ODF compressed package; 2) All BRP geometric blocks are uniformly classified into the Configurations2 subdirectory; 3) Texture maps, drawings, documentation, and other IFC-related resources are classified into the attachments directory; 4) META-INF / manifest.xml automatically records all file paths, types, and versions to form a complete ODF package structure.

[0053] Optionally, load the IFC source file, traverse all IfcProjects, component entities, attribute sets, material entities, and relationship entities through the IFC parsing library; perform data splitting according to five mapping rules: geometric data is sent to the BRP generation channel, while attribute data, material data, metadata, and component relationships are sent to four types of XML generation channels respectively; geometric data is split and encoded by floor / component / space area, and batch outputs independent BRP block files; the four types of non-geometric data are populated with fields according to the ODF standard format XML syntax, namespace, and node specifications, and the tag format is verified to be compliant; write the binding mapping relationship between components and BRP, and between components and styles in settings.xml; summarize all BRP files, XML files, and related auxiliary resource files, and archive them according to the ODF standard directory; generate a manifest.xml index list, and compress and output a complete ODF file compressed package.

[0054] It should be noted that by pre-setting the mapping rules between the IFC data model and the ODF data model, the IFC source file can be parsed accurately and completely, avoiding problems such as data loss, field confusion, and information omission, and ensuring the integrity and consistency of the model data during cross-format conversion. By uniformly extracting geometric data, attribute data, material data, metadata, and component relationship data, a full-coverage migration of all IFC model data is achieved. Simultaneously, geometric data is segmented into lightweight BRP files, and various non-geometric data are categorized and converted according to ODF specifications to generate functionally independent XML files. This gives the converted data inherent advantages such as decoupling of geometric and non-geometric data, segmented storage, and categorized management, completely resolving the shortcomings of traditional IFC files, including overall bloat, slow loading, difficult parsing, inability to perform partial updates, and high redundancy. Finally, all BRP segmented files, standardized XML files, and auxiliary resources are integrated to generate an ODF compressed package. This transforms the original IFC files, which were highly versatile but lacked practicality, into standardized ODF files with a clear structure, incremental updates, segmented loading, cross-platform compatibility, and long-term archiving capabilities. This significantly improves the read / write efficiency, transmission efficiency, and iterative maintenance capabilities of BIM model files, effectively ensuring compatibility with existing massive amounts of engineering IFC data, reducing project data migration costs, and enhancing industry adaptability and engineering practical value.

[0055] Furthermore, compared with existing technologies (FBX, 3DS, etc.), this application has the following advantages: Addressing the shortcomings of existing technologies such as FBX and 3DS, which are proprietary binary packages lacking unified international standards, this application constructs a dedicated BIM storage architecture based on the ODF international standard (ISO / IEC 26300). Its core innovations lie in the semantic layering system of BIM engineering data, the geometric block strategy driven by engineering semantics, the bidirectional mapping between IFC and ODF standards, and the incremental update mechanism based on the manifest, rather than simply reusing the general ZIP sub-package approach. Furthermore, FBX and 3DS vendor formats face the risk of version obsolescence and format gaps; ODF, on the other hand, is an ISO international open standard, with over a decade of stable iteration in the office environment, offering advantages such as long-term readability and vendor independence. Embedding BIM into a mature archiving standard is a fundamental requirement for digital engineering archiving, an effect that cannot be achieved through simple custom ZIP sub-packages.

[0056] Secondly, existing IFC plain text and RVT proprietary single-file architectures cannot simultaneously meet the four major requirements of lightweight design, incremental updates, cross-platform compatibility, and on-demand loading. This application decouples and layers attribute data, metadata, geometric data, material data, and project attachments, and combines this with engineering semantic segmentation and standardized ODF indexes. Each step specifically addresses existing technical pain points. The increased process complexity brought by the layered architecture is traded for core performance improvements in model storage, transmission, collaboration, and archiving, demonstrating clear technical necessity and not constituting redundant functionalities. Furthermore, the additional development costs of the layered architecture correspond to multiple engineering benefits. For example, incremental updates eliminate the time required for full export and upload, improving the efficiency of multi-user collaboration; universal XML parsing eliminates the need to adapt to proprietary parsers in various BIM software; it complies with national standards for long-term preservation and open formats of electronic archives; and it can be parsed on Web, mobile devices, and various BIM software, enabling cross-platform and cross-software transmission without software binding.

[0057] Furthermore, existing general-purpose standalone XML can only achieve basic structured storage. If BIM data is stored using general-purpose XML independently, outside the ODF standard framework, the following unsolvable technical defects will occur: (1) The ODF standard framework has fully defined standardized ZIP containers, META-INF / manifest.xml indexes, metadata management, permission identification, version records, and archiving compatibility mechanisms. If general XML is used alone, a complete set of file directories, dependency indexes, metadata, and version management rules need to be designed from scratch, which greatly increases the complexity of the format and leads to the duplication of standards. This application only extends the BIM namespace on the basis of the original content.xml, and fully reuses the proven and mature storage, indexing, and archiving capabilities of ODF, which can significantly reduce the cost of self-built file specifications.

[0058] (2) The ODF native XML carries standard tags related to text layout and style rendering. This application defines a custom independent BIM-specific XML namespace (such as xmlns:bim="http: / / company.cn / bim-odf / schema / v1.0"). All components, attributes, spaces, and related elements belong to the independent namespace. The native layout tags are completely isolated from the BIM business tags. There are no issues of duplicate element names or parsing conflicts. At the same time, the legality of engineering data can be verified through the independent BIM Schema.

[0059] (3) In addition to component attributes, BIM projects also include drawings, thumbnails, survey attachments, and model configuration files. The ODF standard natively supports unified management of multiple types of resources such as XML, binary, images, and documents within a compressed package, enabling a single container to carry multiple types of data. If an independent and universal XML is used, geometric data, project attachments, and metadata will be scattered into independent files, losing the association between components, materials, and drawings, and failing to form a self-contained and independently archived complete project data package.

[0060] (4) There is no unified archiving standard for general custom XML, and parsing tools may be missing after many years. As an ISO international open standard, ODF is natively supported by mainstream office and archive systems around the world. Only the BIM parsing plugin needs to be extended to read BIM semantic data, which greatly reduces the risk of long-term data archiving and cross-platform reading. In other words, this application has stronger long-term archiving compatibility and relies on the ODF international standard to ensure readability.

[0061] (5) ODF natively divides content.xml, styles.xml, and meta.xml into one-to-one correspondences with BIM component attributes, material textures, and project metadata, without the need to redesign the general XML hierarchical structure; data mapping can be completed by simply adding BIM semantic tags, which is lower in development and parsing costs compared to designing a general XML hierarchical structure from scratch.

[0062] Furthermore, the BRP binary block file of this application can solve the inherent defects of existing general-purpose 3D exchange formats, without any unnecessary conversion burden, and at the same time, the accompanying lossless conversion mechanism ensures geometric accuracy and the integrity of component features, specifically reflected in the following five aspects: (1) Existing general 3D formats such as FBX, glTF, and 3DTiles are only for visual triangular face rendering, losing the IFC core Brep entity topology, component construction features, spatial boundaries, and parametric modeling information; IFCSTEP plain text is large in size and has low parsing efficiency. BRP is specifically adapted to BIM entity geometry, fully storing vertices, edges, loops, faces, shells, and entity topology levels, and retaining the original construction features of components such as walls, beams, and columns. General 3D formats cannot achieve this effect. (2) Existing software such as Revit, Bentley, and Tekla export geometric data structures that are incompatible with each other. If they are directly converted to each other, multiple one-to-one conversion interfaces need to be developed. BRP, as a unified intermediate geometric carrier, only requires the development of "geometric data structures for each software". The "brp" one-way converter enables the normalized storage of multi-source BIM data, reduces the development workload of many-to-many conversion, and lowers the overall conversion cost. That is, the brip binary block file of this application serves as an intermediate buffer layer to solve the differences in native geometric formats of multiple BIM software. (3) IFC supporting this application The BRP bidirectional lossless mapping rule is as follows: geometric floating-point values ​​are stored in 64-bit double precision to fully preserve the modeling coordinate accuracy; component parametric features, openings, chamfers, and cross-sectional contours are separately encoded and stored in the BRP header extension area, and fully restored during conversion; at the same time, a geometric check bit (CRC64) is set, and after conversion, the bounding box, vertex count, and topology of the original model are automatically compared, and precision loss is detected and a repair prompt is thrown, which can effectively solve the problems of precision and feature loss.

[0063] (4) Existing general exchange formats are mostly single-file whole geometry, which cannot be split; BRP stores independently by floor / component / space, supports independent replacement of single blocks and partial loading, and is the core carrier of incremental update and lightweight browsing in this application. If a general 3D format is used, the core functions of block storage and partial update will be lost, and the inefficiency of full file reading and writing in existing IFC and RVT will be returned.

[0064] (5) The BRP file in this application is not an external delivery exchange format, but only exists within the BIM-ODF compressed package; when exchanging data externally, the system can batch convert BIM-ODF into standard IFC4 / IFC5 universal exchange files, and external delivery is not restricted by the custom BRP format, and does not affect cross-software collaborative exchange. That is, the BRP file in this application is only used as an internal encapsulation medium for BIM-ODF, and still supports standard IFC export externally.

[0065] Furthermore, the incremental updates in this application do not involve directly overwriting files in situ using the native ZIP library. For example: First, decompress the target block to be modified to a temporary cache directory; second, modify the corresponding XML / brp file and calculate the new SHA256 hash and CRC32 checksum; then, read the original ODF file archive and copy all unchanged files to the temporary output package; next, write the modified files to the temporary output package and update the manifest.xml version, path, and verification information; finally, after all writing is complete, verify the overall integrity of the temporary package, and replace the original ODF file archive if the verification passes.

[0066] It should be noted that in the event of a power outage or program malfunction, the temporary package is automatically deleted, while the original files are preserved without modification, enabling transaction rollback. Furthermore, the above process does not involve directly overwriting files within the original ZIP archive (original ODF file archive), thus fundamentally avoiding issues such as central directory corruption and file damage caused by in-situ modifications to the standard ZIP library. In addition, ZIP is the standard carrier specified by the ODF international standard (ISO / IEC26300) and cannot be replaced by other compression formats such as 7z; each brp file and XML file contains an independent CRC32 checksum, and manifest.xml records the hash of all files; after the update, the integrity of all files is automatically verified; if partial damage occurs due to transmission or storage, the damaged data blocks can be repaired individually based on the manifest list without reconstructing the entire model package, providing superior fault tolerance compared to solid compression formats.

[0067] Based on the same inventive concept, this application also provides a building information model data storage device for implementing the building information model data storage method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more building information model data storage device embodiments provided below can be found in the limitations of the building information model data storage method described above, and will not be repeated here.

[0068] In one exemplary embodiment, such as Figure 4 As shown, a building information model (BIM) data storage device 500 is provided. The BIM data storage device 500 includes: a file acquisition module 501, a file classification module 502, a splitting generation module 503, a file generation module 504, a compression generation module 505, and a creation generation module 506. Specifically: The file acquisition module 501 acquires the model file drawn by the user. The file classification module 502 is used to classify model files according to preset rules to obtain data files of different categories; the categories of data files include non-geometric types and geometric types; The splitting generation module 503 is used to split geometric data files according to a preset structure and store each split independent data block as a corresponding geometric block brp file; The file generation module 504 is used to generate XML files with corresponding functions from non-geometric data files according to the ODF standard format. The compression generation module 505 is used to package and compress all geometric block BRP files, XML files with different functions, and related auxiliary resource files to generate an ODF file compressed package.

[0069] Compared to existing technologies, this implementation method offers several advantages. First, it employs a data classification and block storage approach, combined with ZIP compression, significantly reducing BIM file redundancy, effectively decreasing file size, and saving storage space and network transmission costs. Second, non-geometric data is built on a universal XML format, allowing for data reading using a mature universal parser, eliminating the need for customized parsing programs in traditional IFC formats and lowering the technical application threshold. Third, geometric data is split into independent data blocks according to a preset structure, supporting on-demand loading of model data and improving file access and retrieval efficiency. Fourth, the overall architecture adheres to the ODF international open standard, eliminating vendor-binding restrictions of proprietary formats such as RVT and DGN, providing excellent cross-platform and cross-software compatibility, and ensuring long-term accessibility and secure archiving of engineering data. Finally, a supporting index file uniformly manages the paths and relationships of all files, resulting in a clear data structure that provides strong support for subsequent partial model modifications and incremental updates, adapting to the storage and maintenance needs of BIM data in various engineering projects.

[0070] As an optional implementation, the file classification module 502 is specifically used to parse and split the model file's data across the entire domain according to preset rules, splitting the model file into geometric data, attribute data, material data, metadata, and component relationship data. Among them, geometric data is used to describe the model's shape, including the component's spatial coordinates, vertices, edges, faces, solids, shape contours, spatial position, and orientation; attribute data includes the component's non-geometric business information; material data includes the component's appearance information; metadata includes engineering document management information; and component relationship data includes the hierarchical subordinate relationship, spatial attachment relationship, assembly relationship, and binding relationship between components and their corresponding attributes and materials.

[0071] This implementation method involves parsing and splitting the model file's data across the entire domain. This allows for the differentiation of geometric data, attribute data, material data, metadata, and component relationship data, clarifying the storage content and application scenarios of each type of data and making the overall data architecture more standardized and orderly. Non-geometric data is generated into a general XML file, while geometric data is stored separately as BRP files. This categorized storage method effectively reduces text redundancy, and combined with compression encapsulation, significantly reduces file size, lowering storage and network transmission costs. Furthermore, the general XML format can be directly read using commercially available parsing tools, eliminating the need to develop dedicated parsing programs and lowering the technical implementation threshold. The block storage method for geometric data supports on-demand loading of local model data, improving data access efficiency. The clear data classification and block structure also provides a good foundation for local model modifications and incremental updates, meeting the storage, use, and maintenance needs of various building engineering BIM files throughout their entire lifecycle.

[0072] As an optional implementation, the file generation module 504 is specifically used to extract the structured attributes corresponding to the attribute data, material data, metadata, and component association data, and generate corresponding XML files according to the ODF standard format; wherein, the attribute data generation is used to store the basic information of the model in content.xml; the material data generation is used to store the model style information in styles.xml; the metadata generation is used to store the document information in meta.xml; and the component association data generation is used to store the model association configuration in settings.xml.

[0073] This implementation method allows for data storage based on data categories, facilitating later retrieval, management, and maintenance. Furthermore, it utilizes a universal XML format, enabling data reading and retrieval through mature industry parsing technology. This completely resolves the issues of complex syntax and the need for dedicated parsers in traditional IFC formats, significantly reducing the cost of technology application and secondary development.

[0074] As an optional implementation, the compression generation module 505 is specifically used to collect, sort, and archive XML files with different attributes, all geometric block BRP files, and related auxiliary resource files according to the standard directory structure and encapsulation specifications of the ODF international open document format, and to perform packaging compression using the ZIP compression algorithm to generate an ODF file compressed package.

[0075] This implementation method follows the ODF international standard for file archiving and packaging. Various types of files are stored in fixed directories, resulting in a neat file layout and convenient management. The ZIP compression algorithm is used to uniformly package all files, effectively reducing the overall file size and lowering storage space usage and network transmission pressure. The standardized directory structure and packaging method ensure uniform and standardized file formats, further enhancing cross-platform and cross-software compatibility. Combined with the classified and block-based storage logic, this makes the deployment, circulation, and maintenance of BIM files more efficient.

[0076] As an optional implementation, the aforementioned building information model data storage device 500 further includes an update detection module. This module is used to: detect modifications made to the model files by the user; determine the XML and brp files to be updated based on the modifications; update the XML and brp files to obtain the current XML and brp files, while keeping other files in the ODF file archive unchanged; update the version information and modification time in the index file based on the current XML and brp files to obtain the current index file; and generate the current ODF file archive or directly replace the corresponding files within the ODF file archive based on the current XML, brp, and index files.

[0077] This implementation method, by locating user-side modifications, updates only the changed XML and BRP files, eliminating the need to reconstruct the entire ODF file archive. This significantly reduces the computational load and time required for data updates, greatly improving the efficiency of model modification and file maintenance. During the update process, other unmodified files within the ODF file archive remain unchanged, effectively ensuring overall file stability and data integrity. Simultaneously, by synchronously updating the version information and modification time in the manifest.xml index file, precise file version management and traceability are achieved. Furthermore, by directly replacing corresponding files within the archive, the update process is further simplified, storage resource consumption is reduced, and the editing, maintenance, and iteration of BIM model files become more efficient and convenient, significantly enhancing the flexibility and practicality of file use.

[0078] As an optional implementation, the aforementioned building information model data storage device 500 further includes a conversion and encapsulation module. This module is used to: parse the acquired IFC file according to the mapping rules between the IFC data model and the ODF data model to obtain a parsed IFC file; extract the geometric data, attribute data, material data, metadata, and component relationship data from the parsed IFC file, and split the geometric data to generate corresponding independent data blocks in BRP files; convert the attribute data, material data, metadata, and component relationship data according to the ODF standard format to generate XML files with different functions; and generate an ODF file compressed package based on all BRP files, XML files with different functions, and related auxiliary resource files.

[0079] This implementation method, by setting standardized mapping rules between the IFC data model and the ODF data model, can completely parse all the data in the IFC file and complete the format migration using a unified data splitting, format conversion, and file generation logic. This method achieves seamless compatibility between the mainstream IFC format and the BIM-ODF format, and can directly convert existing IFC engineering data without repeated modeling processing, effectively expanding the scope of application and industry adaptability of this application. In addition, the converted files continue the advantages of block storage and classified archiving, fundamentally solving the problems of large file size, complex parsing, and inconvenient updating of traditional IFC files.

[0080] 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, this 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 computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores building information modeling (BIM) data. The I / O interfaces allow the processor to exchange information with external devices. The communication interface allows communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for storing BIM data.

[0081] Those skilled in the art will understand that 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 the relevant data must comply with relevant regulations.

[0086] 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. When executed, the computer program 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).

[0087] 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.

[0088] 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.

[0089] 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 storing Building Information Modeling (BIM) data, characterized in that, The method for storing the building information model data includes: Obtain the model file drawn by the user; The model files are classified according to preset rules to obtain data files of different categories; the categories of the data files include non-geometric types and geometric types. Geometric data files are split according to a preset structure, and each independent data block is stored as a corresponding geometric block brp file. Generate corresponding XML files for non-geometric data files according to the ODF standard format; All geometric block BRP files, XML files with different functions, and related auxiliary resource files are packaged and compressed to generate an ODF file archive. The method further includes: parsing the obtained IFC file according to the mapping rules between the IFC data model and the ODF data model to obtain a parsed IFC file; Extract and parse the geometric data, attribute data, material data, metadata, and component relationship data from the IFC file, and split the geometric data to generate corresponding independent data blocks in BRP files; convert the attribute data, material data, metadata, and component relationship data according to the ODF standard format to generate XML files with different functions; An ODF file compressed package is generated based on all BRP files, XML files with different functions, and related auxiliary resource files. The mapping rules between the IFC data model and the ODF data model include: geometric data mapping rules, attribute data mapping rules, material data mapping rules, metadata mapping rules, and component association relationship mapping rules. The geometric data mapping rule is as follows: extract all geometric entity data from the IFC file, including shape, coordinates, facets, and orientation; cut all geometric entity data into independent geometric blocks according to a preset splitting structure; the geometric blocks are not written into XML text, but are uniformly encoded and stored separately as .brp binary block files; record the unique ID, floor to which each brp file belongs, and the corresponding component GlobalId in the index manifest.xml; The attribute data mapping rule is as follows: extract the component entity business parameters from the IFC file. The business parameters include built-in direct attributes, IfcPropertySet parameter set, quantity, strength grade, and size specifications; fill all the component entity business parameters into the ODF standard content.xml main content node in a structured manner; use the ODF standard namespace, extend the BIM business tags, and use the component GlobalId as the unique associated primary key. The material data mapping rule is as follows: extract the appearance parameters from the IFC file, which include color, texture map, transparency, rendering thickness, and material type; write the appearance parameters into the style definition node of the ODF style document styles.xml; the component references the corresponding material style in styles.xml through the style-name attribute, which is consistent with the native ODF style reference logic; The metadata mapping rules are as follows: extract the project management information from the IFC file, which includes project information, creation or modification records, modelers, project name, version, unit baseline, and coordinate origin; fully match and fill the project management information into the ODF standard meta.xml meta information node, reuse the ODF native author, time, and project tag fields; and supplement the extended management fields of conversion log and IFC source file path. The component association mapping rule is as follows: extract the associated entities from the IFC file, which include: floor-component subordination, spatial attachment, component assembly, and component binding to materials or attributes; map the hierarchical subordination, spatial affiliation, assembly pairing, component binding to BRP file, and component binding to material style of the associated entities to the settings.xml configuration node; establish a two-way index mapping table between component GlobalId and BRP file name, and between component GlobalId and style name in settings.xml.

2. The method for storing building information model data according to claim 1, characterized in that, The process of classifying the model files according to preset rules to obtain data files of different categories includes: The model file is parsed and split according to preset rules, dividing it into geometric data, attribute data, material data, metadata, and component relationship data. The geometric data describes the model's shape, including the component's spatial coordinates, vertices, edges, faces, solids, shape outline, spatial position, and orientation. The attribute data includes non-geometric business information of the components. The material data includes the component's appearance information. The metadata includes engineering document management information. The component relationship data includes the hierarchical relationships, spatial dependencies, assembly relationships between components, and the binding relationships between components and their corresponding attributes and materials.

3. The method for storing building information model data according to claim 2, characterized in that, The process of generating corresponding XML files for non-geometric data files according to the ODF standard format includes: The structured attributes corresponding to the attribute data, material data, metadata, and component association data are extracted respectively, and corresponding XML files are generated according to the ODF standard format. Among them, the attribute data generates content.xml for storing basic model information; the material data generates styles.xml for storing model style information; the metadata generates meta.xml for storing document information; and the component association data generates settings.xml for storing model association configuration.

4. The method for storing building information model data according to claim 3, characterized in that, The process of packaging and compressing all geometric block BRP files, XML files with different functions, and related auxiliary resource files to generate an ODF file archive includes: Following the standard directory structure and encapsulation specifications of the ODF international open document format, XML files with different attributes, all geometric block BRP files, and related auxiliary resource files are collected, sorted, and archived. The ZIP compression algorithm is then used to compress and package the files to generate the ODF file compressed package.

5. The method for storing building information model data according to claim 4, characterized in that, The method further includes: Detect user-side modifications to the model file, and determine the XML and brp files to be updated based on the modifications. Update the XML and brp files to be updated to obtain the current XML and brp files, while keeping other files in the ODF archive unchanged; Based on the current XML file and the current brp file, update the version information and modification time in the index file to obtain the current index file; Based on the current XML file, the current brp file, and the current index file, generate a current ODF file archive or directly replace the corresponding file within the ODF file archive.

6. A storage device for building information model data, characterized in that, The storage device for the building information model data includes: The file acquisition module retrieves the model files drawn by the user. The file classification module is used to classify the model files according to preset rules to obtain data files of different categories; the categories of the data files include non-geometric types and geometric types; The splitting and generation module is used to split geometric data files according to a preset structure and store each split independent data block as a corresponding geometric block brp file; The file generation module is used to generate XML files with corresponding functions from non-geometric data files according to the ODF standard format. The compression generation module is used to package and compress all geometric block BRP files, XML files with different functions, and related auxiliary resource files to generate an ODF file archive. The conversion and encapsulation module is used to parse the obtained IFC file according to the mapping rules between the IFC data model and the ODF data model to obtain a parsed IFC file; extract the geometric data, attribute data, material data, metadata, and component relationship data from the parsed IFC file, and split the geometric data to generate corresponding independent data blocks in BRP files; convert the attribute data, material data, metadata, and component relationship data according to the ODF standard format to generate XML files with different functions; and generate an ODF file compressed package based on all BRP files, XML files with different functions, and related auxiliary resource files. The mapping rules between the IFC data model and the ODF data model include: geometric data mapping rules, attribute data mapping rules, material data mapping rules, metadata mapping rules, and component association relationship mapping rules. The geometric data mapping rule is as follows: extract all geometric entity data from the IFC file, including shape, coordinates, facets, and orientation; cut all geometric entity data into independent geometric blocks according to a preset splitting structure; the geometric blocks are not written into XML text, but are uniformly encoded and stored separately as .brp binary block files; record the unique ID, floor to which each brp file belongs, and the corresponding component GlobalId in the index manifest.xml; The attribute data mapping rule is as follows: extract the component entity business parameters from the IFC file. The business parameters include built-in direct attributes, IfcPropertySet parameter set, quantity, strength grade, and size specifications; fill all the component entity business parameters into the ODF standard content.xml main content node in a structured manner; use the ODF standard namespace, extend the BIM business tags, and use the component GlobalId as the unique associated primary key. The material data mapping rule is as follows: extract the appearance parameters from the IFC file, which include color, texture map, transparency, rendering thickness, and material type; write the appearance parameters into the style definition node of the ODF style document styles.xml; the component references the corresponding material style in styles.xml through the style-name attribute, which is consistent with the native ODF style reference logic; The metadata mapping rules are as follows: extract the project management information from the IFC file, which includes project information, creation or modification records, modelers, project name, version, unit baseline, and coordinate origin; fully match and fill the project management information into the ODF standard meta.xml meta information node, reuse the ODF native author, time, and project tag fields; and supplement the extended management fields of conversion log and IFC source file path. The component association mapping rule is as follows: extract the associated entities from the IFC file, which include: floor-component subordination, spatial attachment, component assembly, and component binding to materials or attributes; map the hierarchical subordination, spatial affiliation, assembly pairing, component binding to BRP file, and component binding to material style of the associated entities to the settings.xml configuration node; establish a two-way index mapping table between component GlobalId and BRP file name, and between component GlobalId and style name in settings.xml.

7. 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 steps of the method for storing building information model data according to any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for storing building information model data as described in any one of claims 1-5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for storing building information model data as described in any one of claims 1-5.

Images