How do you store element "codes" in IFC?

Moult · June 17, 2021, 11:07pm

Bumping to finally include officially in the docs, not as an implementer agreement (link is now broken).

github.com/buildingSMART/IFC4.3.x-development

Proposal to mark Reference property as deprecated where it duplicates the purpose of a construction type name

opened 11:06PM - 17 Jun 21 UTC

allocated allocated-core

Full discussion [here](https://forums.buildingsmart.org/t/how-do-you-store-eleme…nt-codes-in-ifc/884/3). In short, architecture defines codes for construction types, such as `D01` for a fire-rated, single leaf, metal framed door, and `D02` for a non-fire rated, timber framed door. The IFC documentation does not make it clear that these codes should be stored in the IfcTypeObject's Name attribute, even though that is the intention as mentioned by @TLiebich. Also, there is a legacy `Reference` property when vendors didn't have support for types. But in 2021, most vendors do have type support. There is already an implementer agreement about this conflict, but let's resolve it and include in the docs. I propose to remove this legacy Reference property so there is no more confusion, also I propose that on the IfcDoorType, IfcWallType, and IfcWindowType pages, a sentence be added basically giving an example of `D01` like I gave above. More relatable examples I think will help ensure IFC data is more useful. The majority of export mappings currently get this wrong, and I see all sorts of stuff populated in the Name fields. Ping @berlotti @TLiebich @aothms

Topic		Replies	Views
Proper use of 'Name', 'Type', 'Type name' and 'Description'	7	3981	April 6, 2020
Space category in IFC 4 IFC	5	691	February 7, 2019
Does these attributes are defined by buildingSMART or not? Developers ifc2x3 , common-schema	15	2060	June 3, 2019
Glazing information for curtain wall panels	0	41	November 1, 2024
Store, modify and retrieve ifc-data with ifcSQL Serializations	4	3821	July 4, 2019

How do you store element "codes" in IFC?

Related topics