How to ask for occurrences of IfcAirTerminal(Type) in case of IFC2x3?

From IFC2x3 specification: “The occurrences of the IfcAirTerminalType are represented by instances of IfcFlowTerminal or its subtypes.”

Current IDS entity facet does not allow to restrict IfcTypeObject, which would be needed in case of above example for IFC2x3.
Or is there another way to handle this case?

Proposed extension (adding optional typeObject restriction to entity facet) is also relevant for #88.

At some point it was discussed to make, what is currently, partOf more general, so that you'd be able to say something like:

applicability
  entity
    IfcFlowTerminal
  relates
    relationship: IfcRelDefinesByType
    entity: IfcAirTerminalType

or

applicability
  entity
    IfcFlowTerminal
  relates
    attribute: IsDefinedBy
    entity: IfcAirTerminalType

The concern was the introduced complexity for authoring and checking in non-ifc environments, etc.

Therefore this is indeed currently a limitation. typeObject on entity sounds reasonable, but indeed is a bit messy on non-object entities.

One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType. We encode this in a table as part of the spec. Which is also nasty, but would make the IDS compatible with IFC4 and doesn't require a schema change.

Using IfcAirTerminal is most likely the most convenient solution for IDS users (IFC schema version independent). However, I do not like agreements captured in additional tables.

Using the PartOf facet might work as well, although "PartOf" suggests a different semantic meaning. Technicaly, this comes close to the typeObject setting in the entity facet.

Another potential type of confusion is the predefinedType setting: in above example it need to be checked on IfcAirTerminalType (maybe not that critical, but worth to point out).

This is a critical issue. IFC2x3 needs to be supported in IDS v1.0

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

@aothms

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

as an additional thought - about 95% of all IFC file running around in the moment in industry are IFC2x3 files (whether we like it or not), so without a solutiion here and now for IDS 1.0 it will be rather useless for checking MEP models in the moment.

@aothms

We cannot change IFC2x3 and somehow have to deal with this issue. Not sure what will be the best solution or maybe a proper workaround. The alternative proposed by @aothms might be such workaround without touching the schema. Just have to be agreed and documented.

(One other alternative is that we allow IfcAirTerminal even in IFC2X3 IDS'es and write a rule that this expands to IfcFlowTerminal+IfcAirTerminalType.)

I truly dislike this idea.

When we started to develop IDS we tried to define information requirements remaining relatively IFC agnostic, but we have recently moved in closer alignment to the schema.
Injecting mapping behaviours to make an IDS work for multiple schemas seems like something that will complicate implementation a lot.

The way I see it, we are doing all this to make it simple to write code elsewhere in the supply chain to go and get the information in a robust way; if we inject custom behaviours by type this will impact the entire industry when they go and search for this information in models, as they will have to replicate our maps.

I think this is would not be beneficial to the industry.

@CBenghi

I guess there are two sides of the coin here, make it easy for (1) users = IFC agnostic or (2) software implementation = closer to the IFC schema. I was orginally thinking about a new attribute typeObject (more towards 2).
@CBenghi What are you proposing?

There seem to be two sides of the coin, but I see a different coin.
1- create a standard that is symmetric, predictable and therefore easy to implement
2- create a thing that hangs together from exceptions just to support some kind of use-case
I opt for option 1. That choice has consequences. We need to accept the consequences.

We had a seperation between Typeobjects and instances (and where to put property sets) in a previous version of IDS (version 0.5 had it for example). That has been removed by group consensus to keep IDS predictable. I remember there were too many unclarities and questions about how the overruling of IFC would work when defining these things in IDS.
The reasoning back then was to use the rules of IFC when it comes to typing.

For the example of IfcAirTerminalType and IfcFlowTerminal it would mean that requiring one would mean the requirement is according to the IFC schema.
Good documentation and some examples of this would be needed indeed.

@MatthiasWeise

The coin I see here is:

Implicit solution (supplementary lookup table that nobody likes)
Explicit solution (new attribute solely for a very specific case, also not desirable).

I say for devs it's roughly the same, just a bit more work. We'll have comprehensive test cases in both options, so I don't see a big disadvantage or advantage in both solution directions. It's more a conceptual question for me.

But great work on noticing this issue @MatthiasWeise

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

If anybody is after a computer map of 2X3 elements to types I produced this after coming across the same problem in IFC2X3: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/entity_to_type_map_2x3.json

@Moult

@Moult

This is a fundamental problem in IFC, not in IDS, I believe. IFC2X3 did not have the EXPRESS rules that restricted the class-pairs to be used for types and occurrences. I'm not sure it's up to IDS to make up for this shortcoming.

I think the issue is a different one. It's not about enforcing relationship between Object and TypeObject, but rather the ability to select an IfcAirTerminal Object which only exists as a IfcFlowTerminal - IfcAirTerminalType pair in 2x3.

Oh right I see, that's a bit of a weird requirement then. What's the original requirement in plain English?

I really wonder about this discussion, in particular about this statement:

It's annoying that ifc2x3 has these exceptions and I don't think there is a particular clean solution possible in IDS. But for me, the implicit solution at least keeps the IDS schema itself a bit cleaner. Knowing that 2x3 is a 15 year old version, when 2x3 is finally obsolete, we can remove the lookup table from the documentation, but the attribute cannot be removed in a backwards compatible fashion.

I wonder, because you (Léon, Thomas, ..) are proposing exactly this for IFC5 as an improvement!
Citation from your publication (if I remember well it was ECPPM): "Future of the Industry Foundation Classes: towards IFC 5"

We propose to make the element type mandatory, such that the specialization of IfcElement is no longer necessary. A door will become an IfcElement of an IfcDoorType. As a result, more than hundred entities can be removed from the schema.

If it's done consistently it's not an exception anymore.

I think there's two things here for IFC5 we need to remember. Exceptions are painful. That's what we're seeing in this thread. But also, laborious modelling efforts (the complete replication of occurrence and type trees) will make people desperate enough to come up with exceptions (we had a similar discussion in 4.3 with the selects of predefined types, which in the end was rewritten to the more laborious explicit entity types equivalent buildingSMART/IFC4.x-development#90).

We'll have to see how well this IFC5 paper ages, but combined with the latebinding (built element type as string) and pset'ification (favouring psets over direct built element attributes) already happening since IFC4, I don't think this is particular statement is very contentious.

Let's go back on topic.

@MatthiasWeise

We agreed in the call that @MatthiasWeise will write a bit of documentation about this in a PR.

Extend documentation for use of entity facet

Extend documentation for use of entity facet (#301)

Wrap up: documentation already in place, missing one pass/fail test case to verify it.

We have some test cases for this issue at: https://github.com/xBimTeam/Xbim.IDS.Validator/tree/master/Xbim.IDS.Validator.Core.Tests/TestCases/xbim

Happy to contribute if useful

This might also just be out of scope for IDS.
I see no reason to make IDS implementations extra complex just because of weirdness in IFC.

Bear in mind that without some kind of solution to this it will be pretty much impossible to use IDS for MEP use cases when checking IFC2x3 models. It's not just AirTerminals - there's 50+ IFC types that can't easily be identifed due to IFC2x3 'weirdness' and the IDS decision not to support Types for entities.

@atomczak

@atomczak your wrap-up above says the documentation is in place and the one thing missing is a pass/fail test case to verify it. Opened #458 with that.

A pass fixture where an IFC2X3 IfcFlowTerminal typed by IfcAirTerminalType matches the entity facet IFCAIRTERMINAL, and a fail fixture using the same specification against an element typed by IfcElectricApplianceType instead. Validated against Schema/ids.xsd and functionally against IfcOpenShell's IfcTester, plus a third untyped control to confirm the applicability facet actually selects the instance rather than matching nothing.

Not claiming it closes the issue. This thread is long and I have not verified every other point in it is settled, only the fixture gap you flagged.

One thing noticed while checking the table: it differs between branches. development has the corrected values, IfcSpaceHeater mapping to IfcEnergyConversionDevice and IfcVibrationIsolator to IfcEquipmentElement, while ver/1.1.x still carries the earlier ones. Mentioning it in case the backport matters to you; IfcAirTerminal is unaffected either way.

Add IFC2X3 occurrence type mapping testcase

Merge pull request #458 from BIMvoice/ids-116-occurrence-type-testcase

Navigation Menu

Repository navigation

How to ask for occurrences of IfcAirTerminal(Type) in case of IFC2x3? #116

30 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

How to ask for occurrences of IfcAirTerminal(Type) in case of IFC2x3? #116

Description

Activity

aothms commented on Nov 14, 2022

MatthiasWeise commented on Nov 14, 2022

dro007 commented on Nov 29, 2022

Moult commented on Nov 29, 2022

MatthiasWeise commented on Nov 29, 2022

TLiebich commented on Nov 29, 2022

CBenghi commented on Nov 29, 2022

MatthiasWeise commented on Nov 29, 2022

berlotti commented on Nov 30, 2022

aothms commented on Nov 30, 2022

Moult commented on Nov 30, 2022

aothms commented on Nov 30, 2022

Moult commented on Nov 30, 2022

MatthiasWeise commented on Nov 30, 2022

aothms commented on Nov 30, 2022

30 remaining items

CBenghi commented on May 17, 2024

atomczak commented on Aug 26, 2024

andyward commented on Aug 26, 2024

berlotti commented on Aug 26, 2024

andyward commented on Aug 26, 2024

petruconduraru commented on Aug 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions