Part of the IFC-information

This forum section is only for IFC-related issues
paullee
Veteran
Posts: 5098
Joined: Wed May 04, 2016 3:58 pm

Re: Part of the IFC-information

Post by paullee »

doubters wrote: Sun Sep 11, 2022 8:11 am I think the solution to the problem is to simply make the field output from the IFC properties customizable. Then everyone will be able to display exactly what he needs.
Could you make a simple example ? I am not familiar with IFC properties.
doubters
Posts: 168
Joined: Fri Mar 18, 2016 12:53 pm

Re: Part of the IFC-information

Post by doubters »

After a little thought, I decided that the user does not need to configure anything at all: if he added some IFC properties, then they should automatically appear in the form of lines:
Attachments
5.gif
5.gif (866.43 KiB) Viewed 3127 times
2.png
2.png (66.47 KiB) Viewed 3127 times
4.png
4.png (47.54 KiB) Viewed 3127 times
3.png
3.png (60.94 KiB) Viewed 3127 times
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Part of the IFC-information

Post by yorik »

Hm that's interesting... I thought at first this would be annoying because it would display too many entries in the properties view, but this looks nice... How did you manage to enter the psets as a drop-down list??
doubters
Posts: 168
Joined: Fri Mar 18, 2016 12:53 pm

Re: Part of the IFC-information

Post by doubters »

I edited the screenshot in a raster editor to visualize my thought :)
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Part of the IFC-information

Post by yorik »

Ah too bad :D
In any case, that's interesting.. Indeed that's exactly what we would need. There is an App::PropertyMap that's actually exactly that (a string:string dictionary). All we need is a property editor for it. I'll have a look, might not be too hard to implement...
User avatar
Moult
Posts: 321
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Part of the IFC-information

Post by Moult »

Psets are pretty critical on any medium to large project. For example, storing the fire rating and acoustic ratings of walls are done in psets. Storing if something is load bearing or external is done in psets.

Psets are pretty efficient. If you have a pset that is common to all walls of a type, you store it on the type, and then all occurrences inherit that pset, so it is not necessary to define them again and again. To properly make use of psets, it would be important for FreeCAD to also support types and occurrences.
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Part of the IFC-information

Post by yorik »

Moult wrote: Sun Oct 16, 2022 1:00 pm Psets are pretty efficient. If you have a pset that is common to all walls of a type, you store it on the type, and then all occurrences inherit that pset, so it is not necessary to define them again and again.
Interesting, I never thought of that.. Indeed that seems to be a far better use of psets.
Moult wrote: Sun Oct 16, 2022 1:00 pm To properly make use of psets, it would be important for FreeCAD to also support types and occurrences.
Indeed. That's something easy to address I think, as FreeCAD already uses the concept (one "master" wall with cloned instances around), I think we should build on that.
Maybe, everytime we detect that a wall (or anything else) has clones, that is, more than a single-use, we create a type.

@Moult do you know if it's possible to override the type pset? I imagine, for ex. a wall type with a fire resistance of 1h. then an instance of that wall type would override the fire resistance value to, for ex. 1/2h?
User avatar
Moult
Posts: 321
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Part of the IFC-information

Post by Moult »

Yes, if the same property is assigned on the occurrence, it overrides the type.

What you've proposed is a good start but it would still be nice to manage types separately. Many types do not have geometry, such as walls, slabs, beams, columns,etc In these cases, the wall type simply defines the construction layers (as is standard in architectural documentation), or the beam type defines the profile cross section (as is standard in structural documentation). So in these very common scenarios you'd need a way to manage them.

But yes, automatic types for reused geometry would be a sensible start and would work for things like doors, windows, furniture, etc.
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Part of the IFC-information

Post by bernd »

Just wanted to say we do make heavy usage of properties an psets too. Furthermore we do automaticly control them by BIMTester :D

two reasons ...

One:
Our awarding authority wants us to fill the modell with lots of properties. They gave us the property structure. This is even part of the contract.

Two:
We do fill the modell with own propterties to do some evalutations with the model. This mostly due to calculate costs.

I have not made heavy usage of the type since the CAD we mostly use does not make smart support of it.

bernd
doubters
Posts: 168
Joined: Fri Mar 18, 2016 12:53 pm

Re: Part of the IFC-information

Post by doubters »

bernd wrote: Wed Oct 19, 2022 9:31 pm
We do fill the modell with own propterties to do some evalutations with the model. This mostly due to calculate costs.
I completely agree. Some users transfer monetary calculations to third-party programs, which, in my opinion, is wrong: in a digital model, absolutely all information should be stored inside this model.
Post Reply