Import/Edit/Export IfcPropertySet and IfcPropertySingleValue

[rockn]

Thanks bernd for testing. I fix the issue with https://github.com/FreeCAD/FreeCAD/pull/91

I would vote for to add this to the current implementation, so they would automatically be grouped similar to materials right?

Yes similar to materials.
I will do it.

And I agree with your statement, I would also be able to filter properties and do some "massive" operation on it.

The main aim of this implementation is first to start handle category (before this feature category wasn't handle) and to show the world (BIM actors and others dev) that FreeCAD is capable to browse/edit Ifc properties.

[saso]

I would vote for to add this to the current implementation, so they would automatically be grouped similar to materials right?

Yes similar to materials.
I will do it.

Is this a complex thing to add? I would find it good to have it before the new release

[rockn]

I would vote for to add this to the current implementation, so they would automatically be grouped similar to materials right?

Yes similar to materials.
I will do it.

Is this a complex thing to add? I would find it good to have it before the new release

Ok, it's done, I keep it simple (no special object for IfcPropertiesConainer) just a simple folder.
Branche :https://github.com/wood-galaxy/FreeCAD/ ... cproperty5
Commit : https://github.com/wood-galaxy/FreeCAD/ ... 37313e7095

[saso]

Ok, it's done, I keep it simple (no special object for IfcPropertiesConainer) just a simple folder.
Branche :https://github.com/wood-galaxy/FreeCAD/ ... cproperty5
Commit : https://github.com/wood-galaxy/FreeCAD/ ... 37313e7095

Yes, simple is ok and it works nice. I was looking where to add the code for it inside importIFC.py

[saso]

Ok, it's done, I keep it simple (no special object for IfcPropertiesConainer) just a simple folder.
Branche :https://github.com/wood-galaxy/FreeCAD/ ... cproperty5
Commit : https://github.com/wood-galaxy/FreeCAD/ ... 37313e7095

so, can this code get reviewed and in to master? i have copied the file in to an existing win dev build and imported a few ifc files to test it, to me it seems like it is working ok.

[rockn]

This gonna be merged soon

I notice something while I was reading an IFC file, there could be IFCProperty for the whole project too !
Anyone know if all IFC object (but in fact the project is not an object in FC) can have IfcProperties ?
Right now I only import IfcProperty for Arch Components based object (that's except Floor, Building and Site)...

Another question : I'm wondering how to handle the "reference" between object and ifcspreadsheet. I found that's it's not easy to find the name of the Spreadsheet in the IfcProperties property of the object.
Should we name the ifcspreadsheet like :
IfcProperties-ObjectLabel ? (but sometimes label are really long...)
or
Add the object Label in a cell of the spreadsheet ? (but we still have to open the spreadsheet to know...)
or
Something else ?

[yorik]

it's merged now!

[rockn]

Thanks yorik

I have imported an IFC, 20 Mo, whith the IfcSpreadsheet option, that give something like 4000 arch objects and 2000 spreadsheets .
The load time is still horrible but I notice another slowness when I open a spreadsheet.

I think it comme from the Spreadsheet/Expression system, it look like for each little interaction with the spreadsheet, the document is "reindexed".
Open a spreadsheet object take 10 minutes a least and i get a lot of this in the output from the terminal :

Code: Select all

accepting rule at line 149 (".")
--accepting rule at line 275 ("Int")
--accepting rule at line 149 (".")
--accepting rule at line 275 ("Int")
--accepting rule at line 149 (".")
--accepting rule at line 275 ("Int")
--accepting rule at line 149 (".")
--accepting rule at line 275 ("Escalier")
--accepting rule at line 144 (" ")
--accepting rule at line 275 ("coulé")
--accepting rule at line 275 ("Escalier")

Code: Select all

#--(end of buffer or a NUL)
#--accepting rule at line 144 (" ")
#--(end of buffer or a NUL)
#--EOF (start condition 0)
#--accepting rule at line 149 (",")
#--accepting rule at line 149 (",")
#--(end of buffer or a NUL)
#--accepting rule at line 144 (" ")
#--(end of buffer or a NUL)
#--EOF (start condition 0)

[yorik]

Yes the spreadsheet stuff is still "fragile", and prints a lot of debug info. I suppose we need to be patient with it, as things will stabilize, it should become faster and more solid...

In any case, I feared that indeed creating a spreadsheet for each object could be explosive But after 0.16 release I'll work on my idea of using Spreadsheet::PropertySheet instead...

[eivindkvedalen]

Thanks yorik

I have imported an IFC, 20 Mo, whith the IfcSpreadsheet option, that give something like 4000 arch objects and 2000 spreadsheets .
The load time is still horrible but I notice another slowness when I open a spreadsheet.

I think it comme from the Spreadsheet/Expression system, it look like for each little interaction with the spreadsheet, the document is "reindexed".
Open a spreadsheet object take 10 minutes a least and i get a lot of this in the output from the terminal :

When using a debug build of FreeCAD, loading spreadsheets are horribly slow, yes. I just recompiled in release mode, and reading gets a 10x speed-up for Spreadsheet objects. The main contributor is the parsing of the actual expression.

I also noticed another thing: when loading objects, the create time goes up with the number of objects, from about 1ms to 5ms during the ~6000 objects. The time seems to vary linearly with number of objects, so it might be worth looking into whether the data structures holding the document objects could be made better (constant or logarithmic).

After loading, if FreeCAD is slow to work with, I would guess it is the auto completer. That data structure is being rebuilt very often.

I'll submit a pull request to remove the excessive output; it has done it's mission now.

Eivind