Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended use of BCF 2.0 #28

Closed
ErikPijnenburg opened this issue Jun 26, 2014 · 8 comments
Closed

Recommended use of BCF 2.0 #28

ErikPijnenburg opened this issue Jun 26, 2014 · 8 comments
Assignees

Comments

@ErikPijnenburg
Copy link

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
Copy link
Contributor

teocomi commented Jun 27, 2014

Agree on all your points!

@lbj
Copy link

lbj commented Jul 16, 2014

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
Copy link
Author

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

@pasi-paasiala
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

@pasi-paasiala pasi-paasiala self-assigned this Jul 17, 2014
@pasi-paasiala
Copy link
Contributor

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
Copy link
Contributor

These are done here:cf242b0#diff-fc5059085a6bb53d00544fb7da80db2f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants