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

Mods Draft, Arch & BIM
1

Currently the only way to edit an IfcProject is through a dialog box UI. I wonder if it is a better idea to have it as an actual element in the tree just like IfcSite. After all, just like IfcSite, it has spatial decomposition to contain the site. Additionally, rather than have to maintain an entirely separate UI window, we can detect parameters - for example currently it is not possible to change the IfcProject “ObjectType”, “LongName”, “Phase”, or set a “RepresentationContext” to get an IfcMapConversion for correct real world survey coordinates.

Also with an actual element maybe it is easy to swap it out with IfcProjectLibrary, rather than having the need for IfcProject to be hardcoded.

Is there interest in building an IfcProject element feature? If so, at the same time I can add the missing attributes, as well as add support for coordinate reference systems, since the inability to set a CRS is a showstopper for FreeCAD to be used on any geographically large projects right now.

2

Furthermore we could have multiple projects in one FreeCAD file. I do not see any disadvantages in this.

3

Excellent! I might have a shot at implementing this.

I had a great meeting yesterday with John Mitchell, from BuildingSMART Australasia chapter - he is head of the working group that is defining how to do initial model and project setup - how to make sure everything always comes together in the right place in the world and in the right place in local project coordinates.

He was very excited to hear about FreeCAD and how it is getting some IFC features, and will be able to review our implementation of IfcProject to ensure that it fulfills the IDMs that BuildingSMART is working on.

4

You mean Jon Mirtschin no ?

About library, did you see his work about IFC library :

Having FreeCAD to be the only easy to use software able to make parametric IFC objects would be a killer feature. Currently, manufacturers need to pay someone to make objects on all common software in the industry (and in my experience most of them are shitty).

About IfcProject Yorik was working on Arch Reference :

I don’t know how these references appear in the tree but it could be a use case for multiple IfcProject.

5

Until now I have failed to see a real utility to the IfcProject entity… Okay, in theory, “project != file”. It’s not because it’s in one single file that it means it’s one single project. But also, you could have the contrary, one project is made of several files (likely much more common scenario, actually) and there is nothing for that case.

This is bad design of IFC I would argue.. Do we really need to swallow and reproduce that bad design ourselves too? The question is there :smiley:

If the thing is to be able to specify some project parameters (although, looking at http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifckernel/lexical/ifcproject.htm, I don’t see anything really meaningful), maybe we can find a way that doesn’t requires an extra document object? For ex, the FreeCAD document has a “Meta” property that is a string:string dictionary. I believe no other WB uses that yet. We could maybe use it in Arch/BIM, to store some per-document settings?

6

Actually, there is a way to have 1 project = multiple files. I personally was not aware of how to do this since STEP as adopted by IFC doesn’t allow the referencing of other IFC files in the same way that code can link together.

However, John Mitchell tells me that it is possible and the way bS endorses right now is match GUIDs, and then the ownerhistory dictates whose IFC file contains the actual content. For example, you can have one file which only contains project prepared by the client, the surveyor inherits project and specifies site in his own file, then the architect inherits site and specifies building and stories in his own file and so on.

Having an actual element simply makes the UI consistent with other spatial containers which are already elements. Also, I guess sometimes you want a project library, not a project. How should we support project library?

As for attributes, yes, project doesn’t have that many attributes but the most important attribute it does have is the map conversion to specify coordinates. (I hear it might move to IFC site in the future though which makes more sense). At the very least, if project isn’t an element, I’d like to implement coordinates mapping if you’re ok with that :slight_smile:

7

Offtopic …

I wonder if any of the big ones is able to read or write such multiple IFC, or if there is an example (even a simple one) around. How about Ifc++ and IfcOpenShell in this regard?

8

The multiple IFC thing is highly interesting indeed. With the Arch Reference object in FreeCAD this is becoming increasingly an issue. How do we treat that?

But I see your point, the IfcProject can be a kind of anchor point between several files, if several of them share the same project GUID we know they are parts of a same project. That makes sense… But doesn’t seem very solid to me (like, how do you know the file you have is a single project or a part of a multi-file project). And indeed there is the project library problem.

BTW, doing my part to try toget rid of IfcProject :wink: https://forums.buildingsmart.org/t/what-would-you-like-to-see-most-in-the-modernization-of-ifc/1460

But I think you’re right about the coordinates thing, there should be something to work with “local” coordinates. Have you looked at the App Part object? I don’t really like to use it, because I don’t like to have coordinates masked (I like everything in “real”, world coordinates), but it might be just what you need…

9

I agree, the linking approach seems a little bit weak, especially as there is no URI explicitly written in the IFC. I’ll find a demo of it working and ask how they achieved it. From memory they said they did it with archicad.

Let’s push more on the building smart forums. I think this is the first time bS is hearing the community freely speak and it’s clear we all don’t agree with what they’re doing.

I can go ahead with coordinates first. To start off with its simply a few more parameters to be added to the IFC project dialogue so it should be a super simple patch.

10

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…

Maybe it would make more sense to have an additional document object (a “real” IfcProject object) indeed… That would have many advantages, you can copy/paste it over, etc. And after all, if it’s not mandatory on the user, why not…

11

Relevant: Thread tracking FreeCAD & QGIS integration

12

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

13

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…

14

It gets even worse if you take these relationships into account … https://forum.freecadweb.org/viewtopic.php?f=39&t=36824

15

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

16

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

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…

17

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

Here is the example IFC created:

[ ... 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-094425_429x558_scrot.png
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
18

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

19

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?

20

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.