BIMagineering

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

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

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