If you're reading this, we've just migrated servers! If anything looks broken please email dion@thinkmoult.com :)

IfcRelDefinesByObject vs IfcRelDefinesByType

Hello,
I am struggling to understand the difference between IfcRelDefinesByObject and IfcRelDefinesByType.
Let's say i have a furnishing element type composed of a table and two chairs. Then, the furnishing element type can declare a new instance. Then, automatically the table and the chairs are also declared . If I select one chair of the furbishing element instance, its inverse property IsDeclaredBy(IfcRelDefinesByObject@RelatedObjects) should then contan the original furbishing element type name?
Thanks

theoryshaw

Comments

  • Also curious.
    related: https://github.com/IfcOpenShell/IfcOpenShell/issues/2283
    would love to see BB accomodate this.
    Along with 'typed aggregates', as well: https://github.com/buildingSMART/IFC4.4.x-development/issues/17

    Pit
  • They have two different meanings. DefinesByType means that this product is of that type. (e.g. if on a project, you were to ask the question "what type is that pipe, what type is that slab, what type is that door, what type is that pump" etc, the DefinesByType should answer that question. Occurrences will then inherit properties, materials, and geometry of the type, and can override them.

    DefinesByObject means that the object is a clone of another due to a constraint, the constraint shown in the docs that it is part of an aggregated type. I find it a generally unexplored and less developed aspect of the IFC schema so exactly how it is managed is still to be discovered. The clone is exactly the same apart from its placement. No overriding can occur. My understanding is that it seems to be bit like a mapped representation at the product level.

    CoentheoryshawPit
  • I have consulted the links and the answers you have given me and from all this I have the idea that the DefidesByObject attribute stores information of a part of the aggregate that cannot be defined in the type from which one of the parts derives.
    For example, and going back to the previous example, a FurnishingElement consisting of a table and two chairs.
    Its IsDecomposedBy(IfcRelAggregates@RelatingObject) attribute would contain the set (Table, Chair1,Chair2) each one eventually defined by a type whose name I can know by asking the chair for the value of its IsTypedBy(IfcRelDefinesByType@RelatedObjects) attribute.
    However, the position of that chair in the aggregate would be exclusively stored in the FurnishingElement so to know if that chair has some kind of specific concrete condition I would have to ask if its IsDeclaredBy(IfcRelDefinesByObject@RelatedObjects) attribute has any stored value.

    I think I can conceptually understand the difference now.
    (I wonder then what would happen if this FurnishingElement aggregate were part of a Group).

  • Nothing happens if the aggregate is part of a group. A group is non-geometric, does not exist as part of the spatial tree, and is separate :)

    Pit
Sign In or Register to comment.