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)
Comments welcome!