Thoughts about Git for IFC

Recently there has been some discussion on Twitter on how nice it would be to have some sort of Git-like versioning system for IFC files. Since Twitter messages are too short to express the full complexity of this topic, I decided to write this post.

Assumptions

  • You know what BIM is;
  • You know what IFC is and you have knowledge on the different class definitions;
  • You know what Git is, or you have worked with other versioning systems before. It helps if you have knowledge on the internals of Git.

Why Git for IFC?

There is a tendency to talk about Git, when people actually want to talk about versioning in general. Reason for this is that Git is very common nowadays as the versioning system for software development.

The question is thus: Why versioning for IFC? Well, basically we need to look for versioning of BIM models in general, and IFC is key candidate when it comes to this because of it's open specification.

We need versioning of BIM models, because, as in the real world, models change over time. Several things happen:
  1. During the design phases, models change very fast. Versioning can help in detecting changes.
  2. During the design phases, design options are often developed parallel. Versioning can help in analysing differences between design options. Git's tools like branching, merging, diffing could help a lot.
  3. During asset-management phases, models should reflect the as-built situation. However, often small parts of buildings change, and models are not kept up to date. Again, versioning could help here, especially branching and merging, since we could simply branch the as-built model, redesign a part of the building, built it, and merge it back in the asset-management model.
Furthermore, the commit structure used by Git creates a chain of commits. (Note this is NOT a blockchain!). However, the chain of commits does allow us to track any changes made in models. If anything changes in the data of the model, the hash of the commit will be different. This is of significant importance! How many times have you heard that people are reluctant to give their models away because "you never know if anyone changes something and than blames you"? Well, with a commit structure like Git's, this is no longer an issue. 

Finally, the beauty of Git is the fact that you can clone complete data repositories. This means that you could for example clone the complete model (including it's history) of a project to your computer. You can than work locally on the model, and push changes to the cloud based repository. This is super powerful!

Conclusion, why Git for IFC?

  • Because we are in need of a chain of changes in the construction industry.
  • Because we are in need of versioning of models (by element) in the construction industry.
  • Because we need to be able to track changes between versions of models in the construction industry.
  • Because a versioning system could solve a lot of issues on using BIM models in the asset-management phase.

What's next?

In my next post, I describe the current limitations on using Git directly with IFC files, and what we need to change in order to make IFC's work with Git.

Reacties

Een reactie posten

Populaire posts van deze blog

Thoughts about Git for IFC (2)

Afbeelding
In my previous post I described why we would need a versioning system like Git for IFC. Now, let's focus a bit on what would be necessary for this to work. Can't we just start using Git? Git is all about versioning ASCII based files, and IFC files are ASCII based as well (both the STEP files as the XML files). So can't we just start using Git right away? No. Let me explain. In Git, whenever a file changes, the hash of the file changes. This results in a new "blob" being stored inside the Git database. So in essence, Git stores files completely no matter how small the change. However, the power of Git is in the fact that it can display changes between versions of files on the level of lines.  Now, IFC's file scheme fails completely at this point. Let's have a look at 2 STEP lines: #6= IFCCARTESIANPOINT((0.,0.,0.)); #80= IFCAXIS2PLACEMENT3D(#6,$,$); What you see here is the definition of an IfcAxis2Placement3d. The definition is assigned
Meer lezen

Thoughts about Git for IFC (3)

In my previous posts I described why we are in need of a versioning system for IFC , and what the current drawbacks are when if comes to using IFC and Git . In this post I'll describe my thoughts on how we could implement a version tracking system for IFC by defining a new way to write IFC data to disk. First, let's define some starting points. Starting points I've taken the following starting points into account: Stick to the principles of the IFC graph as much as possible: keep data linked and separate, don't store entities in entities (which is tempting in hierarchical file-structures), since that results in data duplication. Use the hash of an entity as the identification method of the entity. Entity hashing and storage should be such that no data duplication occurs. Entity hashing should be such that entity uniqueness remains, even on non-rooted entities. Human readability would be nice but is not a necessity. Speed is more important, the repository sh
Meer lezen