Limitations using models from Navisworks
iModel Element Identification and Change Detection
Navisworks objects do not have a stable ID, so the connector creates iModel element identifiers by concatenating the names of their nodes (from the topmost node to the leaf node) in the Navisworks object hierarchy tree.
The selected object from the Navisworks model in the figure gets the element identifier 3D COLUMN[1]/3D Solid[6] in the iModel.
The names of source model files that are nodes in the Navisworks object hierarchy tree are included as part of the iModel element identifiers, so changes in the name of an exported file node from Navisworks shows up as deleted-added on all iModel elements within that subtree during change detection.
The selected Navisworks object in the figure has the element identifier Columns02.nwd[2]/3D COLUMN[1]/3D Solid[6] in the iModel. For example, changes in the Navisworks file results in a node name Columns02.nwd to Columns03.nwd and results in changes in to the element identifier to Columns03.nwd[2]/3D COLUMN[1]/3D Solid[6], the element will be deleted and added during change detection.
- Navisworks geometry fragments do not have a stable ID, so the same exact geometry does not necessarily show up as unchanged during change detection; they can show up as changed when there is a new set of fragments added to the Navisworks model, regardless if the new fragments were added to a different geometry.
- Navisworks objects can have the same name, so the connector appends index numbers to iModel element identifiers. If the iModel elements are getting computed with the same identifier and they have different geometries, they will show up as changed during change detection.
The selected Navisworks objects in the figure gets element identifiers 3D COLUMN[1]/3D Solid[1], 3D COLUMN[1]/3D Solid[2], 3D COLUMN[1]/3D Solid[3], 3D COLUMN[1]/3D Solid[4], 3D COLUMN[1]/3D Solid[5] and 3D COLUMN[1]/3D Solid[6] in the iModel; index positions are added to the element identifiers.
Referenced reality data misaligned in an iModel
Symptom:
Users report that reality data does not align accurately with the content of DGN files when viewed in iModels.
Issue:
This alignment issue arises from the differing coordinate systems used by the reality data and the iModel. Specifically, the reality data employs a Geocentric coordinate system, whereas the iModel relies on the Geocoordinate system defined by the DGN file.
For example, if the DGN file utilizes the NAD27 geodetic datum, it's important to note that NAD27 and the Geocentric coordinate system are founded upon different ellipsoidal models. These models' assumptions regarding the Earth's shape, size, and initial meridian references differ. Consequently, positional discrepancies can occur due to these fundamental differences when attempting to overlay or integrate reality data with DGN files in iModels. In the Central United States context, users may observe that these discrepancies typically range from approximately 3 to 20 meters.
Resolution:
The issue of coordinate system mismatch leading to alignment inaccuracies between reality data and DGN-file-based iModels is recognized as a current limitation.
For additional assistance, updates on the matter, or potential workarounds, please contact Bentley Support directly (https://bentleysystems.service-now.com/csp)