search

buildingSMART / IFC4-CV

IFC4 Coordination View
27 stars 7 forks source link

IFC4 Coordination View successors - name and differentiation #13

Closed TLiebich closed 10 years ago

TLiebich commented 10 years ago

Currently the two names are:

for explanation see the powerpoint explanation

Whereas the IFC4 Reference View is a well understood name, the "Design Handover" seems to have an ambiguous meaning - where most understand "Handover" to client, and in particular for operation.

At a recent bSI meeting in Munich the recommendation was made to call it:

Any thoughts on that?

TLiebich commented 10 years ago

On the second subject - during the IFC2x3 period, about 95% of all IFC implementations followed the IFC2x3 Coordination View. With IFC4 there will be at least 2 or 3 well established views (reference view, design handover/transfer view, and hopefully a library view) - data sets created for these views require different IFC import capabilities.

E.g. if a software only implements IFC4 reference view import capabilities, it would not be able to import IFC4 design handover/transfer view files (e.g. as it would not have the CSG capabilities required). However users see IFC = IFC and would/might not understand the differences among the different model views. So the import would not be successful, hence "IFC doesn't work"!

The only differentiation between two different views is in the IFC Header description field, see the official documentation here. Ordinary users would have no knowledge about what a MVD is, nor would they be patient to learn all these subtle differences.

So which convention should we prefer?

Opinions?

AngelVelezSosa commented 10 years ago

On IFC Design Transfer View: I think it is a great name, and settles the debate about "Handover" being confused with "FM Handover". It also states nicely what it is for (an intelligent transfer of data in one direction from application A to application B) and what it isn't for (roundtripping).

As far as conventions, I think we should leave the file extensions alone, and have meaningful messages. I am not going to claim Revit has the best UI for IFC, but on export we ask users to state the IFC schema version and MVD, and I think it makes sense that users know why they are exporting what they are exporting. On the import side, there should indeed be meaningful "unsupported schema" or "unsupported MVD" messages, and these should be tested in certification (a fake IFC5 file, or a fake "NotRealMVD" IFC4 file, or both).

I also think that in addition, there needs to be an end-user friendly place on the buildingSMART site that explains what an "IFC4 Design Transfer View" (or any other official MVD) is, and isn't. (e.g. "It is for a one-way transfer of ownership of a design from one application to the next. It is not intended for roundtripping.") The reason is that I think implementers have a responsibility to explain the limitations in their particular flavor of IFC, but not of the limitations of the IFC MVDs themselves. Being able to have a common voice for all vendors in this regard would be extremely beneficial.

MarieHermanova commented 10 years ago

I agree with Angel. Showing a message about unsupported schema/MVD is the best solution. A different file extension tells users nothing and some of them could try to rename and import it anyway.

rasso commented 10 years ago

100% agreed, and I think we should stop confusing end-users with acronyms like "MVD". Instead we should offer data-exchange for specific purposes and we should agree on standard definitions for such purposes, so that they appear in the same way in all apps.

TLiebich commented 10 years ago

The names are agreed:

and the need to have a clear definition on the buildingSMART website in user terms is noted. It should be brought up with buildingSMART as a strong user request.

TLiebich commented 10 years ago

Sorry - I made a mistake by copying the wrong pair of names into the resolution. It is of course:

All current documents already using these names.