Support for a One-to-Many (non-type) of 'Group'.

[theoryshaw]

For IFC Design Transfer View, is it possible to support one-to-many (non-type) Groups?

i use the word 'Groups', as a stand-in for the concept described below. A better term might be designated

example...

• A BIM file, from Vendor X, contains 10 instances of #Group Z. (Group Z is composed of a wall, a column, and a piece of furniture, for example) →
• This BIM file is exported, via IFC, and in turn imported into Vendor Y's BIM file. →
• Within vendor Y's program, a user changes/modifies the definition of #group Z. This change is, in turn, propagated throughout the 10 instances of #Group Z , within vendor Y's file.

[AngelVelezSosa]

I would think that would be entirely dependent on the CAD application, as I doubt that the applications deal with groups of entities in a consistent fashion. In Revit, for example, there are several ways to have such a concept. Using the one that would probably be the most relevant, the Group element, it would work similar to what you describe. However, individual group members could have differences - for example, that wall in one instance of the group might not be joined to another, but in another it would be. So I think it would probably be beyond scope to force any particular use.

[theoryshaw]

Could a lowest common denominator functionality be found?

Perhaps a 'referencing' type of function. (xrefs, hotlinked modules, linked files, etc.)

Almost every BIM application that i know of, supports this.

Could possibility be a general approach to start breaking down these monolithic, and typically humongous, IFC files.--making them a little more agile, and modular in nature.

@import foo.ifc
@import bar.ifc
@import baz.ifc
@import qux.ifc

@export foo.ifc
@export bar.ifc
@export baz.ifc
@export qux.ifc

[theoryshaw]

...also, different BIM applications deal with other 'core' BIM objects/functions such as wall, ceilings, structure, in differing degrees, but IFC still can address them .

The concept of one-to-many (one definition to multiple instances), is so core to so many BIM applications that if not accommodated to some degree in the 'Transfer View' a lot of time saving intelligence will be lost when the other party 'picks it up' on the other end.

Imagine transferring your code to another party, and loosing your Classes, Constructors, and Prototypes. :)

[jwouellette]

Ryan,
I am going to politely suggest you drop this, for now... or risk further alienating the developers involved with this effort.

As far as I can see, there is no corresponding concept in IFC4 and we can't just make one up now.

Yes, it is a handy convenience, but a great deal of root technical work needs to be done within the semantic and relational structures of the IFC specification to accomplish this. That work for IFC4 is LONG past. If you want future support, I suggest you make a request in JIRA-IRD and hope for the best.

I see so much other stuff that needs to get done and this does NOT qualify as "low hanging fruit". I am also NOT in favor of "hacking" anything together at this point, either.

[theoryshaw]

From what i can gather, from the pulse of the following discussions and documentation, it's quite doable within the present IFC4 schema--namely through the ifcmappeditem and ifcelementassembly entities.

• @jmirtsch (in a conversation with @AngelVelezSosa) hints that ifcmappeditem might be the way to address such functionality.
• The following quotes from Section 9.1.4.2 in the IFC 2x Edition 3 Model Implementation Guide @TLiebich outlines similar concepts.

The IFC2x specification allows for the use of mapped representations in order to reuse the shape of a particular object type at all particular instances of this object. The concept of mapped representations can be compared with the concept of a block definition and block insertions within most of CAD systems. The block contains geometric items within a local (block) coordinate system, which can be inserted one or several times into the actual drawing model by using a block reference, including a Cartesian transformation operator, which normally includes scaling.
...
A similar concept is used in IFC2x, where IfcRepresentationMap represents the block definition, and IfcMappedItem represents the block insertion. The IfcRepresentationMap can include any representation by containing one or several IfcGeometricRepresentationItem.
...
Beside the term "block", other terms, like cell, macro or library part are used to denote the same or similar concepts

• @MatthiasWeise on the other github issue where this was brought up, hinted that IfcElementAssembly/IfcElementAssemblyType could be used as well. Here @jmirtsch commented that IFCElementAssembly could be appropriate as well.
• Also, from my perspective, it would seem to make sense to implement this concept in the up and coming Library View, as well. Do we not want to standardize a workflow whereby a change in the manufacturer's model is easily propagated throughout all the instances of it in our model?

I would, by all means, drop the topic if it didn't seem feasible within the present schema to address such functionality, but from my interpretation of the discussions/documentation above, that it's quite doable. Please correct me if i'm wrong.

[jwouellette]

But there is a huge difference between a manufactured object, or even a
sub-assembly of a larger system, and an entire unit plan.

These ideas are merely "hacks" based on one construct to accommodate an
entirely different one. I'm frankly tired of such hacking and would rather
do it the right way, at the core, instead if rushing a "solution". We do
too much of this, right now, across the industry, and too much of it in
IFC2x3. Thankfully, much of it was cleaned up in IFC4, with good work and
clear direction after dealing with shortcomings in practical application.

There is a time and place for your requests, as I noted, which can better
address such user requirements. Look forward to IFC5, or beyond, and trust
that the MSG can make it work in a way that is fundamentally sound and
logical.

Meanwhile, there is so much else to do...

On Friday, June 20, 2014, Ryan Schultz notifications@github.com wrote:

From what i can gather, from the pulse of the following discussions and
documentation, it's quite doable within the present IFC4 schema--namely
through the ifcmappeditem
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcgeometryresource/lexical/ifcmappeditem.htm
and ifcelementassembly
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcproductextension/lexical/ifcelementassembly.htm
entities.

• @jmirtsch https://github.com/jmirtsch (in a conversation
  http://sourceforge.net/p/ifcexporter/discussion/general/thread/fad5b2f8/?limit=25#a08f/078a
  with @AngelVelezSosa https://github.com/AngelVelezSosa) hints that
  ifcmappeditem might be the way to address such functionality.
• The following quotes from Section 9.1.4.2 in the IFC 2x Edition 3
  Model Implementation Guide
  http://www.buildingsmart-tech.org/downloads/accompanying-documents/guidelines/IFC2x%20Model%20Implementation%20Guide%20V2-0b.pdf
  @TLiebich https://github.com/TLiebich outlines similar concepts.

The IFC2x specification allows for the use of mapped representations in
order to reuse the shape of a particular object type at all particular
instances of this object. The concept of mapped representations can be
compared with the concept of a block definition and block insertions within
most of CAD systems. The block contains geometric items within a local
(block) coordinate system, which can be inserted one or several times into
the actual drawing model by using a block reference, including a Cartesian
transformation operator, which normally includes scaling.

...
A similar concept is used in IFC2x, where IfcRepresentationMap represents
the block definition, and IfcMappedItem represents the block insertion. The
IfcRepresentationMap can include any representation by containing one or
several IfcGeometricRepresentationItem.
...
Beside the term "block", other terms, like cell, macro or library part
are used to denote the same or similar concepts

@MatthiasWeise https://github.com/MatthiasWeise on the other github
issue where this was brought up, hinted
buildingSMART/mvdXML#3 (comment)
that IfcElementAssembly/IfcElementAssemblyType could be used as well.
Here
http://sourceforge.net/p/ifcexporter/discussion/general/thread/fad5b2f8/#819b/4fd4
@jmirtsch https://github.com/jmirtsch commented that
IFCElementAssembly could be appropriate as well.

Also, from my perspective, it would seem to make sense to implement
this concept in the up and coming Library View
https://github.com/BuildingSMART/IFC4-CV/blob/master/IFC4_Library_View.md,
as well. Do we not want to standardize a workflow whereby a change in the
manufacturer's model is easily propagated throughout all the instances of
it in our model?

I would, by all means, drop the topic if it didn't seem feasible within
the present schema to address such functionality, but from my
interpretation of the discussions/documentation above, that it's quite
doable. Please correct me if i'm wrong.

—
Reply to this email directly or view it on GitHub
#16 (comment)
.

[jwouellette]

Your correlation to the Library View is incorrect. That is a perfect example of Typing with instance overrides, when necessary.

At the root of the problem, maybe you misunderstand Type/StandardCase?

What you want is something like IfcRoof, with similar relational structures and hierarchy, but a different semantic naming that "fit" in the overall schematic and logic. That is why I think it needs it be addressed as an item for future development, say IFC5, where all the details and semantics can be properly worked out.

[theoryshaw]

I'm thinking more along the lines of assemblies and modules that would be composed of a variety of IFC Types/StandardCases?

A prefab bathroom module repeated en masse throughout a hospital or hotel, for example.

In a 'design transfer' scenario, I would just like to keep this definition/instant correlation intact when i transfer the file to another party. It would save a tremendous amount of time.

[AngelVelezSosa]

The issue in my mind is the original one I mentioned. There are ways to group things in IFC, to be sure - IFCGROUP comes to mind. However, those are generic groupings that don't necessarily correspond to a particular workflow. The prefab bathroom modular you presented, for example - it is farily clear how the first instance could be made into a group. However, in these cases, there are always slight differences. Do you allow mirrored/scaled copies of the group? Do you allow for design variations (e.g. are the corner units different from the middle ones)? How do you deal with wall connection data, space/zone/building story containment data, and other relationships that change from group instance to group instance? Can the various applications support these things, or are we truly "dumbing it down" to AutoCAD blocks? In that case, why not just use DWG and AutoCAD blocks? Is there a group instance vs group type entity? There can even be slight geometrical differences - imgaine that your prefab bathroom modular is installed on a story with a slanted or non-flat floor or ceiling.

These are all significant questions that need to be considered both in the theoretical framwork ("this is how we'd like a generic CAD system to deal with this") and a practical framework ("Application X doesn't allow design variations; Application Y requires that all group instances are on the same building story", etc.)

Given the upcoming mandates in Northern Europe, we should first concentrate on trying to satisfy those. Then I think, when that's done, we can move about how to extend collaboration. I agree that your workflow is a good one, I just think we have more fundamental issues to solve first before we get to this next level of intelligence, which should definitely be on a roadmap.

[theoryshaw]

Sounds good... thanks guys.

[theoryshaw]

related discussion: http://forum.freecadweb.org/viewtopic.php?f=23&t=12131

[theoryshaw]

Apropos to this discussion: https://www.researchgate.net/publication/305770614_Modeling_of_repetitive_IFC_Building_Elements_using_the_Flyweight_Design_Pattern_Approach
Thought I'd share.

[NickNisbet]

This capability is already in the IFC schema, for geometry look under ifc type product and IFC shared representation. The challenge is on the bim authoring tools to exploit this, or to readers to discover and exploit this.

The same applies to attributing. Any IFC property set is intended to be assigned to many elements, or to an IFC type product which specifies many elements, especially where the properties are intrinsic. Alternatively IFC group, IFC system and IFC zone offer a mechanism for the mass assignment of a property set where the properties are extrinsic.

So the rationalisation is possible already. But the bim authoring tools do not necessarily capture the design logic that produces this commonality, nor detects it when exporting to IFC.

Sent whilst away from my desk.

Regards,

Nick.

Nicholas Nisbet MA(Cantab) DipArch(UNL)
Director: AEC3 UK Ltd
Web: http://www.aec3.com
E-mail: nn@aec3.com
Direct: +44 (0) 1494 714 933
Mobile: +44 (0) 781 616 8554
Skype: nicholasnisbet
Registered Address: 46 St Margaret's Grove, Great Kingshill, High Wycombe, Bucks, HP15 6HP, UK
Registered in the UK: 03484881

Vice-Chair: buildingSMART UK Chapter
ifcXML Coordinator: buildingSMART Model Support Group
Web: http://www.buildingsmart.org.uk/
E-mail: nn@buildingSMART.org.uk

********** Confidentiality Notice **********.
This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.

On 11 Oct 2016, at 15:54, Ryan Schultz notifications@github.com wrote:

Apropos to this discussion: https://www.researchgate.net/publication/305770614_Modeling_of_repetitive_IFC_Building_Elements_using_the_Flyweight_Design_Pattern_Approach
Thought I'd share.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.