Closed Moult closed 2 years ago
Note that this issue is related to #178. If this proposal were accepted, it would make it one location less confusing :)
Voted
Keep: Dunno: @aothms Remove: @TLiebich @Moult
Result: remove :)
As it stands this doesn't seem to affect UML.
Full discussion here.
In short, architecture defines codes for construction types, such as
D01
for a fire-rated, single leaf, metal framed door, andD02
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