Thoughts about Git for IFC (2)

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 to #80 points to an IfcCartesionPoint (#6). It's important to understand that the numbers starting to the # define the IFC graph (or entity network), and that is exactly what makes IFC so powerfull. So the line above actually shows is:
  1. Two graph nodes (IFCCARTESIONPOINT and IFCAXIS2PLACEMENT3D)
  2. A graph edge (#6, pointing from IFCAXIS2PLACEMENT3D to IFCCARTESIONPOINT)
IFC graph of a small example file

Now, the numbers starting with # are purely numbers that are defined within the scope it the IFC file. They have nothing to do with the bim-model data, nor do they have any relation to anything in the original source file the IFC was exported from. So, whenever something changes in a model, and the IFC is re-exported, these numbers could be completely different. #80 could than just as well be an IfcWall! This problem is present in the XML files as well.

So although tracking changes on line level is possible because the IFC files are ASCII bases, it's quite useless since differences between files could be almost 100%. 

And what about Git LFS?

There is an extension to Git which allows to track large files (LFS). But really, what's the point in version tracking whole models? You want to track changes on the element level right? 

Versioning separate entities: a necessity

Instead of looking for ways to version complete IFC files, we need to start looking for ways to version separate entities. This is an absolute necessity. Mainly because of the fact that we never know what the scope of and IFC file is (one storey or a full building?), but also because we need to be able version data changes on the smallest of entities, like properties.

IFC already provides some sort of versioning through the ChangeAction property on the IFCOWNERHISTORY entity. However, this particular property remains often unused, mainly because IFC exporters will simply export the model as-is. Often, BIM software itself doesn't even store model/entity versions, so there is nothing for the IFC exporter to export.

Furthermore, the IFCOWNERHISTORY only reflects changes on rooted items (entities which are descendants of IFCROOT). So single properties, or geometries are not included.

Where IFC fails

When it comes to versioning IFC data, IFC fails at the exact point where its strength is: the definition of it's data graph. It is important to understand that it is not the IFC schema that fails, but the way the data is written to IFC STEP or XML files. The problem lies in the fact that arbitrary integers are being used to define the graph edges, which are only defined within the scope of the file.

The main problem is that most data storage systems are hierarchical, while IFC's graph is not.

So in order to be able to start versioning IFC data, we need to redefine how the data is saved to disk. We need to:
  • Define a pure mechanism for identifying all IFC entities.
  • Define a pure mechanism for identifying the links (graph edges) between entities.

What's next?

In my next post, I'll present some thoughts on how to redefine how data is stored.

Reacties

Een reactie posten

Populaire posts van deze blog

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