Is there a need for an actual IfcProject / Library element?

This forum section is only for IFC-related issues
User avatar
Kunda1
Posts: 4560
Joined: Thu Jan 05, 2017 9:03 pm

Re: Is there a need for an actual IfcProject / Library element?

Postby Kunda1 » Wed Jun 05, 2019 1:40 am

yorik wrote:
Wed Jun 05, 2019 12:58 am
Just read your article about coordinates, indeed there is more complex stuff under the hood available to the IfcProject than I thought... And indeed this could be an interesting bridge with GIS, at some point we'll need to have projection system info stored somewhere...
Relevant: Thread tracking FreeCAD & QGIS integration
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
User avatar
Moult
Posts: 203
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby Moult » Thu Jun 13, 2019 1:20 pm

Work in progress PR: https://github.com/FreeCAD/FreeCAD/pull/2259

Right now, I've merely duplicated the function of an IfcSite element, which can contain (er, group?) other things. Here's an example below. It still uses the IfcSite icon for now.

I wonder if there is any need to create entities for things like `IfcRelAggregates` and `IfcRelContainedInSpatialStructure`. Or perhaps those types of relationships should be invisible to the user? Thinking out loud ... I don't personally see a benefit.
2019-06-13-230742_437x672_scrot.png
2019-06-13-230742_437x672_scrot.png (29.38 KiB) Viewed 255 times
In addition I'm experimenting with exposing all inherited attributes up to IfcRoot instead of stopping at IfcProduct. Previously the JSON stopped at IfcProduct so there were certain attributes which were locked. Now, as shown in the IfcWall below, there is the full gamut of attributes. It still needs more intelligent behaviour, such as for the global ID as an obvious example, and it does indeed give opportunity for the user to break things, or maybe use GUIDs creatively such as linking other IFC files.
2019-06-13-231739_429x677_scrot.png
2019-06-13-231739_429x677_scrot.png (36.08 KiB) Viewed 255 times
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
yorik
Site Admin
Posts: 11249
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby yorik » Thu Jun 13, 2019 9:56 pm

Note that the GUID is already stored in IfcData. Not sure if it's really useful to have it visible there. Will someone really want to change a GUID manually?

Also, certain of these would be redundant, for ex. Name. And having "Object Type" there might confuse people more than it helps, I fail to see its use, actually... If you think of it, IFC objects have name, long name, description, all simple user-settable strings... I've never seen used more than two of these.

Agree with you for relationships.. Soon we'd have an horribly complex tree, and I don't really see any benefit, I can't think of a kind of relationship that you couldn't create with current tree grouping.

The project object seems good however. Looking forward to see how you plan to implement coordinate systems...
User avatar
bernd
Posts: 7892
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Is there a need for an actual IfcProject / Library element?

Postby bernd » Fri Jun 14, 2019 11:03 am

yorik wrote:
Thu Jun 13, 2019 9:56 pm
Agree with you for relationships.. Soon we'd have an horribly complex tree, and I don't really see any benefit, I can't think of a kind of relationship that you couldn't create with current tree grouping.
It gets even worse if you take these relationships into account ... https://forum.freecadweb.org/viewtopic.php?f=39&t=36824
User avatar
Moult
Posts: 203
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby Moult » Sat Jun 15, 2019 3:05 am

WIP update: there seem to be 4 main types of rooted ifc objects: Products (i.e. those with geometric representation - maybe spatial containers can be a sub category of products?), Contexts (projects, libraries), Object Types (FreeCAD doesn't support this currently, but something we should figure out), and relations (super overengineered by bS, which ideally we should hide and automate as much as possible).

I've done a bit of refactoring. Now arch components implement products, and you can change them to any other ifc product - however you cannot change an ifc product subclass to an ifc context subclass. This makes sense - you cannot change an IfcWall to an IfcProject, because the latter has no representation.

The project element now knows that it is an "IfcContext", and you can switch it to any other IfcContext (for now, only between project and project library). Similarly, you cannot change an IfcContext into an IfcProduct subclass. It also sets up simple attributes now. (Note that coordinates are not a simple attribute, so it'll be implemented differently).
2019-06-15-125533_1920x1080_scrot.png
2019-06-15-125533_1920x1080_scrot.png (39.54 KiB) Viewed 196 times
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
yorik
Site Admin
Posts: 11249
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby yorik » Sat Jun 15, 2019 8:17 pm

Seems cool so far! We need an icon :) Not sure how a project icon should look like...
Moult wrote:
Sat Jun 15, 2019 3:05 am
maybe spatial containers can be a sub category of products?
They are, at the moment, no? I like the idea that a BuildingPart can be either a spatial container or a product itself, so in the future we can use BuildingParts more and more as a kind of assembly object, or "reusable component". This is something not very well defined in IFC...
User avatar
Moult
Posts: 203
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby Moult » Fri Jun 28, 2019 11:48 pm

The PR has progressed to a stage where exporting with an IfcProject is now possible.

Here is the example IFC created:

Code: Select all

[ ... snip ... ]
#19=IFCUNITASSIGNMENT((#13,#14,#15,#18));
#20=IFCDIRECTION((0.,1.,0.));
#21=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#9,#20);
#22=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model',*,*,*,*,#21,$,.MODEL_VIEW.,$);
#23=IFCCOORDINATEREFERENCESYSTEM('EPSG:28356','Australia - 150\X4\000000B0\X0\E to 156\X4\000000B0\X0\E','GDA94','AHD');
#24=IFCMAPCONVERSION(#21,#23,334902.775,6252274.139,4.,1.,0.,0.001);
#25=IFCPROJECT('c3ac687d_f98c_405c_bdf',#5,'SOH','An iconic stage near the Sydney harbour','','Sydney Opera House','Concept Design',(#21),#19);
#26=IFCCARTESIANPOINT((0.,0.));
#27=IFCAXIS2PLACEMENT2D(#26,#6);
#28=IFCRECTANGLEPROFILEDEF(.AREA.,'rectangular',#27,1.,0.2);
#29=IFCCARTESIANPOINT((0.5,-2.72848410531879E-18,0.));
#30=IFCAXIS2PLACEMENT3D(#29,#7,#6);
#31=IFCEXTRUDEDAREASOLID(#28,#30,#7,3.);
#32=IFCCOLOURRGB($,0.839215695858002,0.839215695858002,0.839215695858002);
#33=IFCSURFACESTYLERENDERING(#32,$,$,$,$,$,$,$,.FLAT.);
#34=IFCSURFACESTYLE($,.BOTH.,(#33));
#35=IFCPRESENTATIONSTYLEASSIGNMENT((#34));
#36=IFCSTYLEDITEM(#31,(#35),$);
#37=IFCLOCALPLACEMENT($,#9);
#38=IFCSHAPEREPRESENTATION(#22,'Body','SweptSolid',(#31));
#39=IFCPRODUCTDEFINITIONSHAPE($,$,(#38));
#40=IFCWALL('2w90hisO14jeiFob5V2vbO',#5,'Wall','',$,#37,#39,$,.MOVABLE.);
[ ... snip ... ]
You will notice:

- You can set all attributes of the IfcProject
- There is a map conversion and target CRS linked to the main geometric representation
- The main geometric representation is now a 'Model', which has a sub geometric representation of a .MODEL_VIEW., this is what objects are linked to (see #38 which links to #22)

If you choose not to create an IfcProject element, it will generate one for you as per the old behaviour of FreeCAD. This generated IfcProject will not contain any map conversion like the old behaviour. However, it will have the proper subrepresentation.
2019-06-29-094354_433x588_scrot.png
2019-06-29-094354_433x588_scrot.png (34.07 KiB) Viewed 118 times
2019-06-29-094425_429x558_scrot.png
2019-06-29-094425_429x558_scrot.png (35.83 KiB) Viewed 118 times
There are still many things to fix, such as:

1. Import functionality not working yet Done
2. Doesn't work with project library, only projects
3. It needs to be a projected CRS, not a regular CRS, and Meter needs to be a unit type Done
4. True north isn't calculated
5. Better UI: shouldn't ask the user to input X axis abscissa / ordinate
6. Better UI: should have preset list of EPSG standards like QGIS
7. It should detect name from the label, and shouldn't have a name attribute Done
8. Better handling of GUID attribute Done for now
9. Bug related to exporting the serialised complex attributes - need to check it out Done
Last edited by Moult on Wed Jul 03, 2019 10:19 am, edited 2 times in total.
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
yorik
Site Admin
Posts: 11249
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby yorik » Sat Jun 29, 2019 5:26 pm

Cool! Small cosmetic detail: I would use a grid layout for your widget, so edit fields are aligned...
User avatar
Moult
Posts: 203
Joined: Sat Jan 05, 2019 11:46 am
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby Moult » Wed Jul 03, 2019 10:56 am

Just a heads up on the progress of this. Currently, all of the fields have to be manually typed in for the projected CRS metadata (e.g. EPSG name, description, zone, unit, ...). It would be much, much more desirable to instead have a CRS lookup system, similar to how in QGIS you can just lookup any CRS and select it. It would then set all of the fields for you.

In order to do this, a CRS lookup could be done by downloading the EPSG database, and creating our own lookup system. However, there is a better way! The better way is to introduce GDAL as a dependency, which would allow you to look things up. It would also allow FreeCAD to automagically transform between CRSes. This is very useful as it can convert your projected CRS coordinates into a WGS84 lat/long for the IfcSite object. Another added benefit is that this opens up the possibility for FreeCAD to do spot levels and coordinates which are using absolute units whilst keeping local coordinates for your modeling, which has benefits for large infra projects.

The downside is that GDAL is introduced as a dependency.

What do you guys reckon?
I also blog about 3D rendering, architecture, software and other on thinkMoult.com. RSS / Atom feed available for your convenience.
User avatar
yorik
Site Admin
Posts: 11249
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Is there a need for an actual IfcProject / Library element?

Postby yorik » Wed Jul 03, 2019 1:59 pm

Do not add gdal as a dependency (Adding dependencies gives a hell of a headache to people doing packaging everytime). Scan for gdal availability at runtime, if available use it, if not, inform the user and let them fill manually.