Scattered Model treshold?
-
@agroni said in Scattered Model treshold?:
Might it be that the deviation of the elements in relation to the storey is too high?
The only difference between the “two locations” is that the five elements on the left have in common that they have a global X value > 3.000m whilst the rest is below. But this might just be a coincidence as well …
#1

#2

-
@JSN
I think your problem does not lie in the global coordinates but rather on the definitions of your components in relation to the floor.
What I find strange is the huge value you have for the Unter- and Oberseitenhöhe (46m). In addition the positive values of these categories make it more strange, even though we are talking about a foundation which should be in the negative area.
In my opinion, these values should be in mm or even <1m value.
As an example, here is a value of a foundation from my model that is found 3 storeys under ground floor.

Or do you know why these values are so huge?
-
That is indeed a good observation. The floors itself do have the correct values, and the element relation is working as well.

However the model itself is exported from a survey point to ensure the correctly georeferenced location - not just x/y but also in z direction.
Unfortunately the effect of the survey point does not work when it comes to the building stories. Not sure if this is an exporting issue but afaik this is handled similiar in all authoring tools. Anyhow this has not yet been a big issue so far - the initial topic here isn’t one either to be fair - but it is definitely something worth to discuss. -
what do you mean “exported from a survey point”???
As I understand you, your model sits in the BIM authoring tool according to the height of the georeferencing (probably WienerNull). That is the reason why those elements have a Globale Unterseitnhöhe 45,85m and Oberseitenhöhe 46,45m, in which results a storey height of 0,60m. That is the reason why the next level is at -46,45m.
So if this model is coming from the surveyor and your other model has coordinates related to the relative system of 0,00… this could be the reason why Solibri identifies this as an error in distance.
In practice we define the EPSG Coordinates in the IfcSite, and from there alle related components get their relative coordinates. -
The model is located close the internal origin of the authoring tool and therefore also the building storey heights are referenced according to the project origin. The survey point on the other hand is used to ensure the correct location of the elements within the IFC as this is then decisive for the IfcSite and all the relative coordinates. How are you specifiying the IfcSite, solely within the project location settings or in the SP settings as well?
The situation here is however confusing me now totally as I have double checked it with another model which has basically the same setup and there the parameter are reflected correctly (beside a minor issue). In a third one it’s for whatever reason similiar to the screen from above.

So, this is now something I have to investigate further to understand the reason of this habit. At the moment it’s not really causing a big issue, but it might and what’s worrying me is that I do not really know the reason for it. If you have an explanation for this I would be happy to hear your thoughts.
Apart from that, there is just one model loaded in Solibri and for some reason it gets “split up” between 2,9 and 3k - as solely this value seperates the five foundations from the rest - which fostered my suspicion that there might be an issue with the tolerance itself. Anyhow it could be also related to the other observation, but without an answer from Solibrians we won’t know for sure.

-
J JSN referenced this topic on
-
J JSN referenced this topic on
Copyright © 2025 Solibri Inc. | Powered by NodeBB
