search

opensourceBIM / BIMserver

The open source BIMserver platform
GNU Affero General Public License v3.0
1.54k stars 608 forks source link

Merge multiple versions of an IFC file. #449

Open theoryshaw opened 7 years ago

theoryshaw commented 7 years ago

How involved would it be to modify the merge plugin to...

Essentially looking for a solution that merges multiple versions of an IFC file over time.

rubendel commented 7 years ago

Determining duplicate GUID's is not that hard, but what would you replace them with? And how would you do that consistently for the same (logical) objects?

There would have to be some extra storage reserved I think (outside of the IFC schema) to indicate objects that have been deleted. The current merge-plugin interface does not support this at the moment.

theoryshaw commented 7 years ago

Hi Ruben,

In a nutshell, I'm looking for a git equivalent for IFC files.

Which I know is a tall order at the moment. So looking for a MVP in that direction.

but what would you replace them with?

At this point, to keep it simple, I was thinking the most recent GUID could just override the previously submitted GUID. We would worry about merge control later.

theoryshaw commented 7 years ago

Just to give you some background...

@yorikvanhavre and I are working on a very simple, barebones rountripping workflow between FreeCad and Revit: https://github.com/OpeningDesign/FreeMVD_WorkFlow/blob/master/BIM%20Specifications.md'

Involves only simple extrusions and IfcBuildingElementProxy elements.

We're using this roundtrip workflow to create large scale details: https://github.com/OpeningDesign/Sports_Complex/issues/18

...and using a Dynamo script developed by @dimven to automate the annotation of these details.

So far, the roundtripping has worked pretty well. Would be nice to incrementally add more intelligence to the workflow over time--to potentially recreate Revit profile families and groups.

In this regard, It would be great to find/develop a solution that would allow us to merge the versions of this one IFC file, over time--as I mentioned, almost like a git solution for IFC files.

I-Sokolov commented 7 years ago

Are you speaking a situation when the same GUID is used in two IFC files but not when one IFC file has two objects with the same GUID? If so, it makes the task more clear and correct to my understanding. The newer IFC file has a newer data for object that should update/replace older versions, is it? Merged file should take an object from newer file with all follow-up properties and relations?

theoryshaw commented 7 years ago

Are you speaking a situation when the same GUID is used in two IFC files but not when one IFC file has two objects with the same GUID?

two files (or multiple throughout duration of project) with the same GUID

The newer IFC file has a newer data for object that should update/replace older versions, is it?

Yes.

Merged file should take an object from newer file with all follow-up properties and relations?

Correct. It would be nice to have merge control here, but not crucial at this point.

rubendel commented 7 years ago

If I understand correctly, this is a problem we have looked into a few years ago. My conclusion was (not everybody agreed) that it is too hard to reliably detect the changes between 2 versions of an IFC model.

GUIDs that stay the same between versions would definitely help a lot though. Maybe with some clever way of user-interaction you can come up with a working solution.

Another way of accomplishing this I think would be to record the changes in a model in the authoring tool itself, and send those to a BIMserver.

berlotti commented 7 years ago

For the record... I was one of the people that didn't agree :-)

Moult commented 5 years ago

GUIDs have to stay between versions, it is part of the requirements of the IFC spec.

Recording the changes can be done via IFC's owner history. Of course, the authoring tool would have to identify the changes, and then send a package of owner histories over to the BIM server so it can perform the merge.

Can we reopen this issue and re-evaluate?

I-Sokolov commented 4 years ago

GUIDs have to stay between versions, it is part of the requirements of the IFC spec. Unfortunately it is far from practice. For most of vendors there are strong entities with stable GUIDs (usually building elements) and weak (psets, relations) that are fluent, assume generated on the fly. A lot of vendors change GUIDs for project, building and storey.