[Question] Regarding IfcRelFillsElement and IfcRelVoidsElement check in PartOf-Facet

[MarcelStepien]

Hello everyone,

in the current IDS version (0.9.6) the relations IfcRelFillsElement and IfcRelVoidsElement are included in the partOf-Facet. The documentation says:

The IFCRELVOIDSELEMENT relationship describes how a void belongs to an element.
The IFCRELFILLSELEMENT relationship describes how an element fills an a void, potentially making it part .

So, I am trying to understand the descriptions. Does the check stops at the IfcOpeningElement? If yes, would'nt it render the entity-check included in the partOf-Facet useless (since it always would be IfcOpeningElement in most cases)?

Usually I would consider the important information to be the elements behind the openings. Lets look at the following example:

In my opinion, a valid check would be:

1. Which wall elements are containing windows with type XY?
2. Are the doors leading to apartment entries inserted in a partition wall? (which must be the case and may require additional properties)

Is my understanding of the partOf-facet check correct? Or can someone give me practical example in IDS that utilizes the IfcOpeningElements directly? The description in the documentation may need a bit more context, describing how the openings are utilized specifically. Personally I would recommend avoiding the entity use of an IfcOpeningElement and refer directly to the elements behind the relation.

Kind regards, Marcel Stepien

[CBenghi]

That's well spotted, and worth discussing.

I see two options to solve this

User friendly option

Assuming that IfcOpenings are not interesting in most scenarios we keep a single value of the relation that includes IFCRELFILLSELEMENT and IFCRELVOIDSELEMENT so that the connection from wall to window is transparent to the end user.

Tech savvy option

We allow users to specify multiple relations to consider, so that they can stop at multiple points in the chain of relations. E.g. in the following case, if relation was CNT only wall would be selected, with CNT/VDS/FLS we could get to the door, and with CNT/VDS/FLS/AGG we would also include the Sensor.

[Moult]

This is resolved now, right? The solution is that it's now transparent to the user.

[CBenghi]

I think it probably is resolved. @MarcelStepien?

[andyward]

Do we have any updated PartOf test cases covering this new update to Relations traversal @CBenghi ?

[MarcelStepien]

The current solution is, that IFCRELVOIDSELEMENT and IFCRELFILLSELEMENT relations had been combined into one single option "IFCRELVOIDSELEMENT_IFCRELFILLSELEMENT". This option performs a two steps iteration through the relations and checks for Elements behind a IfcOpeningElement, skipping to the relevant element.

However, this will only be a temporary solution. A concept will be worked on in the future to provide clarity on multi-steps iteration through the relation. Allowing to check the relating elements for elements attached to certain related combination.

[berlotti]

wasn't it "IFCRELVOIDSELEMENT IFCRELFILLSELEMENT"? (with a space instead of a _) That allows it to become an xml list in the future.

[MarcelStepien]

@berlotti yes, my bad. Depending on how you generate the class structure from the xsd, it automatically adds a '_' inbetween (since its translated to an enumeration). The option is labeled as "IFCRELVOIDSELEMENT IFCRELFILLSELEMENT" though.