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

#17

Dear Sergej,

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

https://processing.org
http://processingjs.org

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

#18

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

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.

#20

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.

3 Likes
#21

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

Dear friends,

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

#23

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

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

#25

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

Dear Ian,

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

#1=IFCPERSON($,$,'Yorik van Havre',$,$,$,$,$);
#2=IFCORGANIZATION($,'uncreated.net',$,$,$);
#3=IFCPERSONANDORGANIZATION(#1,#2,$);
#4=IFCAPPLICATION(#2,'0.19 build 16944 (Git)','FreeCAD','118df2cf_ed21_438e_a41');
#5=IFCOWNERHISTORY(#3,#4,$,.ADDED.,$,#3,#4,1560119567);

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

#27

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.

2 Likes
#28

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

#29

“After ISO 19650, IFC, especially IDM needs some improvements, so “WHAT IF ISO BIM, CLASSIFICATION AND IFC BE MORE CLOSE TO EACH OTHER AND BUILD A BETTER SOLUTION FOR THE INDUSTRY” ”

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

#30

For the past few months, there has been discussion within the bSI technical community to look forward at the architecture of IFC. As part of this discussion, it is important to understand that there are different components, such as:

  • Description Method - including the Definition Language (UML vs. EXPRESS, etc.) and Data Formats (STEP, XML, JSON, etc.)
  • Specification - including the structure and content of the schema and possible extensions like Taxonomy and Data Dictionary
  • Implementation Methods - including File-based (P21-STEP, XML), Database (Relational-SQL or Triplestore-SPARQL) and even Web-based (openAPI or GraphQL).

I think to make any headway on many of the discussions recently launched in this Forum, it also helps to have everyone step back and take a broader view before launching into “…well I can make it better if you all just do it this way instead…”, especially when jumping into implementations/executions before understanding many other points of view.

There are many requirements that must be fulfilled in any case of moving the development forward. This includes, but is not limited to:

  • Legacy compatibility (versioning, STEP/XML, file-based workflows, etc.) which is VERY important to existing and long time users with existing IFC files;
  • Posterity, where any long-term vision (25-50-75+ years?) of development and deployment must be viable and accessible;
  • Ease of use, not necessarily for everyday BIM end users, but considering modern and best practice methods for development now and debugging by completely new actors in the future, some large, some small, some less sophisticated than others;
  • Flexibility, enabling schema content to expand and/or contract based on needs that have been evaluated at critical times. This may include “modularization” which helps specific stakeholders create tailored semantics, context, and content for specific market needs while still having a valid overall relationship to the general scope, semantic structure, and transactional capability of the data;
  • Industry-specific, the data that the building and infrastructure domains generate is much different than much of general manufacturing, commerce, and services. There are complex relationships and many attributes that are important to capture and enable many types of transactions;

So, I ask that everyone take a deep breath and maybe step back for a moment and look at this from a higher-level before diving too deep into the debates that appear to be heating up.

3 Likes
IFC for relational databases - ifcSQL
#31

I would like to clarify the below misunderstandings of IFC’s capabilities.

In IFC, you are able to describe multiple sites, and multiple buildings.

In more concrete terms, an IfcProject can contain through IfcRelAggregates multiple IfcSite objects. Each IfcSite, can have its CompositionType parameter set to COMPLEX, for instance. Each IfcSite can then have another IfcRelAggregates to decompose itself into another IfcSite object, which also has a CompositionType parameter set to ELEMENT or PARTIAL. The spec currently allows up to 3 levels of IfcSite nesting (COMPLEX -> ELEMENT -> PARTIAL). This arbitrary limitation of 3 levels deep may be removed in a future IFC version.

Similarly, each IfcSite, seemingly at any level of CompositionType, can contain one or more IfcBuilding objects. Each IfcBuilding object has the same 3 levels of CompositionType. (COMPLEX -> ELEMENT -> PARTIAL) The spec is a little bit more specific here, nominating that the COMPLEX type refers to a “building complex”, like a group of buildings, and an ELEMENT type is a single building. This creates a bit of ambiguity whether or not a group of buildings is a one to many IfcBuilding (COMPLEX) -> IfcBuilding (ELEMENT) or if a group of buildings is a one to many IfcSite -> IfcBuilding (ELEMENT).

This page about IfcSpatialStructureElement describes how it works, and shows that it applies to any spatial structure. So my description applies to things like IfcSpace too, and now maybe even IfcFacility in the new spec.

In short, despite the ambiguity, which hopefully somebody (@TLiebich ? @jonm ? ) can clarify, it is clear that IFC supports more than one site and building.

1 Like
#32

In COBie, instead of Building we have “Facility”
So, I think Facility was/is a good choice, but I don’t know why it didn’t nominate to be in IFC, maybe @TLiebich know.

All in all, in the near future, all other IFCs like Infrastructure, … all will merge with current IFC and from now it’s better choose better definitions and structures to have a coherent as well as accurate IFC schema

#33

Some insights:

#34

Spatial/project structure in IFC is inherently connected. As you have established, there is a 3 level decomposition currently in place for every single spatial structure element of a particular type (as you have explained). This limitation is not really embedded into the schema and is mainly bound to MVDs. There is no rule preventing you from having an IfcBuilding decomposed into 5 levels.

That being said, I am not familiar with software that allows decomposition of a particular spatial structure element into spatial structure elements of the same type. So, use of CompositionType is not really widespread. :slight_smile:

Talking about more than one IfcSite or more than one IfcBuilding in one IFC file is another matter. An IfcSite is able to contain more than one IfcBuilding as well as an IfcProject can be composed of more than one IfcSite. For this issue, there are no limitations either in the schema nor in the Reference View MVD. I am not familiar with Implementer agreements on this matter. Maybe they restrict it.

#35
#36

The objective for modernization of IFC is described at https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC

We need your help collecting and discussing issues that fit this objective. Please read this full text first and follow the links to contribute: https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC

(issues that are not according to the guidelines can be placed in another repository and will be removed from this list)