Overview

This article outlines a federated OpenX Designer file strategy designed to separate disciplines and linked objects, establish consistent file naming and documentation, and control reference nesting. Following these guidelines helps preserve project performance, enable concurrent multi-user access, and protect dynamic civil relationships.

1. Federated File Structure

• Deliverable-Driven Planning: Plan the file structure around final deliverables, project disciplines, project stages, quantity needs, and sheet requirements.
• Separation of Components: Store distinct civil components—such as terrain, geometry, corridors, superelevation, control features, sheets, cross sections, and civil cells—in separate design files rather than consolidating them into one large master file.

2. File Naming and Documentation

• Logical Naming Conventions: Utilize standardized folder structures and file names that clearly identify the route, discipline or data type, and specific project component.
• Model Management Plan: Maintain a model management plan or tracking spreadsheet recording each file's contents, reference attachments, descriptions, corridor edits, template drops, display rules, point controls, parametric constraints, and dependencies.

3. Performance and Multi-User Collaboration

• Performance & Safety: Smaller files load and process faster, simplify file discovery across disciplines, allow multiple team members to work simultaneously, and minimize the risk of total project loss due to file corruption.
• Early File Separation: Separate files at the start of the project. Splitting consolidated files late in the design process requires creating file copies and risks breaking dynamic civil relationships.

4. Separation of Linked Objects

• Avoid Combining in Corridor Files: Do not create proposed terrains, civil cells, sheets, superelevation, cross sections, or control lines directly inside corridor files. Placing these objects inside a corridor file triggers re-processing whenever corridor modifications occur.
• Dedicated Control Geometry: Control lines and geometry shared across multiple corridors should reside in a dedicated control file.

5. Live Nesting and Container Strategy

• Managing Nesting Depth: While live nesting displays elements from nested references and reduces manual attachment steps, excessive nesting leads to duplicate references, circular reference loops, complex dependency cross-webs, and performance lag.
• Best Practices:
  • Establish container files early in the project setup.
  • Keep design-file live nesting depth capped at 1 or 2 levels.
  • Ensure master geometry and corridor container files reference individual design files directly.

6. Reference Rules, Dependencies, and Detachment

• External Civil Rules: Snapping to an element within a reference attachment creates a persistent civil rule/dependency, even though the element is not in the active file. Disable snapping or selection on reference attachments when appropriate.
• Safe Reference Detachment: Review element dependencies in the Civil Display Browser before detaching references.
• Protect Foundational References: Never detach foundational reference files (e.g., base alignments) without reviewing dependencies, as doing so can break downstream corridors, sheet models, and station-based annotations.

7. Path Management (Save Relative Path)

• Local Project Management: For locally stored and managed projects, enable Save Relative Path in the References dialog to ensure reference links remain intact if project directory structures are relocated.
• ProjectWise Integration: Projects managed within Bentley ProjectWise automatically handle reference path resolution via ProjectWise dependency management.

8. Sheet Display Control

• Display Overrides: Level display control in sheet files is governed by display overrides, determining whether levels are controlled directly within the active sheet or inside a container file.
• Attachment Hierarchy:
  • A direct reference attachment structure allows sheet files to control level display one level back.
  • When deeper live nesting is required, level display must be managed within the container file or through purpose-specific container files.

9. Annotation File Placement

• Dedicated Label Files: Place plan view annotations in a dedicated label file (preferably within the Default Model) so annotations persist and are retained when sheet views are regenerated or recut.
• Attachment Choice: Select direct attachment or nested attachment depending on whether level and element display should be controlled from the sheet file or from the container file.

10. Reference Updates and Line Styles

• Reloading References: Changes made to referenced design files can be reloaded directly via the References dialog, regardless of whether live nesting is enabled.
• Global LineStyle Scale: The impact of Global LineStyle Scale settings across nested reference structures requires project-specific verification and testing.

11. Corridor Container Processing and Performance

• Container Overhead: Corridor containers primarily serve as display vehicles for corridor elements and do not process or evaluate the live corridor's parametric constraints.
• Performance Factors: While corridor containers do not inherently create processing overhead or dependency errors, overall system performance remains influenced by project complexity, reference hierarchy depth, ProjectWise retrieval times, and corridor model organization.