Recommended use of BCF 2.0

[ErikPijnenburg]

The BCF 2.0 documentation should contain a section "recommended use". There are too many things in BCF 2.0 for disputable reasons which can cause different interpretations of BCF 2.0

So I suggest at least these recommendations and invite everybody to add more:

Keep relation comment:viewpoint = n:1
The Viewpoint-ID in a Comment is regarded being leading !
This is to prevent that wrong use of back-reference from viewpoints to comments can make the relation n:n. So actually comment-ID in Viewpoint could or should even better be removed from the. BCF 2.0 definition. Redundant info is often cause of trouble.

Comment status and verbal status will be phased out and are replaced by status and type on topic level. When interpreting BCF 1.0 files this is the way to do it:
a- use Status of most recent comment as Issue-Type
b- use Verbalstatus of most recent comment as Issue-Status.
When interpreting BCF 2.0 files: Verbal Status and Status on comment level should all be neglected if Status and Type are present on Issue-level

Remark: a BCF hub needs to keep track of history on its own and not by using these obsolete fields in comments.

To prevent huge viewpoints containing all GUId's of an IFC file (which we see a lot in BCF files) it should be defined that when NO components are mentioned in a viewpoint as being visible it means the whole model is visible (clipping planes can do the job to pinpoint an issue)

[teocomi]

Agree on all your points!

[lbj]

I think we should clarify on issues if we are talking about the BCF 2.0 format as such or about the BCF 2.0 API. While the comments here seems to be about the BCF 2.0 file format there are also references to the BCF "hub" that might imply that this remarks are about BCF in the shape of an API. We cannot remove bits from the file format that preserves history because the API can preserve the history in another way. The BCF file format and the BCF API are two different things.

[ErikPijnenburg]

Everything I wrote above was about recommended use of BCF 1.0 and 2.0 formats.

[pasi-paasiala]

I would suggest that for the third point we could agree that if the viewpoint only lists hidden components, then all the rest would be visible except the hidden components (the Visible flag is false). For example, it is often good not to show spaces. This way the smaller set of components (visible or invisible) could be exported to BCF.

[ErikPijnenburg]

I agree, but then we need to recommend to use that with care: when listing only hidden components you cannot know anymore if the Zoom-To shows all involved items if the model has been changed. When listing visible components the software can check if they are still available.

The definition will then become:

• By default NOT listed components are hidden
  UNLESS: there are NO components listed as visible,
  THEN all components except the ones listed as hidden are visible
• By default NOT listed components are NOT selected

And the advised/best working practice to limit size of viewpoints:

• either list a few involved components as “selected=true" but show whole model (no components listed as visible) and perhaps use clipping planes
• or list a few involved components as “visible=true"
• or list no components as visible meaning whole model is visible except components listed as hidden

The software creating viewpoints should work in a way that viewpoints remain small, to limit BCF file size and improve performance when working with a hub.

[pasi-paasiala]

Agreed in telecon 2014-07-17 that I will update the documentation.

[pasi-paasiala]

Here's the first version of the agreements: https://github.com/pasi-paasiala/BCF/tree/master/Documentation. It is still in the fork and not merged.

[pasi-paasiala]

These are done here:cf242b0#diff-fc5059085a6bb53d00544fb7da80db2f