Interpreting classifications and properties for grouped objects

[michaeldejong]

Hi all,

I somewhat regularly see customers submitting IFC files for validation that contain objects that are grouped together using IfcRelAggregates. The interesting bit is that additional information like classifications and properties are sometimes attached to either the parent object and/or the child objects, but not to all objects.

Here's a very simple example that I've come across:

#855=IFCPROPERTYSINGLEVALUE('IsExternal',$,IFCBOOLEAN(.F.),$);
#906=IFCCLASSIFICATION('','',#907,'NL-SfB');
#10973=IFCSTAIR('2si94wiMrCAuS_9Pq9rdoz',#18,'...',$,'...',#10972,#10970,'1419800',.NOTDEFINED.);
#10975=IFCSTAIR('2si94wiMrCAuS_9Py9rdoz',#18,'...',$,'...',#10969,$,'1419800',.NOTDEFINED.);
#10978=IFCPROPERTYSET('3swCMp1Gk9Zh9NUgoXKNpF',#18,'Pset_StairCommon',$,(#855));
#10980=IFCRELDEFINESBYPROPERTIES('3RFAwAR9R5vYvmV2Pu0pWp',#18,$,$,(#10975),#10978);
#10981=IFCCLASSIFICATIONREFERENCE($,'24.11','trappen en hellingen; trappen, rechte steektrappen',#906);
#12658=IFCRELAGGREGATES('1UCE5pz$VbC3PS8kyXQJHb',#18,$,$,#10975,(#10973));
#12906=IFCRELASSOCIATESCLASSIFICATION('1$$2VP59RXtLKLCujYOKU7',#18,'...','...',(#10975),#10981);

As you can see in this example, the parent IfcStair (#10975) object has both a property and a classification, but the child IfcStair (#10973) has neither. I'm not sure if this is an issue with how these objects are created or generated in Revit, or if it has to do with the IFC export process, but I've been told similar things also happen with roofs and ramps. I've seen this kind of output from multiple different customers.

Although not explicitly stated, I suppose one could interpret that the child IfcStair object should also be considered to have the IsExternal=F property, and the 24.11 classification (because it's parent has these explicitly defined), but there's nothing in the IFC or IDS documentation or test cases that support that idea. However, the IDS test cases do tell us to look at properties and classifications of related IfcTypeObjects when looking up the properties or classifications of an object. So perhaps this idea of looking at related objects (like we do for types) isn't really that farfetched?

I have tried using the partOf facet, but unfortunately that doesn't quite cover the use case, since that only allows me to check if an entity is part of a group, and not if the other entity in that group has a specific property or classification, and if so, which one.

I'm wondering if others have any thoughts on this issue? Perhaps others have come across into this issue themselves as well?

[atomczak]

If your IDS specifies IsExternal property on all IfcStair objects, then the #10973 fails that requirement.

I'm not aware of any rule that would say that aggregated objects should inherit properties of their parents. If you want this to pass, you should repeat the properties on child element.

A stair within a stair is not common, I would rather model the child object as IfcStairFlight.

[michaeldejong]

Thanks for the insight, Artur! I thought that nested IFCSTAIR was a bit weird indeed.

And I'm somewhat glad to hear that this way of interpreting the model isn't something you're aware of. IFC and IDS are both pretty strictly defined and documented, so at least it doesn't look like I missed some documentation somewhere. That's quite a relief.

I think I've figured out the root cause though. I've investigated a number of files now, and it seems that this nested IFCSTAIR situation occurs (sometimes), when stairs are created in Revit using the NLRS Loadable Family for stairs (a Dutch standard for Revit projects).

Unfortunately neither me, nor my clients can fix the root case of that. I think the best way forward for now, is to write some custom validation code myself, as I don't think I can model these restrictions with the IDS 1.0 specification schema. I don't want to turn this issue into a feature-request, but to make this work in IDS I'd need to exclude IFCSTAIR entities that have another IFCSTAIR as their parent. That would probably require something like cardinality="PROHIBITED" on facets in applicability (not to be confused with maxOccurs="0").

<applicability>
    <entity>
        <name>
            <simpleValue>IFCSTAIR</simpleValue>
        </name>
    </entity>
    <partOf relation="IFCRELAGGREGATES" cardinality="PROHIBITED">
        <entity>
            <name>
                <simpleValue>IFCSTAIR</simpleValue>
            </name>
        </entity>
    </partOf>
</applicability>

I'd love to hear your thoughts on this, but otherwise I'm ok with closing this issue.

[atomczak]

How about cardinality="PROHIBITED" on PartOf facets but in Requirements, not in Applicability?

Applicability: All Stairs
Requirement: Being part of other stairs is prohibited.

[michaeldejong]

If we put such a specification in place, that would unfortunately mean that any IFC file containing such a stair will always fail validation, even if all of the required classifications and properties are present on the parent stairs entity. Since there's currently no way for the architect/modeler to generate a correct IFC from Revit when using NLRS, that would mean that they have no way of passing the validation at all.

What I would like to do instead is to ignore these child stair entities when validating the IFC file, generate a detailed report on the remaining entities, and separately mention in the report that the IFC file contained invalid entities.

[atomczak]

Possible workaround for Revit is to add a property in those parent elements that is not present on child (or vice versa), and use that to filter in IDS.

[michaeldejong]

Yes, that might be an option as well. I'll see what I can come up with. Thanks for all the help @atomczak !