buildingSMART Forums

What would you like to see most in the "modernization" of IFC?

I personally struggled a lot with the upper level elements like IfcProject, IfcSite which bind a single IfcBuilding per file. We should contain multiple buildings in a file while this also raises the file size depends on the size and details. I agree with @yorik to have more objects, but I believe relationships might be valuable also for other purposes. I worked on some graph analytics on a >2GB ifc file just to see what kind of results would appear. Although I don’t have clear suggestions regarding what kind of relationships would be defined extra (may be a separate thread), I found existing relationships in ifc standard does not bring sth new with one building, since you can reach similar results with DB queries.

I fully agree with the argument that ifc describing (one) site, building or project is not working. I think most of the civil works is done using ifc parts per assembly per phase per disciplibe etc. Merging ifc should be made more simple.

Besides that i would like to see a improvements and efforts taken to bridge the gap with what is called ‘level 1 bim’ (i personally hate that typology). In other words, make it in ifc more easy to incorporate linework and ‘stupid’ cad design. Either 2d first and 3d, or vice versa.

Point is ifc should be more capable of simple mixing and fushion of data. For those who see it as just a an other fileformat.

I’d like to know your opinion guys:

Kind regards,

My vote is to not ask permission.

That’s all I needed to to hear :smile:

As of this commit, FreeCAD is now able to export an IFC file without any site, building or storey. Example file: without-building-structure.ifc (11.6 KB) (please don’t mind the geometry defect in the column). The objects are simply aggregated directly under the IfcProject. Actually, I haven’t found in the IFC docs anything that says this is forbidden. The IfcRelAggregates apparently allows to aggregate any object type. Anyone knows where the mandatory building story comes from? I don’t remember…

This file opens OK in FreeCAD, IfcPlusPlus and ArchiCAD so far. Revit opens it, but merges all objects under a single one…

The IfcProject, however, I couldn’t do without, because that’s where all the units are defined. I suppose you could actually have several projects with different units in a same file, that could make sense some day… So probably that one has to stay.

I think that replies your question too @ReD_CoDE ?

Happy to hear this Yorik, good job

I see the final output which is STEP files, and say: OK! Let’s accept that all are happy with STEP at the output

How can we have “shallower tree” and “single entities” and “simplified relationships” inside the schema.

The output can be this:

#1=IFCPERSON($,$,'Yorik van Havre',$,$,$,$,$);
#4=IFCAPPLICATION(#2,'0.19 build 16944 (Git)','FreeCAD','118df2cf_ed21_438e_a41');

But what if we be able to “move all types, rules, functions, … needed into a single entity” and “have simplified relationships” not messy ones that cause a lot of misunderstandings even between people who know IFC well

I don’t know is it possible or not, but it seems that possible. I should ask from people who know UML and software architecture development I think

It is true that you need 5 lines for something that could be said in one (Yorik, FreeCAD, date), but that’s how IFC works… Any 2D profile is also made of 10, 15 lines when it could in theory be only one (a list of points, basically), it’s hard to imagine that could be changed easily. The format is made for modularity (you can easily reuse any of the “pieces” anywhere else) rather than compactness

The idea of being able to synthesize is attractive, though… (something like: IFCOWNERHISTORYCOMPACT('Yorik','FreeCAD',1560119567) maybe?

What about

One can dream :smiley:


@ReD_CoDE, @yorik - are you guys serious? Exactly because of complex concepts and relationships (with inheritance so that attributes are not redundant) that everyone can agree on (ISG and certification) we can even come close to start exchanging data. A 200MB model can have all kinds of different geometry representations for various objects. Your " IFCCLOSED2DPROFILECOMPACT" is broken with an arc already, let alone something “fancy”. :slight_smile: Have you taken a look at IfcIndexedPolyCurve?
Your owner history example goes away from the concept of object oriented models. You want to parse strings where you should have structures and types that allow you to get away from compliance errors. You could go all the way with simplification -> go back to PDFs. In the end, an IFC SPF does not need to be human readable. Isn¨t that the whole point? Digitization and automation.

Dear Sergej,

IFCCLOSED2DPROFILECOMPACT” concept represents a familiar structure we see in the world, especially related to 2D and 3D Javascript geometries:

You know, and all we know, with current IFC structure we won’t achieve “a real” digitization and automation

It’s like building a beautiful building on a “weak” foundation and I ensure that “all” countries that work on national digital projects have felt this

Why don’t build IFC based on modern things that are available today? Instead of “insist” on ideas and technologies which were good 20 years ago?

Take a look at the majority of resources on buildingSMART, most of them are for “10” years ago

Relax, not trying to push a standard change here, just playing with the idea, which is what this topic proposes… In any case, providing alternative, compact ways to “reduce” (maybe REDUX is cooler than COMPACT :thinking: ) some “bunches” of data does not mean everybody would be forced to use it…

1 Like

I was referring you to existing possibilities. I think IfcIndexedPolyCurve does what you ask and more. Why would you need another redundant definition in a schema that is already quite substantial. Just means less implementers will support it.

yes, the IfcIndexedPolyCurve provides you with this capability. See attached a document that was created to justify the addition of a new class. And please have in mind, that IFC is currently used by >250 software applications worldwide, with millions of IFC files around - so one can’t just “do and change”.

see: IFC4_Add1_IndexedPolyCurve_Definition.pdf (314.2 KB)

Nevertheless - thinking about a new generation of IFC using modern, web-based technology is needed, while maintaining the existing technology stack to guarantee compatibility.


A new generation of IFC tools that are cross platform (I’m looking at ya, IfcDoc!) Is good! A new generation that relies on an entire web stack as an application platform ? Not a good idea! Feel free to provide a web UI, but don’t couple the code to the web. Even web devs don’t do this anymore for serious applications.

1 Like

Dear friends,

Your feedback is highly appreciated and will help us to improve IFC and build a new interactive IfcDoc

Thomas, I want to be super clear that I’m not proposing breaking existing implementations. And it’s possible that I’m conflating two discussions: the improvement of the IFC schema, and the development of new technologies around bringing the standard to cloud workflows. These can be separate discussions, but like any lazy programmer, I’m trying to figure out if we can make improvements that advance the standard in both contexts so we don’t end up with the “IFC for the desktop” and the “IFC for the cloud.”

1 Like

I say let’s drop IfcRoot, IfcOwnerHistory, and IfcObjectDefinition, …, and just have the end one
For instance an IfcWindow is just an entity --> We can with “CLASSIFICATIONS” say that a window is an object, a product, an element, a building element

I appreciate your energy in suggesting to reduce the number of types in the schema. But I think you don’t understand that many of those types are “abstract”. They represent levels in the inheritance hierarchy but are not the types that are stored in IFC. For example, you won’t find an instance of IFCROOT written to an IFC file. But The IFCROOT Entity has properties which are inherited by all of its derived types. You CANNOT remove those entities from the schema without breaking the dependency tree.

1 Like

Dear Ian,

My suggestion is clear: I say in output, Ifc file (SPF) the output is this:

#1=IFCPERSON($,$,'Yorik van Havre',$,$,$,$,$);
#4=IFCAPPLICATION(#2,'0.19 build 16944 (Git)','FreeCAD','118df2cf_ed21_438e_a41');

So, let’s redesign the schema like this too
Instead of having 4-11 layers tree, let’s have a 1-4 layers tree which is so close to the output file

I get it. And like I said, you can’t. Unless you want to duplicate the attributes belonging to all parent entities across all of the derived types, which would do the opposite of simplifying the schema.


Yes, I understand what you say, atomic approach

However, I think if “schema” be easy to use (especially in automation and control systems) with less “entities” and “types”, but the size of it increases, this is not a problem

Especially when the majority of them are “Optional” which I see this as a weakness inside the existing schema

If you reduce many things, and move all relationships and instances in just 1-4 layers (entities), in the final schema the consequent of things dropped and things duplicated would be nothing more than existing schema in structure and in size

For instance in IfcWindow example, we easily can drop IfcObjectDefinition, IfcObject, IfcProduct, IfcElement, IfcBuildingElement, and with classifications control the sitatuion


As said before we can reduce IFC schema layers and instead use classifications to say a window is an object, a product, an element, a building element

Also, ISO 19650 naming approach can help us develop a better way than just GUID/UUID (in 128-bit approach) for identification