How to prevent huge viewpoints

[buildingsmart]

How to prevent huge viewpoints

[gschleusner]

I think this is the exact wrong approach. We should optimize the schema to be as efficient as possible...which is currently isn't because you end of repeating the elements in every viewport. Not limit what can be transimitted in BCF.

[ErikPijnenburg]

OK so what do you suggest ?

[gschleusner]

I think the major issue is what I'm commenting about in #65 ...that the elements are associated with the view port and not separate with a mapping to the view ports they belong to. I am not the one coding this internally, but the current implementation you end up repeating elements in every view port it appears...do I have that correct?

[ErikPijnenburg]

You are correct but I don't think that is the major problem:

1. Big files:
   The current definition of BCF would be changed a lot to introduce this relation from GUIDS to viewpoints in one file. This can perhaps spead up loading time, but not viewpoint-handling time. And since issues are more and more stored in databases this relation is easy defined in the database and thus solved.
2. Big viewpoints

• can slow down the server-client communication in web-based issue-tracking systems a lot, even when we use caching techniques.
• can slow down the zoom-to, depending on the client BIM application: each component needs to be looked up and set visible.

[gschleusner]

I see what you are saying.

If that is the isuse then what I'm sugguested before would be a fix.

We generate huge viewports because we don't want to create issues for every single instance of a type of issue. as example... "All the ducts on this level that are in these types of rooms are to low". Its much simpler to just show them all then make 50 individual issues. I have sugguested in the past that we split the concepts issues from the element to element relationships. The result we are looking for in this situation is not a single view port, but a single issue that has a sereis of sub-issues. I wouldn't generate a viewport for the main issue, but only for the sub-issues

[GeorgDangl]

You might want to create then a leading topic that describes the nature of the problem and then create a series of related topics, each for one issue. This you you could group sets of topics by a common, parent topic to which all have a relation.

[gschleusner]

Is this grouping capablity current functionality or proposed?

[GeorgDangl]

It's not in the standard as a grouping functionality, just described as a property stating that two topics are related.
I think it's up to the developer, but for me the most logical thing to do is to group topics that are defined as related.

[gschleusner]

I don't think this would be enough. We would really need a parent child type relationship and not a flat relationship. Otherwise there would not way of determining which items is the "top" item.

[linhard]

#85