[Discussion] Addressing IfcTypes

[carlopav]

Another hot topic for next week!
reference: https://forum.freecadweb.org/viewtopic. ... 00#p397622

In Ifc, each IfcProduct can be based on a realtive IfcTypeObject (sorry for misplelling it). Imagine a WindowType, and many Windows that are exactly the same, but with different height and width. Quite common in construction, isnt'it?

Since the support of Type/Instance for Arch is on the orizon (or not yet, but soon), maybe we need to discuss a much wider implementation in Arch.

It would be a pity for example to have a new wall object but have to change it all of a sudden to match this pattern. So, why not thinking it right from the beginning?
My doubts are about which properties should the Wall have and which others should the WallType have.
How to link them, also if they are in different documents, how to have an always updated list of all the available Types.
The implementation with windows and other components seems a far easier task.

Also it would be a pain to be forced to use types if you want to draw something really simple, so i'd like to keep the user free to decide if he wants to use the Type approach or not...
@yorik, @everyone else, what do you think?

[yorik]

Honestly I still didn't look very deep in the Ifc*Type objects in IFC, and don't really see very well yet where it might fit. They seem basically to group common attributes of a same set of windows, such as materials or ifc properties.

Looking at http://dcom.arch.gatech.edu/aci/cic/sch ... owtype.htm now... basically several windows can have a same IfcWindowType that defines common things for all of them:

- "opening type" (2 panels, 3 panels...) that seems a bit dumb to me. For ex I often do 4-panel windows and it's not even there in the list
- material: That's a good idea indeed.
- ifc properties: That's a good idea too
- shape: They say to use mapped representations for this, which we already do (for windows that are clones). It's the most interesting part, and it's fully implemented already.

I think we could add a system, somewhere in Arch, to propagate changes made to materials or ifc properties to all siblings (clones) of an object. Then in FreeCAD, we would have everything we need: Several objects with a same, linked shape, and same materials and same ifc properties. Then it would not be too much work, at IFC export, to detect those and store an Ifc*Type object. But it seems not to be available for any type of object, though.

On import, objects that share representations are already imported as clones. This should then just be extended to look for related Ifc*Type objects and get material and IFC properties from there.

[carlopav]

I had a real interesting conversation with Dion Moult this morning.
My brain is still boiling so i need to cold it down...

Anyway. Ifc Types are a really cool thing!

Think about it in a similar way to how a construction project usually works: you have a window schedule where you list all the windows, that will go to the manufacturer, where you decide how many windows type 1 you want, how many type 2 and so on, their material and their dimensions.

I was thinking to something similar to this 2 implementation:

IMPLEMENTATION 1: TEMPLATE/TYPE/OBJECT (what I was thinking about)

TEMPLATE : The real App::Part parametric object that defines all the features of many similar window types (for example: wood, 1 panel, full glass).

TYPE: A SubShapeBinder of the App::Part, that inherits all the properties of the template, plus set the dimensions (ex: window type 1: 700x1200mm)

OBJECT: A SubShapeBinder of the SubShapeBinder that tweaks some object specific parameters (like wall width to generate the wall void)

In this scenario, the TYPE is more adherent to Ifc specifications from what I understood. For roundtripping it's not so good because we would just export dumb non parametric types.

IMPLEMENTATION 2: TYPE/OBJECT (what could be also feasible)

TYPE: The real App::Part parametric object that defines all the features of many similar windows objects (for example: wood, 1 panel, full glass).

OBJECT: A SubShapeBinder that tweaks some object specific parameters (ex: window type 1: 700x1200mm + wall width to generate the wall void)

In this second scenario of course the windows schedule should be generated on demand scanning every drawing object belonging to a certain type, and probably also if we want to export types to Ifc. Do not know if this could be easy for roundtripping, probably yes because we could export the type features parametrically.



Something similar can also be used for walls, but I still have to think about it since it's not so clear to me how to implement it...

[yorik]

This looks good to me, specially using app links make it far more suitable to have windows be complex structures with many subobjects.
But, as always, we should take care of not forcing anything on the user. We should always assume a window can be just any object coming from anywhere in FreeCAD, that users designed themselves in a way we can't even think of , and just want to declare that it is a window.

I think we should definitely design an IFC types system that can analyze a model, and "deduce" when a type should be used. If we then design a workflow in FreeCAD that allows users to control it better, perfect. But, like with the IfcProject/IfcSite/IfcBuilding/IfcBuildingStorey annoyance in IFC, in FreeCAD we should be able to forget about it and design our model the way we want.

Also we should make a list of which IFC classes have a Type class, I guess it's not all of them, as usual in IFC Not sure how we deal with that, if we can deal with Column types the same way as window types, etc.

That's a point where Moult and I sometimes disagreed in the past, he thinks we should cope more strictly with IFC, and I don't think FreeCAD should be harmed by IFC limitations... But this disagreement is a good thing, it forces us to find better solutions!

[carlopav]

But, as always, we should take care of not forcing anything on the user. We should always assume a window can be just any object coming from anywhere in FreeCAD, that users designed themselves in a way we can't even think of , and just want to declare that it is a window.

I think we should definitely design an IFC types system that can analyze a model, and "deduce" when a type should be used. If we then design a workflow in FreeCAD that allows users to control it better, perfect. But, like with the IfcProject/IfcSite/IfcBuilding/IfcBuildingStorey annoyance in IFC, in FreeCAD we should be able to forget about it and design our model the way we want.

Definitely... this is one of the main points I do not want to renounce. And it's really complicated to deal with that in an IFC perspective.

I want to share a doubt that is increasily mounting in me. It's about semantics of window and doors and it's geometry. I'll try to explain it.
Since a month I was looking for a name that could include both window and door. In Italy we have "Infisso" or "Serramento" that both refer to the family of doors, windows, shutters.
I found "Opening". And I was quite pleased.
Then talking with Moult, he pointed out:
"Mind that in IFC the Opening in the wall is not part of the window!" and at the beginning I just answered, well, no problem.
and:
"Think about IfcTypes as a window schedule that you will have to send to the window manufacturer". And I sayd... : "Ok!, no problem again".

But keep thinking about that and trying to implement it... well there is a problem indeed.

The window I'm experimenting have basically 3 components:
1) the window itself(the one that I expect to by from the manufacturer)
2) the window sill (that I will send to another manufacturer)
3) the wall void, that is, semantically the real opening, and in fact whatever object we want to cut from the wall.

So, frame, addition, subtraction.

In a perspective of an IfcProduct, we have 2 products (window and sill). Is that right?

So... what I was thinking:
Can we have an Opening object, that have 3 shape property:
1 is the window itself, cloned from a certain window type, or just binded from a window template
2 the void object shape
3 the wall additions shape, being the sill or whatever else.

so, we keep the possibility to extract a window type and create a schedule on the fly, or to define window types before inserting them into the model. You probably would ask: "What's the advantage?"
Well, probably that the window type is just the pure window frame, without the sill (exactly what the window manufacturer wants).
The Opening object never have to be listed in documentation (no Opening types), so Opening objects can differ by having a different WallWidth property.
From the user point of view this won't change much, he will just create an opening and decide if it have to link inside a window type, a door type, or nothing, leaving it just as a hole...

Hope I was able to describe the concept properly...

Edit: i did not realize that IFC has IfcOpeningElement. Is seems it does not associate a window frame, but this sound like a good idea to me.

[carlopav]

https://standards.buildingsmart.org/IFC ... lement.htm

IfcRelFillsElement adopt exactly this behaviour:

ifcrelfillselements-fig1.png (41.09 KiB) Viewed 837 times

[onekk]

As carlopav stated the ifc is correct at least in semantic, the order:

WALL has VOID (a void could simply a void with no elements to be put in)
VOID has OPENING (this means that there are something that go in this void?)

That seem to pose no problem in implementation

if VOID has an OPENING:
OPENING has e RELFILL (? maybe is not correct the image is not clear) this Relfill could be a door or a window?
RELFILL has DOORS and WINDOWS (maybe taken form an "OPENINGS library") and CUSTOM

but as yorick said a DOOR or a WINDOW could be every FreeCAD objects so a user could design his own. (the same must de true even for a RELFILL).
maybe in the FreeCAD implementation, not following the hierarchy of Ifc and OPENING could have a RELFILL children that could be.

but if there is an "OPENINGS library" this library must have RELFILL, DOORS and WINDOWS, as at east in Ifc a DOOR or WINDOWS must have a RELFILL.

even CUSTOM objects that "fill" the OPENING must have this hierarchy, i.e an OPENING must have a RELFILL object that have a children object that is a DOOR or WINDOW or a CUSTOM?.

with a designed from scratch, i.e not using an "OPENINGS library" there must be an OPENING > RELFILL type CUSTOM > DOOR or WINDOW type CUSTOM.

Sorry for the intrusion, but thinnking in terms of hierarchy and "databases" this have to be clear prior to make the infrastructure.
Hope te have been clear.

Regards

Carlo D.

[carlopav]

ref

Well, i'm happy you stepped in.
From what i did understand, what happens in Ifc is (please correct me if I'm wrong):

Code: Select all

FLOOR contains WALL
WALL -> contains -> OPENING
FLOOR -> contains -> WINDOW
OPENING -> is FILLED by -> WINDOW

WINDOW -> Type is -> WINDOW_TYPE_1

What I was thinking to do in FreeCAD is:

Code: Select all

WALL -> contains -> OPENING
OPENING -> contains -> WINDOW

WINDOW -> Type is -> WINDOW_TYPE_1

Everything good until you also want the Opening to have a window sill (wall addition) and a wall subtraction shape...
We can use the ShapeGroup object, the App::Link, the PartDesign::SubShapeBinder, the Draft::Clone code to build this kind of special object, but I still do not understand exactly how...
Because I wish it to be a single object (or maximum 2 objects as the actual window object)....

[carlopav]

Some more thoughts on a possible, non rigid, document articulation:

Code: Select all

Building (FreeCAD Document)
└── GroundFloor (Arch.BuildingPart)
    └── Walls (Std::Group)
        └── Wall001 (Arch.Wall)
            └── Opening001 (Arch.Opening)
                └── Window001(App::Link to WindowType001)
            └── Opening002 (Arch.Opening)
                └── Window002(App::Link to WindowType001)
            └── Opening003 (Arch.Opening)
                └── Window003(App::Link to WindowType002)
            └── Opening004 (Arch.Opening)        

└── Types (Std::Group)
    └── Windows (Std::Group)
        └── WindowType001 (WindowSimple 100x150)(PartDesign::SubShapeBinder of WindowSimpleSinglePanel, that dimension the template)
        └── WindowType002 (WindowSimple 60x150)(PartDesign::SubShapeBinder of WindowSimpleSinglePanel, that dimension the template)

WindowTemplate001(FreeCAD Document)
└── WindowSimpleSinglePanel(App::Part containing all the necessary parametric geometries of the window frame

Of course when you add an Opening object it would be nice if you can already choose the right TemplateWindow you want to insert and the window type is created on the fly to match the Opening object dimensions...
Or you could chose to not create and associate a type and just link the template directly with a configured App::Link.

[onekk]

but from what I was able to understand:

Code: Select all

Building (FreeCAD Document)
└── GroundFloor (Arch.BuildingPart)
    └── Walls (Std::Group)
        └── Wall001 (Arch.Wall)
            └── Opening001 (Arch.Opening)
                └── RefFill (App::Link to RefFill Type)
                			OR Custom (App::Link to another FC.Shape Object similar way to window custom type)
                			OR None if a such a "component" is not needed
                	└── Window001(App::Link to WindowType001)
                		OR 
                	└──  Door001(App::Link to DoorType001)
				OR 
				Custom (App::Link to another FC.Shape Object as told by Yorick)

In envisioning of a future "Opening Library" RefFill, Windows and Doors are in thi library and used when needed, if not a custom designed object is needed/wanted

(RefFill maybe the wrong term for the "Frame" that is holding the window or the door to the wall)

This way it resembles more the Ifc type, but is maybe a normal way to do building, I'm not an expert, but to explain to carlopav (hole, frame, door) (buco, telaio, finestra) chosen by design in this strat phase seems to be a more articulated approach.

Regards

Carlo D.