Best Practices for Creating a Civil iModel

Best Practices for Creating a geolocated iModel

When source files consist of Power Platform based models (*dgn)

• Reference all the data into Master models. If everything is referenced into 1 Master model, it is enough to map this model and all the references will be processed automatically.
• References should not be mapped separately. 
• If necessary, the Master model can be split into several Master models which would contain their own references. In that case, one model needs to be mapped as a Spatial root model which could have GCS defined and rest of the Master models are mapped as Master models.
• Grouping of Master models depends on the user needs, e.g. grouping by discipline.
• When connecting to federated models to iTwin, any reference files with visibility/display ‘off’ will not be published in iTwin

The Role of the Active View Group

When importing a source master file, DGN-based connectors use the first view from the active view group--what you see when you open the DGN--to determine the starting 3D design model.
If the first view does not have an appropriate root model, the other open views are examined--in numeric order--until an appropriate root model is found.
If an appropriate root model is not found through the active view group, the open views in the other view groups are examined. This quiet processing is why a 3D master model is still found when the active view group shows a drawing or a sheet.
If no 3D model is found via the view groups, the default model is used. This may be a 2D model that will result in a "No spatial models found" warning.

If the results in the iModel do not match your expectation for the model imported, the best practice is to click Save Settings in the PowerProduct with the desired 3D model active.

Importing Drawings and Sheets

Per the MicroStation Online help:

• A drawing model is a subset of a 2D or 3D design model, used to apply annotations, dimensions, callouts and other embellishments to a design. By default, the view windows of a drawing model have grey background.
• A sheet model is a type of model that serves as an electronic drawing sheet. It typically consists of design model references that are scaled and positioned to create a printable drawing. By default, the view windows of a sheet model have white backgrounds.

Drawing models and sheet models are imported into an iModel along with the design models However, more drawing and sheet models may be imported than you expect. A DGN-based connector imports:

1. Every drawing model and sheet model found in the source master file and any other DGN containing a displayed reference attachment.
2. Every drawing model and sheet model found in "reachable" DGNs. This means DGNs linked via:
   1. Saved views
   2. Named groups
   3. Link sets
   4. Displayed reference attachments to any model in the DGN.
   5. Graphic elements with explicit Design links.
3. Embedded files found in DGN files.

The "reachable" process in #2 is iterative in that if a DGN is added to the running list, it, in turn, is checked for links.

Levels

Levels are converted to Categories in the iModel.  Unlike in Power Platform where different references can have different definitions for the same named Level, all models under the root model will share the appearance for a Category.  The first time the DGN-based connector encounters a level, it will use that definition for the appearance (color, weight, line style).  If a reference has a level of the same name but a different definition, the discrepancy will be reported but the category's appearance will not change.

Similarly, if the level's definition is changed in Power Platform, it will not be propagated to the iModel on an update. The DGN-based connector cannot determine whether this as a deliberate change of the original definition or a conflict, so it maintains the original definition.  If the appearance needs to change, a new level should be created and all elements assigned to that new level.  Or, with the help of Bentley Support, the master file can be unmapped, the old definitions purged, and then the file remapped.  This will cause all elements to lose their version history, though, so should not be used lightly.