Retrieval-oriented BIM lightweight model attribute index table construction method and system

Abstract

The invention discloses a retrieval-oriented BIM lightweight model attribute index table construction method and a retrieval-oriented BIM lightweight model attribute index table construction system. The method comprises the following steps: firstly, extracting a component attribute metadata set with a four-layer logic structure in a BIM lightweight model through an analyzer; then, generating an attribute index table with a flattened structure based on the set, and presetting a database index on a key field of the attribute index table; and finally, converting the component attribute metadata records in the component attribute metadata set into target standardized records in batches through a concurrent processing engine, and writing the target standardized records into an attribute index table. Based on the filled attribute index table, an attribute query request from a lightweight terminal can be efficiently responded, and on-demand and dynamic engineering quantity statistics and report generation are realized. According to the method, complex multi-table associated storage of the attribute data is reconstructed into an atomized and flattened attribute index table, so that the technical bottlenecks of slow attribute retrieval and difficult engineering quantity statistics caused by a complex storage architecture of a traditional BIM lightweight model are fundamentally solved.

Description

Technical Field

[0001] This invention belongs to the field of Building Information Modeling (BIM) and database information processing, and specifically relates to a method and system for constructing a retrieval-oriented lightweight BIM model attribute index table. This invention also relates to electronic devices and storage media for implementing the above method. Background Technology

[0002] In the field of engineering digitization, lightweight processing of Building Information Modeling (BIM) is a key technology for enabling the efficient application of models on lightweight terminals such as web browsers and mobile devices. Existing technologies typically use dedicated conversion tools (such as Bimface and iTwin) to convert large BIM models into lightweight models based on databases (such as SQLite), significantly reducing the model size while preserving the original geometric and non-geometric information to meet the performance requirements of lightweight terminals.

[0003] Existing lightweight BIM models employ a multi-layered, indirectly related heterogeneous storage architecture. While this architecture aims to provide flexibility, it fundamentally sacrifices query performance. The root cause is its design paradigm of separating business identifiers from physical storage. The meaning of attribute values ​​and their storage location are forcibly decoupled and connected through complex mapping relationships. Although this design supports flexible expansion of the storage model, its inherent cost is that every attribute query must recalculate and parse this complete mapping chain at runtime through multi-table join operations. This design, which embeds computational complexity into the data structure, inevitably leads to low real-time query efficiency at the architectural level. This is mainly reflected in the following two aspects:

[0004] 1. Poor Attribute Retrieval Performance: To maintain flexibility, existing lightweight BIM models often employ a sparse storage structure with dynamic tables and columns to manage massive amounts of attribute data. This structure leads to complex join queries and dynamic parsing across multiple data tables for retrieval operations targeting specific attributes (such as "concrete strength grade"), resulting in high time complexity. When dealing with models containing hundreds of thousands or even millions of components, the response latency is significant, failing to meet the second-level response requirements of interactive applications.

[0005] 2. Limited Quantity Statistics Functionality: Accurate quantity statistics (such as calculating the total volume of specific types of components) heavily rely on efficient and flexible retrieval and aggregation capabilities for attribute data. Due to the performance bottlenecks in attribute retrieval mentioned above, on-demand, real-time quantity statistics become extremely difficult, or even impossible, in large-scale model environments. Engineers can only rely on pre-exported, fixed reports, unable to flexibly perform real-time statistics based on dynamically changing filtering conditions, severely impacting the efficiency of project decision-making and management.

[0006] To address the above issues, current industry optimization methods often involve optimizing query statements at the application layer or introducing external caching. These solutions are all localized optimizations that only treat the symptoms and not the root cause.

[0007] Query optimization: It cannot change the fact that multiple tables need to be joined at the underlying level, so it has limited improvement for massive amounts of data.

[0008] External caching requires maintaining an additional system, increasing architectural complexity and consistency maintenance costs, and makes it difficult to cache flexible and varied combined query results.

[0009] None of these solutions address the performance issues stemming from the inherent "dynamic mapping-distributed storage" architecture of lightweight BIM models. Therefore, the field has long lacked an innovative technological solution capable of fundamentally reconstructing efficient attribute access paths by restructuring the data organization model.

[0010] The purpose of this invention is to fundamentally solve this long-standing technical problem in the industry and achieve efficient retrieval and real-time statistics of massive attribute data. Summary of the Invention

[0011] To overcome the two major technical problems of slow attribute retrieval speed and inability to perform real-time quantity surveying in existing lightweight BIM models on lightweight terminals such as web and mobile devices due to the complex attribute data storage structure, this invention proposes a retrieval-oriented method and system for constructing an attribute index table for lightweight BIM models. This invention achieves second-level retrieval response for attribute information and provides quantity surveying functionality by reconstructing the organization and management of attribute data.

[0012] Therefore, the first objective of this invention is to provide a method for constructing a retrieval-oriented lightweight BIM model attribute index table, which includes the following steps: The component attribute metadata set in the BIM lightweight model is extracted by the parser, and the component attribute metadata set includes at least one component attribute metadata record. Based on the aforementioned component attribute metadata set, define and create an attribute index table with a flat structure; The concurrent processing engine converts the component attribute metadata records in the component attribute metadata set into target normalized records and writes them in batches into the attribute index table.

[0013] Preferably, the step of defining and creating an attribute index table with a flat structure based on the component attribute metadata set includes: Create an attribute index table, whose core fields include at least the globally unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute. Each record in the attribute index table includes only a single attribute. Create a database index on the key query fields of the attribute index table. The key query fields include at least the globally unique identifier of the component, the logical name of the attribute category, and the logical name of the attribute.

[0014] Preferably, the step of converting the component attribute metadata records in the component attribute metadata set into target normalized records and batch writing them into the attribute index table through a concurrent processing engine includes: Multiple concurrent processing threads are started, and the component attribute metadata set is divided into subsets and distributed to each thread for parallel processing; Within each concurrent processing thread, the original attribute values ​​are extracted based on the storage location information in the component attribute metadata record. The original attribute values ​​are then combined with the component attribute metadata record to generate an initial normalized record, which is further converted into a target normalized record that conforms to the attribute index table structure. The generated target normalized records are written to the attribute index table through a batch database write operation.

[0015] Preferably, after converting the component attribute metadata records in the component attribute metadata set into target normalized records and batch writing them into the attribute index table using a concurrent processing engine, the method further includes: Based on the populated attribute index table, respond to attribute query requests from the lightweight terminal; Alternatively, based on the already populated attribute index table, respond to the quantity statistics request and generate a statistical report.

[0016] The second objective of this invention is to provide a retrieval-oriented lightweight BIM model attribute index table construction system, which includes: The metadata parsing module is used to extract the component attribute metadata set in the BIM lightweight model through a parser. The component attribute metadata set includes at least one component attribute metadata record. The attribute index table construction module is used to generate an attribute index table based on the component attribute metadata set; A concurrent processing engine is used to convert component attribute metadata records in the component attribute metadata set into target normalized records and write them in batches into the attribute index table.

[0017] Preferably, the system also includes: The query interface module is used to respond to attribute query requests from the lightweight terminal based on the populated attribute index table. Alternatively, a statistics reporting module may be used to respond to a quantity statistics request and generate a statistics report based on the populated attribute index table.

[0018] Preferably, the attribute index table construction module includes: The table structure definition submodule is used to create an attribute index table with a flat structure based on the component attribute metadata set. Its core fields include at least the global unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute. The index pre-setting submodule is used to create a database index on the key query fields of the attribute index table. The key query fields include at least the globally unique identifier of the component, the logical name of the attribute category, and the logical name of the attribute.

[0019] Preferably, the concurrent processing engine includes: The task scheduling submodule is used to start multiple concurrent processing threads and divide the component attribute metadata set into subsets and allocate them to each thread for parallel processing. The data conversion submodule is used to extract the original attribute values ​​according to the storage location information in the component attribute metadata record within each concurrent processing thread, combine the original attribute values ​​with the component attribute metadata record to generate an initial normalized record, and further convert it into a target normalized record that conforms to the attribute index table structure. The batch write submodule writes the generated target normalized records into the attribute index table through a batch database write operation.

[0020] A third objective of this invention is to provide an electronic device comprising: Memory, used to store computer programs; A processor is used to execute a program stored in memory to implement any of the steps of the above-mentioned method for constructing a retrieval-oriented lightweight BIM model attribute index table.

[0021] The fourth objective of this invention is to provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of any of the above-mentioned methods for constructing a retrieval-oriented lightweight BIM model attribute index table.

[0022] The beneficial effects of this invention are as follows:

[0023] 1. Achieved an order-of-magnitude improvement in attribute retrieval performance: By constructing a flat attribute index table, the organization of attribute data was reconstructed from the complex, multi-table-associations, discrete state in the original model to a unified, flat, centralized state. This transformed the attribute retrieval operation from a high-time-complexity operation requiring multiple table joins and dynamic parsing to a low-complexity operation of a single index scan of a single attribute index table. This completely avoided full model traversal, achieving second-level attribute retrieval response in a million-component model and resolving the core performance bottleneck of lightweight terminal interaction.

[0024] 2. Achieved on-demand and accurate quantity surveying capabilities: The invention, based on an efficient attribute index table, establishes a direct and efficient mapping relationship between attribute values ​​and quantity calculations. Users can quickly and flexibly perform aggregated quantity calculations (such as summation, counting, and averaging) based on arbitrary and dynamically changing filter conditions (such as component type, material, spatial location, etc.), and generate complete and accurate statistical reports. This changes the traditional model that relies on fixed, pre-generated reports, enabling quantity data to reflect the latest state of the model in real time and accurately, providing strong data support for project management and decision-making.

[0025] 3. Reduced overall system complexity and deployment cost: This invention achieves performance optimization by directly building and applying attribute index tables in the embedded database, simplifying the system architecture, reducing operational complexity, and providing a more cost-effective and easier-to-integrate and deploy solution. Attached Figure Description

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

[0027] Figure 1 This is a flowchart illustrating a method for constructing a retrieval-oriented lightweight BIM model attribute index table according to the present invention.

[0028] Figure 2 This is a schematic diagram of the lightweight model structure and data relationships upon which embodiments of the present invention depend.

[0029] Figure 3 This is a schematic diagram of the structural design of the attribute index table constructed in an embodiment of the present invention;

[0030] Figure 4 This is an example of a statistical report on the quantity of masonry work derived in an embodiment of the present invention.

[0031] The accompanying drawings have illustrated specific embodiments of the invention, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the invention in any way, but rather to illustrate the concept of the invention to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0032] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without inventive effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0033] Lightweight model

[0034] This refers to a complete set of information suitable for lightweight terminals, generated after converting and optimizing the original full-element BIM model using specialized tools. It uses a database as its carrier and, while ensuring information integrity, includes all geometric and non-geometric data of the model. Geometric data refers to the visible information constituting the model's two-dimensional and three-dimensional shapes; non-geometric data covers the model's materials, component names, attributes, and industry information. In this invention, the lightweight model is the overall object being processed, and the core of this invention lies in reconstructing the organization and access methods of its internal non-geometric data by constructing an attribute index table, thereby solving the global retrieval and statistical performance bottleneck.

[0035] member

[0036] The components constitute the basic information carriers and functional units with clear engineering semantics that make up the lightweight model. A component is not only a geometric entity in space, but also a digital object integrating geometric information (such as the component's physical form, size, location, and shape in three-dimensional space) and non-geometric attributes (such as material, model, and cost), representing an identifiable and manageable part of a construction project (such as a wall or a window). In this invention, the component is the logical ownership and organizational core of attribute information, and a key level connecting the macro-model and micro-attributes. The attribute index table is precisely the technical implementation of efficiently managing the attributes of components as basic units.

[0037] SQLite

[0038] A lightweight, embedded relational database management system (RDBMS). Its core feature is that the entire database is stored as a single disk file, eliminating the need for a separate server process, making it particularly suitable for embedded devices and localized application scenarios.

[0039] Work volume

[0040] This refers to the quantity of various items or components in a construction project, expressed in physical or natural units of measurement. Physical units of measurement are based on the physical properties of the object (such as "square meters" or "meters"), while natural units of measurement are based on the object's inherent natural properties (such as "pieces" or "sets").

[0041] parser

[0042] This invention relates to a core functional component for extracting and processing component attribute metadata from a lightweight BIM model. It employs a layered architecture, including: a data storage layer responsible for persisting raw data; a data processing layer responsible for data extraction and transformation; and an application interface layer that provides unified data services to the outside world.

[0043] Dynamic column

[0044] This is a non-fixed-schema data storage design at the database level. Its core lies in breaking away from the traditional database table model where all columns (attributes) must be explicitly defined in advance. It allows for the dynamic creation of new physical columns based on the attributes of actual business objects during system operation, adapting to constantly changing or highly heterogeneous data storage needs. Specific technical features include:

[0045] Non-predefined and dynamically created columns: Unlike traditional database tables with a fixed number and names of predefined columns, dynamic column structures allow new data columns (column names such as js1, js2, js3... or os1, os2...) to be created dynamically during system runtime based on extensions defined by component attributes. These columns are not all present in the initial database table design.

[0046] Column names serve as identifiers of physical storage locations (attribute name stripping): The names of dynamic columns (e.g., js1) are neutral and lack business semantics. They only represent a physical storage location and do not directly indicate the business meaning of the stored data (e.g., "volume" or "material"). Separation of attribute meaning from column names and external mapping (decoupling of attribute value storage from attribute name interpretation): Specific business attribute names are stripped from the physical table structure and instead defined and managed in a separate component attribute metadata table. Therefore:

[0047] 1. The specific business meaning of the data value stored under the same physical column name (such as js1) is not determined by the column name itself.

[0048] 2. The business attribute names of these data values ​​are dynamically defined and associated entirely by the external component attribute metadata table or configuration. For example, for component A, the component attribute metadata may specify that column js1 stores the value of the "length" attribute; while for component B, the same column js1 may store the value of a completely different attribute, "strength".

[0049] Component attribute metadata record

[0050] Specifically, it refers to structured data used to define, describe, locate, and manage component attributes in a lightweight BIM model. It includes not only the semantic definition information of the attributes (such as logical names, display names, and units of measurement), but also their physical storage location information in the original model database (such as table names and column names). A complete component attribute metadata record constitutes a unique location and description instruction from a component instance to its specific attribute value.

[0051] Example 1

[0052] To better understand the idea behind the BIM lightweight model attribute index table construction method for retrieval in this invention, this embodiment takes the typical engineering problem of accurately calculating the quantity of masonry surface work in the decoration and finishing stage as an example: In the finishing stage of the project, construction and cost personnel need to quickly extract the area of ​​all wall plastering, finishing and other masonry surfaces from the model, and summarize them by room or material, so as to accurately calculate the amount and cost of decorative materials such as paint and bricks.

[0053] Traditional methods involve extremely low efficiency and frequent omissions in manual measurement and screening. Using the method of this invention, personnel can complete the area retrieval and classification statistics of all masonry surfaces in a building within seconds on a mobile terminal. The following section uses a specific masonry surface component (id: "wall_finish_room101_01") from a project as an example to detail the entire process of the method of this invention.

[0054] To clearly illustrate the hierarchical relationship involved in this invention, the following uses the masonry surface component (c_WallFinish) as an example to explain its attribute organization structure.

[0055] This invention provides a method for constructing a retrieval-oriented lightweight BIM model attribute index table, such as... Figure 1 As shown, it includes the following steps:

[0056] S1, extract the component attribute metadata set from the BIM lightweight model through the parser, the component attribute metadata set includes at least one component attribute metadata record.

[0057] To address the unique and complex multi-level dynamic storage structure of lightweight BIM models, the data storage structure is preprocessed. Based on the characteristics of the BIM model, the original data storage structure of the lightweight model is traversed and parsed. Then, based on this original data storage structure, the relationships between component attribute metadata within the BIM model are structurally parsed, establishing association mappings between data tables. Complete and standardized component attribute metadata is extracted from discrete data sources, ultimately forming a data table with four logical levels. Finally, a parser parses the data within these tables to generate a set of component attribute metadata. The data tables are as follows... Figure 2 As shown, it includes at least:

[0058] 1. First level: Component type definition layer.

[0059] The component type definition layer provides unique identifiers and logical definitions for all component types in the model, forming the logical foundation of the entire attribute management system. Each attribute must belong to a component type defined at this level.

[0060] In this embodiment of the invention, the aforementioned component type definition layer is implemented through a component type definition table (e.g., a data table named ec_Class). This table stores component attribute metadata for all component types, and it includes at least the following core fields: id: A globally unique identifier for the component type; name: The logical name of the component type within the system, used to identify the component within the program; displayLabel: The user-facing name of the component type, used for a user-friendly interface display.

[0061] Through the component type definition table, the system can establish the initial logical starting point for attribute retrieval, that is, determine which component type an attribute belongs to.

[0062] 2. Second level: Attribute semantic definition layer.

[0063] The attribute semantic definition layer is used to give each attribute a complete business semantic context, including its name, category, unit of measurement, and optional value range.

[0064] In this embodiment of the invention, the aforementioned attribute semantic definition layer is implemented collaboratively through an attribute definition table (e.g., named ec_property) and its associated auxiliary tables (e.g., category table ec_propertyCategory, enumeration table ec_enumeration, and unit of measurement table ec_KindOfQuantity).

[0065] 1) Core table: Attribute definition table (ec_property)

[0066] The attribute definition table serves as the hub for defining attribute semantics, recording the core component attribute metadata for each attribute and linking it to its component type and other auxiliary information. The core fields of the attribute definition table must include at least: id: A globally unique identifier for an attribute; classId: A foreign key field used to link to the id field in the first-level component type definition table (ec_Class), specifying which component type this attribute belongs to; name: The logical name of the attribute within the system, used to identify the attribute within the program; displayLabel: The name of the label displayed to the user, used for user-friendly interface display; kindOfQuantityId: A foreign key field that links to the unit of measurement table (ec_KindOfQuantity) and is used to classify attributes for business purposes; categoryId: A foreign key field that links to the category table (ec_propertyCategory) and provides a metric for numeric attributes; enumerationId: A foreign key field that is associated with the enumeration table (ec_enumeration) and defines the optional value range for attributes with preset options (such as "material type").

[0067] 2) Auxiliary table system

[0068] a) Category table (ec_propertyCategory)

[0069] The category table categorizes attributes according to business dimensions (such as "geometric attributes" and "material attributes"). The core fields of the category table must include at least: id: Serves as a globally unique identifier for a category; name: The logical name of the category, used to identify the category internally by the program; displayLabel: Category display name, used for user-friendly interface display;

[0070] b) Enumeration table (ec_enumeration)

[0071] An enumeration table defines a predefined set of possible values ​​for attributes, ensuring data standardization. The core fields of an enumeration table must include at least: id: A globally unique identifier used in the enumeration; name: The type name of the enumeration, used in the program's internal code; EnumValues: A list that stores the values ​​of a specific enumeration, for example, defining the values ​​of an enumeration as ["latex paint", "tile", "wallpaper"]).

[0072] c) Table of Units of Measurement (ec_KindOfQuantity)

[0073] The Units of Measurement table defines the units of measurement for attributes and manages the conversion between the original storage units and the display units, ensuring the accuracy of quantity statistics. The core fields of the Units of Measurement table must include at least: id: a globally unique identifier for a unit; persistenceUnit: The original storage unit of the value in the database, such as mm (millimeters); presentationUnits: Units used for user-facing displays, such as m (meter).

[0074] The attribute definition table (ec_property) is associated with the category table, unit of measurement table, and enumeration table through its foreign key fields (categoryId, kindOfQuantityId, enumerationId). When the system needs to obtain or process the complete semantics of an attribute, it can efficiently obtain its classification information, accurate unit conversion rules, and a list of valid possible values ​​through database join queries, thus providing an indispensable semantic foundation for subsequent accurate retrieval and conditional statistics.

[0075] Through the attribute semantic definition layer, the system defines the original attribute values, which might otherwise be just raw numbers (such as 128) or internal codes (such as "latex paint"), along with the business meaning of the raw numbers ("area") and the unit of measurement ("m"). 2 The data is closely linked to the business classification ("work quantity attribute"), realizing the transformation of attribute values ​​from meaningless data to information entities with engineering semantics. This transformation is the logical premise for subsequent intelligent retrieval, dynamic filtering, and accurate work quantity statistics.

[0076] 3. Third level: Dynamic storage mapping layer.

[0077] The dynamic storage mapping layer is used to establish a dynamic, configurable storage mapping relationship between attribute semantics (defined by the second level) and physical storage location (defined by the fourth level).

[0078] In this embodiment of the invention, the storage mapping relationship is implemented through a set of interrelated mapping management tables.

[0079] 1) Core mapping table: Property mapping table (ec_propertyMap)

[0080] As the core connector of the entire mapping layer, the attribute mapping table defines a specific "attribute-storage location" binding relationship for each record. The core fields of the attribute mapping table include at least: id: A globally unique identifier used for mapping relationships; classId: A foreign key field that points to the id field in the first-level component type definition table (ec_Class), indicating which component type this mapping relationship applies to; propertyPathId: A foreign key field that points to the id field of the property path table (ec_propertyPath). This path is ultimately associated with a specific property definition at the second level, thus identifying which property is mapped. columnId: A foreign key field that points to the id field of the dynamic column management table (ec_column). This column is associated with a specific physical storage table and column name, thus identifying which physical column the attribute value is stored in.

[0081] 2) Support Table System

[0082] To achieve the above dynamic mapping, the system relies on the following support table to define the endpoint information of the mapping:

[0083] a) Dynamic table management table (ec_table)

[0084] The dynamic table management table is used to define component attribute metadata that can be used to store attribute values ​​in the physical table. The physical table specifically refers to the database table in the fourth level that actually stores the attribute values ​​of component instances, namely the attribute value dynamic table (bis_GeometricElement3d) and the extended attribute value dynamic table (bis_GeometricElement3d_Overflow). Its core fields include at least: id: A globally unique identifier defined in the physical table; name: The actual name of the physical table in the database (e.g., "bis_GeometricElement3d"); classId: A foreign key field that points to which component type the physical table primarily serves.

[0085] b) Dynamic column management table (ec_column)

[0086] The dynamic column management table is used to define component attribute metadata for columns in a specific dynamic table. The specific dynamic table refers specifically to a data table with a dynamic column structure in the fourth level, used to actually store the attribute values ​​of component instances. In this embodiment of the invention, it specifically refers to an attribute value dynamic table (bis_GeometricElement3d) and an extended attribute value dynamic table (bis_GeometricElement3d_Overflow). Each record in the dynamic column management table defines a specific physical column in its associated specific dynamic table. Its core fields include at least: id: A globally unique identifier defined as a dynamic column; tableId: A foreign key field that points to the id field of the dynamic table management table (ec_table), indicating which physical table this column belongs to; `name`: The actual name of this column in the physical table. For example, if it's a dynamic column in a dynamic table of attribute values ​​(bis_GeometricElement3d), the actual name of the dynamic column is `js1`, `js2`, `js3`, `js4`, `js5`, ...; if it's a dynamic column in an extended dynamic table of attribute values ​​(bis_GeometricElement3d_Overflow), the actual name of the dynamic column is `os1`, `os2`, `os3`, `os4`, `os5`, .... The actual name of the dynamic column is dynamic, composed of letters and numbers, and is unrelated to business semantics. Furthermore, the letters after `js` increment by 1 in increments of 1.

[0087] c) Property path table (ec_propertyPath)

[0088] The attribute path table is used to transform second-level attribute definitions into an abstract path that can be referenced by the mapping layer. Its core fields include at least: id: A globally unique identifier used for attribute paths; `classId`: A foreign key field that points to the primary key `id` field of the first-level component type definition table (`ec_Class`). This association establishes which component type this attribute path belongs to, ensuring type safety in the mapping relationship. accessString: A string whose content corresponds to the name field in the second-level attribute definition table (ec_property), serving as a key string bridge connecting attribute semantics and storage mapping.

[0089] d) Component-table association tables (ec_cache_ClassHasTables)

[0090] The component-table association table serves as a query cache, used internally to quickly determine which physical table the attribute data of a specific component type is actually stored in. By directly querying the pre-stored mapping relationships in this table, complex multi-level associations can be calculated in real time every time data needs to be located, thus providing upper-layer applications with a fast indexing service from component type to physical storage location.

[0091] The dynamic storage table refers to the physical table defined by the `ec_table` table in the third level and the table that actually stores the data in the fourth level, specifically the attribute value dynamic table (bis_GeometricElement3d) and the extended attribute value dynamic table (bis_GeometricElement3d_Overflow). Its core fields include at least: id: A globally unique identifier for a record; `classId`: A foreign key field that points to the primary key `id` field in the first-level component type definition table (`ec_Class`). This association specifies the component type.

[0092] `tableId`: A foreign key field. This association is obtained by querying the dynamic table management table (ec_table) to get the name of the dynamic table (bis_GeometricElement3d) or the dynamic table (bis_GeometricElement3d_Overflow) that actually stores the attribute values ​​of this component type. That is, the value of the `name` field in the dynamic table management table (ec_table). For example, the table name obtained is "bis_GeometricElement3d".

[0093] The dynamic storage mapping layer decouples the attribute storage logic from the physical storage structure through the aforementioned set of mapping management tables, thereby supporting the flexible expansion of the attribute data model.

[0094] 4. Fourth level: Instance data storage layer.

[0095] The instance data storage layer is used to store the actual values ​​of the attributes of each specific component element, and is the physical storage endpoint of the entire attribute data system.

[0096] In this embodiment of the invention, the above-mentioned instance data storage is implemented through an element instance table and its associated attribute value dynamic table.

[0097] 1) Core table: Element instance table (bis_element)

[0098] The element instance table serves as a bridge connecting logical component types and physical attribute values, recording the existence of each specific component instance in the model. Its core fields include at least: id: A globally unique identifier for a specific component instance (element); ECClassId: A foreign key field that points to the id field in the first-level component type definition table (ec_Class), explicitly identifying which component type the element instance belongs to.

[0099] 2) Dynamic table of attribute values ​​(bis_GeometricElement3d) and extended dynamic table of attribute values ​​(bis_GeometricElement3d_Overflow)

[0100] This set of tables is the physical container that actually stores the original values ​​of all component instance attributes. It uses a dynamic column structure (such as js1, js2, etc.), allowing the database table to adapt to flexible expansion of model attributes without needing to predefine all attribute columns. Its core fields include at least: elementId: A foreign key field that points to the id field in the element instance table (bis_element), identifying which specific element's attribute value is stored in this row; ECClassId: Component type identifier, redundantly stored with the element instance table to optimize some queries; [Dynamic Columns]: If a dynamic column belongs to an attribute value dynamic table (bis_GeometricElement3d), the actual name of the dynamic column is js1, js2, js3, js4, js5, ...; if a dynamic column belongs to an extended attribute value dynamic table (bis_GeometricElement3d_Overflow), the actual name of the dynamic column is os1, os2, os3, os4, os5, ...). These column names have no fixed business meaning; their specific meaning is determined by the mapping relationship of the third level (dynamic storage mapping layer). Each column stores one attribute value (e.g., 128, "latex paint"). The actual name of the dynamic column is dynamic, composed of letters and numbers, and is unrelated to business semantics. Furthermore, the letters after js increase in increments of 1, starting from 1.

[0101] The attribute value dynamic table adopts a separate design of the main table attribute value dynamic table (bis_GeometricElement3d) and the overflow table extended attribute value dynamic table (bis_GeometricElement3d_Overflow). When a single element has too many attributes or the data volume is too large, the system automatically stores some data in the overflow table. This design is a horizontal partitioning method used to prevent the data expansion of a single table from affecting performance.

[0102] A specific attribute value is stored at this level, but the complete semantics of that attribute value (what attribute it is) depends on the definition at the second level. The exact physical location of the attribute value (which table and column it is in) is dynamically specified by the mapping relationship at the third level. For example, the "area" value of the element "wall_finish_room101_01" is 128, and it is stored in column js5 of the attribute value dynamic table (bis_GeometricElement3d) determined by the third-level mapping.

[0103] The fourth level carries the final attribute data entity. The semantic definition of the fourth level is closely integrated with the second level and the dynamic mapping of the third level, forming a meaningful attribute management system.

[0104] In this embodiment, taking a specific instance of a masonry surface component (id: "wall_finish_room101_01") as an example, we can illustrate how the parser extracts complete component attribute metadata by traversing the four levels in reverse.

[0105] To clearly demonstrate the hierarchical relationships and key field mappings in the BIM lightweight model processed by this invention, the attribute organization structure and corresponding fields of the masonry surface components are explained. The structure is as follows: [Level 1: Component Type Definition] ├Component type: Masonry surface (Logical identifier: ec_class_id = "c_WallFinish", Display name: displayLabel = "Masonry surface") ├[Level 2 and Level 3: Component instances and their attribute organization using masonry surfaces as an example] Component example: wall_finish_room101_01 (element_id="wall_finish_room101_01", ec_class_id="c_WallFinish") ├── [Attribute Category] Geometric Attributes (category_name = "Finishes", category_label = "Geometric Attributes") │ └── [Attribute] Area(name="Area", label="Area", presentation_units="m²") └── [Attribute Category] Material Attributes (category_name = "Material", category_label = "Material Properties") └── [Attribute] Finish Material (name="FinishMaterial", display name: label="Finish Material")

[0106] The parsing process is as follows:

[0107] 1. Locate the types and examples of masonry surface components (traverse the starting points of the first and fourth levels).

[0108] From the first level: Component type definition table (ec_Class), locate the component type to which the masonry surface component belongs and obtain its logical identifier: (id: "c_WallFinish", name: "WallFinish", displayLabel: "Masonry Surface").

[0109] From the fourth level: the element instance table (bis_element), locate the specific instance of the masonry surface component and confirm its type: (id: "wall_finish_room101_01", ECClassId: "c_WallFinish").

[0110] 2. Parse the semantic definition of the attribute (traverse the second level).

[0111] Based on the masonry surface component type identifier "c_WallFinish", in the second level: attribute definition table (ec_property), its defined geometric attributes are found, and its semantic core is obtained: (name: "Area", displayLabel: "Area", kindOfQuantityId: "k_area").

[0112] By querying the unit of measurement table (ec_KindOfQuantity) using kindOfQuantityId, the unit information is obtained: (id: "k_area", presentationUnits: "m 2 ")`.

[0113] At the same time, the surface material attribute of the masonry surface component was parsed: (name: "FinishMaterial", displayLabel: "Surface Material", enumerationId: "e_material"), and the possible values ​​of the surface material were found to be ["Latex Paint", "Tile", "Wallpaper"] through the enumeration table (ec_enumeration).

[0114] 3. Parse the dynamic storage mapping (traverse the third level).

[0115] By querying the component-table association table (ec_cache_ClassHasTables), the dynamic table identifier "tableId" associated with the type "c_WallFinish" of the masonry surface component is obtained. Then, by querying the dynamic table management table (ec_table), the corresponding physical table name is obtained based on the dynamic table identifier "tableId", thus determining that the attribute value of the masonry surface component type is stored in the attribute value dynamic table (bis_GeometricElement3d).

[0116] By linking the property path table (ec_propertyPath) and the property mapping table (ec_propertyMap), the property "Area" is mapped to the dynamic column js5, and the property "FinishMaterial" is mapped to the dynamic column js2.

[0117] 4. Extract attribute values ​​and complete the mapping chain synthesis (integrate the fourth-level stored values).

[0118] Based on the above analysis results, the fourth level is located: the storage row in the attribute value dynamic table (bis_GeometricElement3d) with elementId "wall_finish_room101_01": In JavaScript 5, the column is mapped to the "Area" property. The js2 column is mapped to the "FinishMaterial" property.

[0119] 5. Output structured component attribute metadata records. Finally, the parser will synthesize two complete component attribute metadata records for this masonry surface instance, corresponding to the "Area" attribute and the "FinishMaterial" attribute, respectively. Each component attribute metadata record contains the precise location information (source table, source column) and semantic information (attribute name, display name, unit, etc.) for that attribute, constituting the addressing instructions for subsequent data extraction.

[0120] By traversing and parsing all component records in the component type definition table (ec_Class) using the above method, a component attribute metadata set containing component attribute metadata records of all components can be generated.

[0121] S2 defines and creates an attribute index table with a flat structure based on the component attribute metadata set.

[0122] Based on the component attribute metadata set extracted in step S1, which fully characterizes the complex mapping relationship between "attribute semantics and physical storage" in the original model, this step aims to create a novel attribute index table oriented towards high-performance retrieval. The table's structural design overturns the hierarchical, associative storage paradigm of the original model, instead adopting a flat structure based on the principle of single-attribute atomic storage. The flat structure specifically refers to the table structure designed based on the principle of single-attribute atomic storage, meaning that each record in the attribute index table corresponds to one attribute of a component and integrates the complete semantic context of that attribute.

[0123] The core of this principle is to reorganize the attribute information in the original model, which requires multiple table joins to piece together a complete set, into independent, self-contained atomic records. This ensures that each record describes only one specific attribute of a component instance and directly contains the complete semantic context of that attribute.

[0124] Based on the input set of component attribute metadata, this step performs the following core operations to define and create this table:

[0125] S21. Create an attribute index table, whose core fields include at least the globally unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute. Each record in the attribute index table includes only a single attribute.

[0126] Create a new database table named attribute_index as the attribute index table, such as Figure 3 As shown. The attribute index table (attribute_index) directly stores the context information (such as component type name, attribute display name, and unit) that needs to be obtained through real-time foreign key association queries in the component attribute metadata set output in step S1 as fields in the same row record as the attribute values.

[0127] The attribute index table is designed according to the principle of "one record per attribute". That is, for the same component instance, each different attribute (such as "area" or "material") will generate an independent record and be written to the attribute index table, thereby ensuring that each record describes only a single attribute of the component.

[0128] Its core fields include at least: id: Primary key, a globally unique identifier for a component; ec_class_id: A logical identifier for the component type, such as "c_WallFinish", which replaces the original join query between the bis_element table and the ec_Class table that needed to be associated through elementId; element_id: A unique identifier for the component instance, such as "wall_finish_room101_01"; category_name: The logical name of the attribute category, such as "Finishes", which is used internally by the program to identify the business category to which the attribute belongs; category_label: The category name of the attribute, such as "Geometric Attribute", for user-friendly display. name: The logical name of the attribute, such as "Area", used to identify the attribute internally by the program; label: The display name of the attribute (such as "area"), used for user-friendly interface display; value: The original value of the attribute (e.g., 128); persistence_unit: The unit of the attribute; presentation_units: The units in which the attribute is presented.

[0129] S22, Create a database index on the key query field of the attribute index table, wherein the key query field includes at least the globally unique identifier of the component, the logical name of the category of the attribute, and the logical name of the attribute.

[0130] After the attribute index table (attribute_index) is created, indexes are created on the corresponding key query fields based on the core business scenarios of BIM model attribute retrieval and quantity surveying. The selection of these fields is based on the following technical judgments: element_id: A globally unique identifier for a component, used for the basic and frequently used operation of retrieving all attributes of a single component; name: Filter the entire model by the logical name of the attribute, such as finding all components with the "area" attribute. Also, filter by a combination of attribute name and attribute value, such as finding all components with the "finishing material" attribute being "latex paint". This is the core mode for attribute retrieval and statistics. category_name: The logical name of the attribute category. Attributes are grouped and filtered according to business categories. For example, filtering all attributes belonging to the "Finishes" (geometric attributes) or "Material" (material attributes) categories is a common requirement for engineering data management.

[0131] Step S22 embeds query performance optimization strategies for specific business scenarios into the data storage structure. By pre-creating indexes, subsequent equality queries, range queries, and join operations based on these fields can be optimized from full table scans (O(n) time complexity) to index scans (O(log n) time complexity).

[0132] Step S2 constructs an empty attribute index table (attribute_index) with optimized structure and ready indexes. This attribute index table (attribute_index), as a high-performance data container to be populated, represents a paradigm shift from the original complex relational model to a model that directly integrates and stores attribute semantic information (such as component type name, attribute display name, and unit) and attribute values ​​themselves, which were previously scattered across multiple tables and required join queries, into a single table. This table structure, because it eliminates hierarchical relationships, is often referred to as a flat table, providing a target framework for batch data writing in subsequent steps.

[0133] In this embodiment, based on the component attribute metadata parsing result of the masonry surface instance (id: "wall_finish_room101_01") in step S1, the following operations are performed to generate the attribute index table structure: 1. Create the table structure for the attribute index table.

[0134] Based on the characteristics of the component attribute metadata records output in step S1 (e.g., containing key information such as ec_class_id, element_id, name, label, value, and presentation_units), the system creates a new table named attribute_index. The attribute index table is designed to directly accommodate the target normalized records output in step S3. In this embodiment, the exemplary core fields included in the target normalized records are as follows: Figure 3 As shown: (id, ec_class_id, element_id, category_name, category_label, name, label, value, persistence_unit, presentation_units).

[0135] A target normalized record conforming to this structure contains all the context required for an attribute retrieval (such as ec_class_id indicating the component type, and name and label indicating the attribute semantics), without any runtime join queries.

[0136] 2. Create an index for the attribute index table (attribute_index) based on the business scenario.

[0137] To directly support the efficient retrieval and statistics described in the claims, the system immediately creates an index for the attribute index table (attribute_index) based on the core pattern of BIM attribute query after the attribute index table is created, on the following fields: The element_id field index: establishes a fast access path to support the basic operation of querying all attributes of a specific component; The name field index provides performance assurance for core retrieval scenarios that support global filtering by attribute name (e.g., querying all "area" attributes) and queries based on combined attribute name and value conditions (e.g., querying Material="latex paint"). The category_name field index lays the foundation for supporting common engineering needs such as filtering or statistics by business category (e.g., statistics on all "masonry surface" related attributes).

[0138] At this point, an empty data container with optimized structure and ready indexes is complete. Taking the masonry surface component "wall_finish_room101_01" as an example, its records related to the "area" attribute, in the form of ("c_WallFinish", "wall_finish_room101_01", "Finishes", "geometric attributes", "Area", "area", 128, "M2", "m²"), will benefit from the query acceleration advantages brought by the aforementioned indexes when written to this table in subsequent steps.

[0139] S3, through the concurrent processing engine, the component attribute metadata records in the component attribute metadata set are converted into target normalized records and written in batches into the attribute index table.

[0140] By performing offline batch processing in one go, the complex mapping parsing and data extraction work that originally needed to be performed in real time with each query is completed in advance. This step parses the component attribute metadata set output by step S1, extracts the corresponding attribute values, and then converts the parsing results into target normalized records and writes them into the attribute index table (attribute_index) output by step S2.

[0141] This step is executed through a concurrent processing engine configured to coordinate the following sub-operations:

[0142] S31, start multiple concurrent processing threads, and divide the component attribute metadata set into subsets and allocate them to each thread for parallel processing.

[0143] The system initializes a processing task, which schedules multiple worker threads to divide the component attribute metadata set into multiple subsets and assigns them to each thread for parallel processing. Each worker thread constitutes a concurrent processing unit, and all concurrent processing units process a subset of the component attribute metadata set from step S1 in parallel.

[0144] S32, within each concurrent processing thread, the original attribute values ​​are extracted based on the storage location information in the component attribute metadata record, the original attribute values ​​are combined with the component attribute metadata record to generate an initial normalized record, and further converted into a target normalized record that conforms to the attribute index table structure.

[0145] The component attribute metadata set is evenly divided into subsets of multiple source data sets. Each concurrent processing unit executes standardized transformation logic for its assigned subset of the component attribute metadata set. The core of this logic is to parse and write the component attribute metadata records containing indirect references extracted in step S1 into the attribute index table (attribute_index) defined in step S2. That is, for a component attribute metadata record in the component attribute metadata set generated in step S1, such as a component attribute metadata record pointing to the js5 column of the attribute value dynamic table (bis_GeometricElement3d), the processing unit will:

[0146] 1. Based on the element_id and source_column information contained therein, locate the fourth-level attribute value dynamic table (bis_GeometricElement3d) and the extended attribute value dynamic table (bis_GeometricElement3d_Overflow), and extract the original attribute values.

[0147] 2. The extracted attribute values ​​are directly combined with the component attribute metadata record to generate an initial normalized record. The initial normalized record contains complete original storage location information, attribute semantic information, and their original values.

[0148] 3. Transform the initial normalized records, removing the original storage location information fields (such as table name, column name) that are only used to guide the data extraction process, while retaining and organizing their core query semantic fields, such as... Figure 3 As shown, this generates a target normalized record that conforms to the defined attribute index table (attribute_index) structure.

[0149] The target normalized records generated by all threads together constitute a target normalized record set.

[0150] S33, The generated target normalized record is written to the attribute index table through a batch database write operation.

[0151] The generated target normalized record set is temporarily stored in memory. When a processing batch is completed, the processing engine uses the database's batch write interface to submit a large number of target normalized records at once and write them to the target attribute index table (attribute_index).

[0152] S34, Status monitoring and completion notification.

[0153] The concurrent processing engine monitors the status of all concurrent tasks and batch write operations. Once all target normalized records derived from the component attribute metadata set generated in step S1 have been successfully written to the attribute index table (attribute_index), the engine marks this step as complete and can send a notification to the system to announce that the attribute index table (attribute_index) has been built. A populated, data-complete, and immediately queryable attribute index table is in a serviceable state.

[0154] In this embodiment, the concurrent processing engine in step S3 will process the entire set of component attribute metadata output in step S1 in parallel. Taking the component attribute metadata record related to the masonry surface component "wall_finish_room101_01" as an example, the following operations are performed:

[0155] 1. Concurrent processing and initial normalized record generation:

[0156] One worker thread of the concurrent processing engine is assigned to a subset of component attribute metadata records containing "wall_finish_room101_01". The worker thread independently processes each of these component attribute metadata records:

[0157] For the component attribute metadata record of the "Area" attribute (which contains mapping information: source_table="bis_GeometricElement3d", source_column="js5"), the worker thread locates the row with elementId="wall_finish_room101_01" in the bis_GeometricElement3d table and extracts the raw value 128 from the js5 column. Then, this value is combined with the component attribute metadata record of the "Area" attribute to generate an initial normalized record A.

[0158] For the component attribute metadata record of the "FinishMaterial" attribute (which contains mapping information: source_table="bis_GeometricElement3d", source_column="js2"), the worker thread extracts the raw value "latex paint" from the js2 column in the same row. This value is then combined with the component attribute metadata record of the "FinishMaterial" attribute to generate an initial normalized record B. Since "finishing material" is a descriptive attribute rather than a numerical measurement attribute, and its semantic definition does not associate with a unit of measurement, the persistence_unit and presentation_units fields in the initial normalized record B are filled with NULL.

[0159] The initial normalized record contains the attribute value's location information (element ID, source table, source column), attribute semantic information (attribute name, display name, unit), and the original value. The initial normalized record can be in the following JSON format:

[0160] Initial normalized record A: {"elementId": "wall_finish_room101_01", / / A unique identifier for the masonry surface component instance, pointing to a record in the element instance table (bis_element)} "ecClassId":"c_WallFinish", / / A unique identifier for the component type, pointing to a record in the component type definition table (ec_Class). "categoryLabel": "Geometric Attribute", / / The display name of the business category to which the attribute belongs (for users). "categoryName":"Finishes", / / The logical name of the business category to which this attribute belongs (used internally by the program). "columnName": "js5", / / The physical column name in the source table where the attribute value is stored (dynamic column, such as js1, js2, etc.). "label":"Area", / / The name of the attribute displayed to the user. "name":"Area", / / The logical name of the attribute within the system (used for internal program identification). "persistenceUnit":"M2", / / The original storage unit of the attribute value in the database. "presentationUnits":"m²", / / The unit of the attribute value when displayed to the user. "tableName":"bis_GeometricElement3d", / / The name of the source physical table where the attribute value is stored. "value":128 / / The original value of the attribute extracted from the specified column in the source table }

[0161] Initial normalized record B: {"elementId": "wall_finish_room101_01", "ecClassId":"c_WallFinish", "categoryLabel": "Material Properties" "categoryName":"Material", "columnName":"js2", "label":"finishing material", "name": "FinishMaterial", "tableName": "bis_GeometricElement3d", "value": "latex paint" }

[0162] The aforementioned initial normalized record includes the original storage location information, which is used to guide data extraction.

[0163] 2. Output structured, normalized target records.

[0164] Based on the initial normalized record, location information fields such as tableName and columnName, which are related to the original storage mapping and are only used in the extraction process, are stripped to generate the target normalized record. The target normalized record contains fields that conform to... Figure 3 The core feature of the fields in the structure shown is that they contain complete query semantic fields such as element_id, ec_class_id, name, label, value, and presentation_units.

[0165] Taking a masonry surface component as an example, two target normalized records will be generated: target normalized record A' corresponding to the "Area" attribute of the masonry surface component and target normalized record B' corresponding to the "FinishMaterial" attribute of the masonry surface component. The format of the target normalized record can be as follows:

[0166] Target normalization record A': (105, "c_WallFinish", "wall_finish_room101_01", "Finishes", "Geometric Properties", "Area", "Area", "128", "M2", "m²").

[0167] Target normalization record B': (190, "c_WallFinish", "wall_finish_room101_01", "Material", "Material Properties", "FinishMaterial", "Finish Material", "Latex Paint", NULL, NULL).

[0168] This process completes the reverse parsing and binding from business semantics to physical storage location, namely the dynamic columns of the attribute value dynamic table (bis_GeometricElement3d).

[0169] 3. Batch writing.

[0170] The generated target normalized records A' and B', along with a massive number of other component target normalized records, are temporarily stored in a memory buffer. When the buffer is full or a processing batch is completed, the concurrent processing engine calls the database batch write interface to submit tens of thousands of target normalized records at once and write them to the attribute index table (attribute_index).

[0171] The attribute_index table, after being written, will contain the following two logically independent data rows, each representing a different attribute of the masonry surface: (105, "c_WallFinish", "wall_finish_room101_01", "Finishes", "Geometric Properties", "Area", "Area", "128", "M2", "m²"); (190, "c_WallFinish", "wall_finish_room101_01", "Material", "Material Properties", "FinishMaterial", "Finish Material", "Latex Paint", NULL, NULL).

[0172] Step S3 converts the component attribute metadata records extracted in S1 into multiple target normalized records that can be directly queried.

[0173] Once all target normalized records have been written in this manner, the attribute index table (attribute_index) becomes a high-performance data source for serving all subsequent query requests.

[0174] In one alternative implementation, after step S3, the method further includes:

[0175] S4, based on the populated attribute index table, respond to the attribute query request from the lightweight terminal.

[0176] Provide an attribute information query interface for lightweight terminals such as web and mobile terminals. The attribute information query interface returns a structured query response (usually in JSON format) by directly accessing the attribute index table constructed in step S3. The query response contains the requested attribute information and its associated component identifier list, which can be displayed on the terminal interface and used for highlighting interaction of the 3D model.

[0177] This step is executed through a query interface module (such as a RESTful API service), and its processing flow is as follows:

[0178] S41 receives and parses the query request.

[0179] The query interface module receives HTTP / HTTPS requests from the terminal. The HTTP / HTTPS request contains at least one or more query parameters, such as element_id, attribute name, attribute value, category_name, or a logical combination of the above parameters.

[0180] Parse the request body or query string to extract structured query conditions. For example, parsing {name:"FinishMaterial", value:"latex paint"} indicates a request to query all masonry surface components made of latex paint.

[0181] S42 is converted into an index query statement.

[0182] The query interface module converts the parsed query conditions into Structured Query Language (SQL) statements targeting the attribute index table (attribute_index). Because the attribute index table has a flat structure and clear semantics, this conversion process is extremely simple and direct. For example, the query condition "masonry components with latex paint as the finishing material" is converted into a query operation on records in the attribute index table where the name field equals "FinishMaterial" and the value field equals "latex paint".

[0183] S43, execute the query and retrieve the results.

[0184] The generated query is submitted to the database for execution. The database query optimizer uses the indexes pre-created on fields such as name and element_id in step S2 to locate the set of records that meet the conditions in milliseconds using an index scan.

[0185] S44 encapsulates and returns a standardized response.

[0186] The query interface module encapsulates the record set returned by the database into a front-end-friendly standardized data format (such as JSON). The response data directly contains complete information such as attribute names, display names, values, and units. Furthermore, based on the returned list of element_ids, the system can drive the 3D rendering engine to highlight the matched components in the model view, achieving "what you see is what you search for."

[0187] S45, Error Handling and Logging.

[0188] The module captures and processes potential parameter errors and system anomalies that may occur during the query process, returning log records containing standard error codes and information. These log records are also saved for monitoring and analysis.

[0189] This step represents the final delivery point for performance optimization. It demonstrates the overall effectiveness of the proposed solution:

[0190] The query path is greatly simplified: the complex query path that originally required traversing four levels and associating multiple tables is shortened to a single conditional query on a single attribute index table.

[0191] A qualitative leap in response time: By utilizing database indexes, the time complexity is steadily reduced from O(n) or higher, which is related to the complexity of the original model, to close to O(log n) or O(1), achieving a qualitative leap in response time from seconds to milliseconds.

[0192] System load stripping: All complex calculations (mapping resolution, data aggregation) have been completed in the offline preprocessing of the S3 steps, making the online query service lightweight and stable, and able to easily handle high concurrency requests.

[0193] Interface standardization: It provides a unified and semantically clear API, which greatly reduces the development difficulty of performing complex attribute retrieval on lightweight terminals.

[0194] In this embodiment, if it is necessary to query all masonry surfaces with "latex paint" as the finishing material, the specific implementation steps are as follows:

[0195] 1. Terminal sends request: GET / api / search?name= FinishMaterial&value=latexpaste.

[0196] 2. Query the interface to parse the parameters and convert them into query conditions for the attribute index table (attribute_index): find all records where the name field value is "FinishMaterial" and the value field value is "latex paint".

[0197] 3. The database uses the index built on the attribute index table (attribute_index) to quickly locate all matching records, including the masonry surface "wall_finish_room101_01".

[0198] 4. The interface encapsulates the results as JSON and returns them, for example: {results:[{element_id: "wall_finish_room101_01", label:"finishing material", value: "latex paint"}, …]}`.

[0199] 5. The web client highlights the corresponding masonry surfaces and other components in the 3D model based on the element_id list in the JSON.

[0200] In one alternative implementation, after step S3, the method further includes:

[0201] S5, based on the populated attribute index table, respond to the engineering quantity statistics request and generate a statistical report.

[0202] The attribute index table (attribute_index) constructed in step S3 provides an on-demand, dynamic capability for quantity surveying and report generation in project management, completely changing the traditional model that relies on predefined, static reports. The specific steps are as follows:

[0203] S51 receives and parses the statistics request.

[0204] The statistics reporting module receives a request, which includes: the request can be a structured JSON instruction, typically containing:

[0205] Filtering criteria: such as component type (ec_class_id), attribute name and attribute value (name, value), category (category_name), etc.

[0206] Aggregation Dimensions and Measures: Specify which field(s) to group by (e.g., group by ec_class_id), and which numeric attribute to perform which aggregation calculation (e.g., sum, average, or count for attributes where the value field is numeric).

[0207] Output format requirements: such as exporting an Excel report.

[0208] For example, the parsed command is {"filter":{"ec_class_id":"c_WallFinish","name": "FinishMaterial","value":"latex paint"},"aggregate":{"group_by":"ec_class_id","sum":"Area"}, "format":"excel"}`, which means requesting to calculate the total area of ​​all masonry surfaces using latex paint, summarize by component type, and output as an Excel file.

[0209] S52, perform filtering and aggregation queries on the attribute index table.

[0210] The business requests are transformed into filtering and aggregation query operations performed on the attribute index table (attribute_index).

[0211] For example, the request to calculate the total area of ​​masonry surfaces using latex paint is converted into a query operation on the attribute index table (attribute_index): first, all records with component type "c_WallFinish", material attribute "latex paint", and geometric attribute "Area" are filtered out, and then the summation and aggregation calculation is performed on the value field of the record.

[0212] S53, dynamically generates structured statistical reports.

[0213] The system retrieves the aggregated results and related detailed data (such as the element_id and specific value field values ​​for each component) returned by the database, calls a report generation component (such as Apache POI, EasyExcel, etc.), and dynamically generates a report file according to the requested format. The report content typically includes a summary, detailed list, statistical charts, etc., and information such as units is directly derived from the data fields.

[0214] S54, Return to report file and completion notification.

[0215] The generated report file (such as an Excel file) is returned to the client as a binary stream for the user to download. Simultaneously, processing status notifications can be returned.

[0216] Step S5 generates a quantity statistics report file (e.g., .xlsx format) containing summary data calculated based on the request conditions, optional grouping details, and complete component attribute metadata information (e.g., unit, component type).

[0217] In this embodiment, it is assumed that a detailed breakdown of the area and quantity of all masonry surfaces in the project is required, such as... Figure 4As shown, the specific implementation steps for preparing a procurement plan for interior decoration materials are as follows:

[0218] 1. The client sends a statistics request, which can be in JSON format, and the statistics request is: {"filter":{"ec_class_id":"c_WallFinish"}, "format": "excel"}. This means: filter out all components of type "Masonry Surface" (i.e., ec_class_id is "c_WallFinish"), and export an Excel report containing details.

[0219] 2. The statistics report module executes a query. The system quickly filters out all records in the attribute index table (attribute_index) where ec_class_id is "c_WallFinish" and name is "Area". It then sums the values ​​in the value field and retrieves detailed data for each component.

[0220] 3. The module dynamically generates Excel reports. The system-generated reports will include summary data and detailed lists. The "Component Type" column in the report is the display name "Masonry Surface" obtained by querying the component type definition table based on ec_class_id.

[0221] 4. Users can download the report and immediately obtain accurate and detailed engineering quantity data for procurement and cost accounting.

[0222] Example 2

[0223] This embodiment provides a retrieval-oriented BIM lightweight model attribute index table construction system, used to work in conjunction with a BIM lightweight model database to achieve efficient retrieval of massive component attributes and real-time quantity statistics. The system consists of two main execution parts: offline preprocessing and online services. It interacts with the original BIM model database through a unified data layer, and finally provides terminal services through a query interface and a statistical reporting module. It includes:

[0224] 1. A component attribute metadata parsing module, used to extract a set of component attribute metadata from the BIM lightweight model through a parser, wherein the set of component attribute metadata includes at least one component attribute metadata record.

[0225] The component attribute metadata parsing module starts during system initialization and is responsible for performing a one-time offline parsing of the complex storage structure of the original model. The module includes:

[0226] 1) The structure traversal submodule is used to connect and traverse multiple logically related data tables in the BIM lightweight model database.

[0227] Based on the unique four-layer storage architecture of the BIM lightweight model, the structure traversal sub-modules are accessed sequentially: the first-level component type definition table (ec_Class) to obtain the component type identifier and definition; the second-level attribute semantic definition table group (including ec_property, ec_propertyCategory, ec_KindOfQuantity) to obtain attribute business semantics, category and unit information; the third-level dynamic storage mapping table group (including ec_table, ec_column, ec_propertyMap, ec_propertyPath) to parse the dynamic mapping relationship from attribute semantics to physical storage location; and the fourth-level instance data storage table (including bis_element, bis_GeometricElement3d, bis_GeometricElement3d_Overflow) to associate specific component instances.

[0228] 2) The association mapping submodule is used to establish the complete association mapping relationship between the four hierarchical data tables.

[0229] The association mapping submodule performs a series of database association queries to construct a complete location path from logical definition to physical storage for each attribute of each component type. Specifically, for an attribute such as the area of ​​a masonry surface component, the association mapping submodule will resolve that it belongs to the component type "c_WallFinish", the business name is "Area", and the unit is "m". 2 And its value is stored in the js5 column of the bis_GeometricElement3d table.

[0230] 3) Component attribute metadata set generation submodule, used to output a structured component attribute metadata set.

[0231] The component attribute metadata collection generation submodule encapsulates the complete mapping path parsed above into structured component attribute metadata records. Each component attribute metadata record includes at least: element identifier (element_id), component type identifier (ec_class_id), attribute name (name), attribute value storage location (source table name, source column name), attribute display name (label), and units (presentation_units). All component attribute metadata records together constitute the component attribute metadata collection for use by subsequent modules.

[0232] 2. Attribute index table construction module, used to generate an attribute index table based on the component attribute metadata set.

[0233] The attribute index table construction module is responsible for designing and initializing the attribute index table (attribute_index), which serves as the core query structure of the system. Its structure is directly geared towards efficient query optimization. This module includes:

[0234] 1) The table structure definition submodule is used to create an attribute index table with a flat structure based on the component attribute metadata set. Its core fields include at least the global unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute.

[0235] The table structure definition submodule defines the core fields of the attribute index table (attribute_index) based on the information contained in the component attribute metadata set. Preferably, the fields include at least: primary key id, component type identifier ec_class_id, element identifier element_id, attribute name name, attribute display name label, attribute value, and display unit presentation_units.

[0236] 2) Index Preset Submodule, used to create database indexes on the key query fields of the attribute index table, wherein the key query fields include at least the globally unique identifier of the component, the logical name of the category of the attribute, and the logical name of the attribute.

[0237] Based on the core business scenario of BIM attribute retrieval and statistics, the attribute index table creates indexes on the element_id, name, and category_name fields.

[0238] 3. A concurrent processing engine is used to convert the component attribute metadata records in the component attribute metadata set into target normalized records and write them in batches into the attribute index table.

[0239] The concurrent processing engine is a high-performance offline data processing engine responsible for transforming and populating the original mapping relationships into the attribute index table. The concurrent processing engine includes:

[0240] 1) The task scheduling submodule is used to start multiple concurrent processing threads and divide the component attribute metadata set into subsets and allocate them to each thread for parallel processing.

[0241] After system startup or model update, the task scheduling submodule initializes a processing task. The processing task can be asynchronous, and multiple worker threads are dynamically scheduled according to computing resources to ensure the parallel processing efficiency of massive component attribute metadata.

[0242] 2) Data conversion submodule, used in each concurrent processing thread to extract the original attribute values ​​according to the storage location information in the component attribute metadata record, combine the original attribute values ​​with the component attribute metadata record to generate an initial normalized record, and further convert it into a target normalized record that conforms to the attribute index table structure.

[0243] For each input component attribute metadata record, the data transformation submodule performs the following operations in sequence:

[0244] a) Mapping Resolution and Initial Normalized Record Generation: Based on the element_id, source_table (source table name), and source_column (source column name) information in the component attribute metadata record, the corresponding attribute value dynamic table (e.g., bis_GeometricElement3d) or extended attribute value dynamic table (e.g., bis_GeometricElement3d_Overflow) is located, and the original attribute values ​​are extracted. Subsequently, the original attribute values ​​are combined with the component attribute metadata record to generate an initial normalized record. The initial normalized record contains complete original storage location information (source table name, source column name), attribute semantic information, and original values.

[0245] b) Semantic transformation and target normalized record generation: The initial normalized record is transformed by removing the original storage location information fields (such as source_table, source_column) that are only used to guide the data extraction process, while retaining and organizing its core query semantic fields (such as element_id, ec_class_id, name, label, value, presentation_units, etc.), thereby generating a target normalized record that conforms to the structure definition of the attribute index table (attribute_index).

[0246] 3) Batch write submodule: Through batch write operation of database, the generated target normalized record is written into the attribute index table.

[0247] The batch write submodule temporarily stores the target normalized records generated by each thread in a memory buffer. When the accumulated batch size reaches the preset size, it calls the database's batch write interface to submit a large number of target normalized records to the attribute index table (attribute_index) at once.

[0248] In one alternative implementation, a retrieval-oriented lightweight BIM model attribute index table construction system further includes:

[0249] 4. Query interface module, used to respond to attribute query requests from the lightweight terminal based on the populated attribute index table.

[0250] The query interface module serves as the system's online service entry point, receiving and processing real-time query requests, including:

[0251] 1) API service terminal module, used to provide RESTful API and receive HTTP / HTTPS query requests from web or mobile devices.

[0252] The API service sub-module is deployed as an independent network service, receiving requests containing query parameters (such as `name="FinishMaterial" AND `value="latex paint"), and is responsible for protocol parsing and encapsulation.

[0253] 2) The query transformation submodule is used to transform business query parameters into optimized query operations on the attribute index table (attribute_index).

[0254] The query transformation submodule parses the request parameters and leverages the flat structure and clear semantics of the attribute index table (attribute_index) to directly generate simple database query conditions. For example, it transforms "find masonry surface components with latex paint finish" into an equality matching condition for the name and value fields of the attribute index table (attribute_index).

[0255] 3) The result encapsulation submodule is used to execute queries, obtain results, and encapsulate them into a standardized response format.

[0256] The result encapsulation submodule executes the generated query, quickly retrieves the result set using the index on the attribute index table (attribute_index), and encapsulates the results into a front-end-friendly format such as JSON before returning them. The response directly includes the attribute name, value, unit, and corresponding component ID list, supporting 3D model highlighting on the terminal.

[0257] In one alternative implementation, a retrieval-oriented lightweight BIM model attribute index table construction system further includes: 5. Statistical Report Module: This module is used to respond to engineering quantity statistics requests and generate statistical reports based on the populated attribute index table.

[0258] The statistics reporting module handles more complex aggregation analysis requests, providing engineering decision support, including:

[0259] 1) The statistics request parsing submodule is used to receive and parse structured engineering quantity statistics requests.

[0260] The requests received by the statistics request parsing submodule explicitly include: filtering conditions (such as component type, attribute value range), aggregation dimensions (such as grouping by floor), aggregation measures (such as summing of volumes), and output format requirements (such as Excel).

[0261] 2) Aggregate query execution submodule, used to perform complex filtering and aggregation queries on the attribute index table (attribute_index).

[0262] The aggregate query execution submodule converts business requests into aggregate query statements (such as using grouping and summation).

[0263] 3) Dynamic report generation submodule, used to dynamically generate structured statistical reports based on aggregated query results.

[0264] The dynamic report generation submodule calls a report generation library (such as EasyExcel) to integrate summary data, detailed lists, and charts, generating a statistical report file (such as .xlsx format) that can be downloaded directly. The report automatically includes the correct units of measurement.

[0265] After system deployment, the metadata parsing module first performs a one-time offline parsing of the target BIM lightweight model to extract a complete set of component attribute metadata.

[0266] Next, the attribute index table building module creates and initializes an empty attribute index table (attribute_index) with a flat structure based on the definition of the set, and pre-sets database indexes on its key fields.

[0267] Then, the concurrent processing engine starts and executes the core index data filling job. Based on the storage location information in the component attribute metadata set, the concurrent processing engine concurrently locates and extracts the original values ​​of all attributes to generate an initial normalized record containing complete mapping information; then, by semantically condensing and structurally transforming the initial normalized record, its original storage location information is stripped away to generate a target normalized record set consisting of target normalized records that fully conform to the structure of the attribute index table (attribute_index).

[0268] Finally, through efficient batch database write operations, the target normalized record set is fully populated into the attribute index table.

[0269] At this point, an attribute index table that is immediately usable and supports high-performance semantic queries is complete. From then on, all query requests will directly target this index table, eliminating the need to re-parse the original complex multi-level dynamic table structure.

[0270] After completing the offline construction and population process described above, the system enters online service mode. In this mode, user-initiated attribute query requests are directly responded to by the query interface module, and quantity statistics requests are dynamically processed by the statistics report module. Both modules operate entirely on the constructed and populated attribute index table (attribute_index), returning results through simple conditional queries or aggregation calculations. This completely bypasses direct access to the complex, multi-layered dynamic storage architecture of the original lightweight BIM model, achieving fundamental performance optimization at the data organization model level.

[0271] Example 3

[0272] This embodiment proposes an electronic device, including: Memory, used to store computer programs; The processor is used to execute the program stored in the memory to implement the steps of the above embodiment of the BIM lightweight model attribute index table construction method for retrieval.

[0273] For details on the specific implementation of each step and related explanations, please refer to the aforementioned embodiment of a retrieval-oriented BIM lightweight model attribute index table construction method, which will not be repeated here.

[0274] The memory of the electronic device mentioned in this embodiment may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0275] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0276] Example 4

[0277] This invention also proposes a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the steps of the above-described embodiment of a retrieval-oriented BIM lightweight model attribute index table construction method. For specific implementation details and explanations of each step, please refer to the aforementioned embodiment of a retrieval-oriented BIM lightweight model attribute index table construction method, which will not be repeated here.

[0278] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for constructing a retrieval-oriented lightweight BIM model attribute index table, characterized in that, include: The component attribute metadata set in the BIM lightweight model is extracted by the parser, and the component attribute metadata set includes at least one component attribute metadata record. Based on the aforementioned component attribute metadata set, define and create an attribute index table with a flat structure; The concurrent processing engine converts the component attribute metadata records in the component attribute metadata set into target normalized records and writes them in batches into the attribute index table.

2. The method according to claim 1, characterized in that, The step of defining and creating an attribute index table with a flat structure based on the component attribute metadata set includes: Create an attribute index table, whose core fields include at least the globally unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute. Each record in the attribute index table includes only a single attribute. Create a database index on the key query fields of the attribute index table. The key query fields include at least the globally unique identifier of the component, the logical name of the attribute category, and the logical name of the attribute.

3. The method according to claim 1, characterized in that, The step of converting component attribute metadata records in the component attribute metadata set into target normalized records and batch writing them into the attribute index table through a concurrent processing engine includes: Multiple concurrent processing threads are started, and the component attribute metadata set is divided into subsets and distributed to each thread for parallel processing; Within each concurrent processing thread, the original attribute values ​​are extracted based on the storage location information in the component attribute metadata record. The original attribute values ​​are then combined with the component attribute metadata record to generate an initial normalized record, which is further converted into a target normalized record that conforms to the attribute index table structure. The generated target normalized records are written to the attribute index table through a batch database write operation.

4. The method according to claim 1, characterized in that, After converting the component attribute metadata records in the component attribute metadata set into target normalized records and batch writing them into the attribute index table using a concurrent processing engine, the process further includes: Based on the populated attribute index table, respond to attribute query requests from the lightweight terminal; Alternatively, based on the already populated attribute index table, respond to the quantity statistics request and generate a statistical report.

5. A retrieval-oriented lightweight BIM model attribute index table construction system, characterized in that, include: The metadata parsing module is used to extract the component attribute metadata set in the BIM lightweight model through a parser. The component attribute metadata set includes at least one component attribute metadata record. The attribute index table construction module is used to generate an attribute index table based on the component attribute metadata set; A concurrent processing engine is used to convert component attribute metadata records in the component attribute metadata set into target normalized records and write them in batches into the attribute index table.

6. The system according to claim 5, characterized in that, Also includes: The query interface module is used to respond to attribute query requests from the lightweight terminal based on the populated attribute index table. Alternatively, a statistics reporting module may be used to respond to a quantity statistics request and generate a statistics report based on the populated attribute index table.

7. The system according to claim 5, characterized in that, The attribute index table construction module includes: The table structure definition submodule is used to create an attribute index table with a flat structure based on the component attribute metadata set. Its core fields include at least the global unique identifier of the component, the logical identifier of the component type, the unique identifier of the component instance, the category logical name of the attribute, the logical name of the attribute, the original value of the attribute, and the unit of the attribute. The index pre-setting submodule is used to create a database index on the key query fields of the attribute index table. The key query fields include at least the globally unique identifier of the component, the logical name of the attribute category, and the logical name of the attribute.

8. The system according to claim 5, characterized in that, The concurrent processing engine includes: The task scheduling submodule is used to start multiple concurrent processing threads and divide the component attribute metadata set into subsets and allocate them to each thread for parallel processing. The data conversion submodule is used to extract the original attribute values ​​according to the storage location information in the component attribute metadata record within each concurrent processing thread, combine the original attribute values ​​with the component attribute metadata record to generate an initial normalized record, and further convert it into a target normalized record that conforms to the attribute index table structure. The batch write submodule writes the generated target normalized records into the attribute index table through a batch database write operation.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing a program stored in memory to implement the steps of the method according to any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-4.

Images