I’ve proposed for this to be created over at the FreeCAD community. FreeCAD already has a rudimentary diff tool based on IfcOpenShell, it should be relatively trivial to isolate this diff script from FreeCAD and make it a standalone script based on IfcOpenShell:
Would this be between two files created by the same authoring tool, but maybe different versions? If it was between two different tools creating the “same” model, I would say that currently it would never work.
@jwouellette
My expectation is that two files are created by the same authoring tool with the different versions. FreeCAD diff tool is trying to compare the geometry by centroids, areas, volumes, bounding box, and also cover material, id. However, it doesn’t cover others: spatial structure, hierarchy, relationship, property set in detail. Also, it isn’t a separate tool from the FreeCAD. Perhaps, this tool isn’t what I want now.
Correct. That is why I have proposed to create a standalone diff tool I believe OpenBIM really needs one.
I don’t see why it can’t diff IFCs created by different authoring tools, the CG industry has had diffing tools for a while now that are completely agnostic of the geometry creator, so… why not for IFC?
Unfortunately, the way things work right now, two tools can create different IFC files for the same model data. They are different because each application has written the ASCII syntax in a different order.
Although yes, the way things work right now is not the best, because each authoring tool supports IFC in a different way.
However I don’t think the different ASCII syntax is a problem at all. I can take an OBJ, edit it in Blender, then edit it in 3DS Max, and I can still compare the two, regardless of the OBJ being written differently each time. It is the same with IFC - the diff tool simply has to:
parse each IFC file into a data structure
canonicalise and sort the data structure
where GUIDs match, compare attributes (geometry, centroids, data attributes) within a certain set precision value
Therefore, the ASCII structure doesn’t matter, and the only prerequisite is that the GUID isn’t mangled in the authoring program, which it shouldn’t be (see discussion in other thread how the current spec for IfcGloballyUniqueId is currently inaccurate, but when this is fixed it can help ensure tools like this diff and others can work reliably).
Absolutely:) so it should be trivial for someone to extend that code to include diff capabilities (FreeCAD is one such example). But such a standalone, command line, open source tool doesn’t exist yet?
I suspect writing one with IfcOpenShell which is headless and relatively easy to prototype with is your best bet.
Geometry Gym has developed diff and merge routines that can be run as a standalone command exe, cross platform with mono. And with nordlenningen have run the routine with files originating from tekla and passed through revit with success. It’s developed on demand as it has various smarts about geometry tolerance. I would like to automate the creation of this tool akin to the toolkit in Ifcdoc.
In a pure way, you could use an approach similar to what I’m advancing on with the definition of ifc within ifcdoc. Create an ordered ifcxml. This might work with very little effort.
That’s true, Jon. But not quite sure what is asked for (maybe bad reading from my side…). Variations and difference between to models originated from the same authoring tool, is as Jeff says done by model checkers. On a “desperate” user level we have used Notepad++ to check the difference in files, but that is often related to specific errors, and may not match the need here.
My interpretation is that the OP is asking for a git diff that is a bit more semantic … this is not something that a model checker currently provides.
I suspect writing one with IfcOpenShell which is headless and relatively easy to prototype with is your best bet.
IfcOpenShell has this entity_instance.get_info() method which you can use to get a hierarchical attribute map for an instance (rooted or not) which you can trivially compare for equality with one from another file. You can exclude the numeric instance id name so the check is robust against multiple exports from the same model which sometimes creates different numeric ids. So yes, this is indeed “relatively easy”.
We have a standalone developer tool which compares two IFC files on textual basis. (Not command line tool, it has UI). It has two panels with the direct an inverse references, you can navigate parallel in both files:
For a bit of closure on this thread, BlenderBIM now packages IFCDiff, which is a command line tool that does some, but not all (yet), of what you’ve asked.
At the moment it covers geometries and properties, ignores changes in STEP line IDs, and also takes into account floating point differences between exports. I expect its capabilities to evolve over time to allow diffing for specific things, deeply nested relationships, querying exactly where geometry changed, spatial diffs (i.e. diffing based on spatial location, not the entire file), and better ways to visualise and report the data. It currently provides a JSON report of added GUIDs, removed GUIDs, and changed GUIDs along with a before / after of property values, and a boolean indicating geometry changes.
If you compare IFC file versions (revisions or variants) generated by the same authoring software there are only minor challenges to solve.
Examples for authoring software deficits:
a) each subsequent IFC export is “new” again, no difference information supported ( attribute “ChangeAction” in “IfcOwnerHistory”, see thread IfcOwnerHistory)
b) changed GUIDs for unchanged items
c) minimal changes in real values (e.g. in the magnitude of 1E-17 caused by rounding errors)
d) same object type e.g. WindowType is stored separately for each window even if the imported IFC4 DTV IFC file had one common WindowType for all equal windows
… to be continued by the community @jwouellette:
Where can a systematic collection of such current drawbacks (future improvements) be found?
If two or more different (authoring) software applications are in use then there is the big challenge of “different representation paradigms”:
As @jwouellette mentioned: " two tools can create different IFC files for the same model data."
And they really do! (e.g. wall represented by extruded area versus brep)
Even worse: currently NO roundtrip-preservation on IMPORT - NO CHANGE - EXPORT (NO “conservative IFC processing”):
Your IFC4 DTV file is completely dissassembled by the authoring software during import. If you export without planning changes you get back the same model in a different representation paradigm. Comparing the differences based on text and formal information structure only,without taking into account the geometric semantics is impossible.
See:
Solution: BIM Level 3:
shift building model to a CDE
(authoring) software applications operate on the model (using an open IFC API) by using standardized basic model manipulation operations (similar to DML of DBMS)