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

[Kunda1]

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

[Moult]

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 (29.38 KiB) Viewed 1532 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 (36.08 KiB) Viewed 1532 times

[yorik]

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...

[bernd]

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

[Moult]

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 (39.54 KiB) Viewed 1473 times

[yorik]

Seems cool so far! We need an icon Not sure how a project icon should look like...

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...

[Moult]

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 (34.07 KiB) Viewed 1395 times

2019-06-29-094425_429x558_scrot.png (35.83 KiB) Viewed 1395 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

[yorik]

Cool! Small cosmetic detail: I would use a grid layout for your widget, so edit fields are aligned...

[Moult]

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?

[yorik]

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.