For architectural uses, traditionally we record three pieces of information about a door: its door type (e.g. D01, D02, D03, for instance D01 would be a 2400x920 metal door with 2 hour fire rating, and D02 would be a 2100x820 wooden door), and its door number, which is simply an identifier for that door (e.g. 01, 02, 03). Usually these identifiers are paired with the room that the door opens to, so a door D01, with number 01, might be in room G01.
Where should these attributes be stored in IFC? Or should they be stored at all? Programmatically, without any human data, we can extract the following:
The spatial relationship with the door and an IfcSpace can derive the room the door is part of. If nothing else, the IfcSpace must have a GlobalId, so we can schedule and identify it.
The door type can be derived by the IfcDoorType IsTypedBy relationship, and each IfcDoorType has a GlobalId. Not exactly pronounceable, but it can be identified and scheduled.
The door number can be derived by the IfcDoor’s GlobalId itself. Again, not a traditional “number” by any means, but it is technically unique.
However, where is the proper place to store this information? Should I store the name of a room in IfcSpace.Name? Or should I store it in IfcSpace.Pset_SpaceCommon.Reference? Similarly, should I store the door number in IfcDoor.Name, or in IfcDoor.Pset_DoorCommon.Reference? Should I store the door type in IfcDoorType.Name, or is there another location that I am unsure of?
I think you may have misunderstood my question. IfcClassification is meant for classification systems such as Uniclass, Uniformat, Omniclass, etc. So no, this doesn’t help answer my question unfortunately.
I am talking about simple identifiers within a building, like this door belongs to room G01, is of door type D01 detailed in our door schedule, and is door 01 in the room.
If I understand you correctly, then what you refer to as door type D01 is what has been called “construction type” in IFC development. There is a rule to store it either as Name attribute in the according type object, e.g. as IfcDoorType.Name=“D01”, or (if no type objects are provided) as Reference property in the according property set, e.g. Pset_DoorCommon.Reference=“D01”
That’s exactly what I’m looking for. Thanks! It is clear that the two locations (i.e. Name and Pset_*.Reference is a source of confusion. I think Name makes much more sense.
sure, two locations are less good than one. The agreement dates back to a time, when there was little support of type objects, and should read:
if a type object is assosziated to the occurrence object (e.g. IfcWallType to IfcWall) then the construction type is provided by the Name attribute (e.g. IfcWallType.Name)
if not, then the Pset_XxxCommon Reference property associated to the occurrence object shall be used (e.g. Pset_WallCommon.Reference)
if both are present, the Name at the type object takes precedence
(need to be added to the concept definitions in the specification)
Thanks for the clarification, as that last sentence (“If both information is present, the construction type assigned to the occurrence shall override the construction type assigned to the type.”) was really confusing. Your clarification of “if both are present, the Name at the type object takes precedence” makes much more sense.
In that case, if the preferred method is to store it in Name, I propose to mark as obsolete, or deprecate the Pset_DoorCommon.Reference field, unless there is a valid explanation as to its existence. This proposal goes not just for IfcDoor, but for all IFC elements that have this source of confusion.
What is the process to get this proposal approved and implemented? I can create a list of property sets which need changing. I notice that the JIRA instance has a message saying that it will be moved and no new issues will be accepted.