IfcSpace good for Spatial containment of IfcDistributionElements?

falken10vdl

In order to establish a spatial containment relationship for IfcDistributionElements (for example IfcCableCarrierSegment and IfcCableSegments) is it good practice to assign those elements to IfcSpace?
Example IfcSpace for "power delivery conduit" where you would have the IfcCableCarrierSegment and fittings and also IfcCableSegments and fittings that bring the power from outside of the building to the building.
Cheers!

walpa

I think it depends on the use case.
For example, an IfcLightFixture relationship with IfcSpace could be used for lighting calculations. For cables and carriers, perhaps for checking installation height, or something similar.
Cheers

KoAra

Since IfcCableCarrierSegment is installed per location, it would be beneficial if it could be related to IfcSpace (IfcSpatialElement).
On the other hand, IfcCableSegments are uniform from the source to the sink and are often installed across different buildings or rooms. I had concerns that handling multiple IfcSpaces might become cumbersome. Determining the allowable rated current does require understanding the outdoor temperature and the worst-case scenario inside the enclosure.
If the relationship between IfcCableSegment and IfcCableCarrierSegment were strictly defined, it wouldn't be a problem 😵‍💫

steverugi

@falken10vdl

In order to establish a spatial containment relationship for IfcDistributionElements (for example IfcCableCarrierSegment and IfcCableSegments) is it good practice to assign those elements to IfcSpace?

I'd say yes, distribution elements are contained in IfcSpace (if I am not mistaken Revit uses them as well).

@KoAra

Since IfcCableCarrierSegment is installed per location, it would be beneficial if it could be related to IfcSpace (IfcSpatialElement).
On the other hand, IfcCableSegments are uniform from the source to the sink and are often installed across different buildings or rooms. I had concerns that handling multiple IfcSpaces might become cumbersome. Determining the allowable rated current does require understanding the outdoor temperature and the worst-case scenario inside the enclosure.

Don't we have IfcZone for that? By my understanding it's a representation-free entity to group IfcSpace entities together via IfcRelAssignsToGroup relationship.
Cheers

falken10vdl

I have gone over the whole hierarchy under IfcRelationship, and in addition to IfcRelContainedInSpatialStructure for spatial containment there is a good candiate... IfcRelAssignsToGroup.
So it looks there are two possibilities to relate IfcDistributionElements (apart from pure element decomposition):
1. IfcDistributionElements can be related physically with IfcRelContainedInSpatialStructure to IfcSpace
2. IfcDistributionElemetns can be related physically with IfcRelContainedInSpatialStructure to IfcSpace and IfcSpace can logically with IfcRelAssignsToGroup to IfcZone

Cheers!

Moult

Here are the relationships you might use:

• IfcRelContainedInSpatialStructure (element<->space): this is the primary location of the object that you need to be in to find and maintain the object.
• IfcRelReferencedInSpatialStructure (element<->spatial elements): any secondary locations that the element might be servicing, if applicable
• IfcRelAssignsToGroup (element<->zone): any zones that the element is part of, such as ventilation zones, fire alarm zones, etc.
• IfcRelAssignsToGroup (element<->system): any systems that the element is part of, such as hot water, supply air, sprinklers, power supply, cctv, etc
• IfcRelReferencedInSpatialStructure (system<->spatial elements): any locations that the system as a whole services, such as level 2 security alarms

Note some software like Revit only assign distribution segments and fittings to the building storey, not space. This is not ideal as it prevents the ability to easily isolate and curate as-built verification of service reticulation.

falken10vdl

@Moult since there is no IfcRelContainedInSpatialStructure (element<->element), the "relationship of containment" between a number of IfcCableSegments that are routed in a IfcCableCarrierSegment is done "indirectly"? I mean IfcRelContainedInSpatialStructure for the IfcCableSegments (Power1, Power2, etc) to IfcSpace (PowerIn) and also IfcRelContainedInSpatialStructure for IfcCableCarrierSegment (PowerTrayIn) to the same IfcSpace (PowerIn).
Cheers!

Moult

IfcRelNests.

falken10vdl

Cool! I tried that initially in Bonsai and found it very convenient. I was a little bit confused afterwards by the description in buildingSMART 5.1.3.41 IfcRelNests

The nesting relationship IfcRelNests is a special type of the general composition/decomposition (or whole/part) relationship IfcRelDecomposes.

That is what made me think that since cable carrier trays are not composed/decomposed of cables but rather can accommodate them I thought it was not suitable (I am not a native English speaker so might have not understood it properly).
I have asked for an account in the buildingSMART forums to raise an issue to ask to add this example next to the one of IfcDistributionElement with IfcDistributionPorts so it is clear that this relationship also applies to this sort of scenario.
Thanks!

Moult

The difference between IfcRelAggregates and IfcRelNests is best elaborated by reading the concepts chapter:

• IfcRelAggregates

  • IfcRelNests

In short, an aggregate describes composite objects. The parent object is defined as the sum of its composite parts. This is why aggregates do not have representations - only their children do. Examples include a stair (what is a stair? The flight? The railing? The landings? All of it!), roof (tiles or sheeting, beams or slab, insulation, etc), walls (studs, sheeting, insulation), etc.

A nest describes hosted objects. The parent object is distinct from its child(ren) (so the parent can have bodies), and the children can be attached to the host. Examples include taps attached to sinks, ports, door hardware fitting into doors, etc. If a child can be plugged or slotted or fitted into the parent, it's probably nesting.

One thing that sometimes comes up as a point of confusion is that the documentation talks about how nesting implies an ordered relationship. This is best clarified in the concept of object nesting (which is different to element nesting). The difference is primarily that if you nest non-product objects (e.g. cost items) then the children are ordered (subitem 1, subitem 2, subitem 3).

falken10vdl

Very insightful explanation. Thanks!
I think the rule given in the doc you linked is very usefull to decide in practice:

A general rule for using nesting as opposed to aggregation is based on the contents of the manufactured product as ordered according to its specified article number. If the product includes the component (regardless of whether it comes assembled), then it should use aggregation. If the product does not include any such component but is specifically designed for attaching to other components, then it should use nesting.

Thanks!