IfcMappedGroup

[theoryshaw]

Related to https://github.com/buildingSMART/NextGen-IFC/issues/61

I'm sure the following proposal needs a lot of love, but as a power user, I'm taking a stab at it.

In essence proposing a way to map IfcGroups...

The following example illustrates mapping a group, within a group.

Formal representation

[Moult]

A heads up that this is one of the "big issues" that will probably be an IFC5 thing, potentially together with proposals on simplified geometry instancing.

Although conceptually this is a group of objects, I think an important aspect of IFC is that there is a spatial hierarchy and objects should appear "once" in the hierarchy. So I would approach this with three potential strategies:

1. How would IFC products be included and referenced multiple times in the spatial hierarchy in a valid way? Would a new "group" object be in the spatial hierarchy, then that is repeated?
2. How is this dealt with differently to aggregation? Maybe it is just aggregation but with extra semantics that multiple aggregations must mirror their parts?
3. This may be largely a phase-specific concept. As the building moves towards construction and as-built, using "mapped groups" becomes less and less practical, as especially during as-builts it may be that there are lots of variations on supposedly typical floors. Can a mapped group transition into partially mapped, partially bespoke entities? What makes it easy to take things in and out of a group, and when you remove an item from a group, what happens?

Just brainstorming.

[aothms]

I agree with (my interpretation of your) point 2.

I think what we should have is the combination of decomposition and instantiation. For example a detailed window being decomposed into a set of elements, and then just instancing this window with the parts carrying over.

And then why not apply this to spatial zones or building storeys as well. So that they can be instanced. I think the semantics of IfcGroup don't really align to this idea, but I think in early design, why not instantiate a bunch of populated building storeys? Or on a larger scale, why not instantiate a couple entire buildings for urban development.

Although quite early on indeed the question of overriding comes into play. It's not impossible to handle I think, e.g in the instance you could override a part by supplying an element with the same name/id, quite analogous to how overriding of properties is handled. Not too sure about this one though.

[yorikvanhavre]

Indeed an IfcGroup seems just some form of "user-made" classification.. I guess it's not what Ifc constituents had in mind for, say, a repeatable bathroom stall

Maybe the problem is actually two-fold:

1) how to group ifc entities in a way that the result is a valid building element 2) how to instantiate objects?

For 1) there is IfcElementAssembly that does just that, but then we loose specific types, and as @aothms says we should be able to define an IfcWindow as an assembly, and still access for example the handle as a separate Ifc entity.

And yes, if it is conceptually admitted that an element can be an instance of another, why stop at just one type...

[theoryshaw]

Again, this is probably blasphemous to the IFC gods, but could something like this inform how we approach this? https://forums.buildingsmart.org/t/a-small-step-to-parameterizing-ifc/3223

the entire structure is reusable classes... kinda like a programming language.

[theoryshaw]

In an effort to prevent the Perfect to be the enemy of good how about typing an Aggregation? We were so close once. :)

[theoryshaw]

related: https://github.com/buildingSMART/IFC4-CV/issues/16

[SergejMuhic]

I am not sure what all your requirements are but just looking at the snippet, are you not talking about IfcMappedItem?

[theoryshaw]

Hi @SergejMuhic, IfcMappedItem only maps the geometry of a IfcProduct in a 1 to many relationship.

This proposal is looking to map groups of geometry, so to speak--a repeating bathroom module or repeating unit type, for example, composed of multiple IfcProducts.

[SergejMuhic]

Semantically, this is quite unclear. IfcGroup does not carry any geometry, so you are basically applying a transformation operator to a non existing target. Even worse, to a relationship. What does this proposal solve? I would argue that it is more confusing than what we currently have. The software still has to loop through all the grouped products and their geometries, cache the operator and apply to each individual product.

The way you would use it at the moment is have the geometry on IfcTypeObject level for each grouped product. Then apply IfcMappedItem to the repeating occurrences. Does this not do exactly what you expect? It is semantically clearer where the types of object carry geometry and on the product level the occurrences are grouped.

[theoryshaw]

I'm open to whatever approach we feel is the most efficient. I do like @aothms idea of repeating spatial zones or building storeys.

I do, however, feel finding a solution to this, should be high priority--as it's such a core functionality of any BIM program.

Furthermore, any program that uses NativeIFC, such as BlenderBIM, as their file format, has their hands tied until this core concept is reflected in the schema somehow.

[SergejMuhic]

I do like @aothms idea of repeating spatial zones or building storeys.

Could you point me to this? I could not find references to spatial zone.

[theoryshaw]

this comment above.

"And then why not apply this to spatial zones or building storeys as well. So that they can be instanced."

[theoryshaw]

some thoughts from @brunopostle https://app.element.io/#/room/#OSArch:matrix.org/$rO4Ayur-_Rq4KzYZm7j0t-8wR8_EegWARsz34-S0cTc