1. Background

One of the greatest strengths of OpenRoads Designer is its parametric modeling philosophy, particularly the template system inherited and continuously developed from earlier Bentley civil products such as InRoads and GEOPAK.

The ITL template library is an exceptionally powerful concept. Its capabilities extend far beyond simple geometric constraints. Templates can incorporate points, components, parent-child relationships, parametric constraints, display rules, end conditions, priorities, alternate solutions, and other conditional behaviors.

As a result, a corridor template can be understood almost as a small parametric geometric program. When an input changes, OpenRoads can regenerate the resulting geometry according to the relationships defined in the template.

This dependency-based philosophy is one of the strongest aspects of the Bentley civil modeling environment for both OpenRoads and OpenRail Designer softwares. However, there is significant conceptual discontinuity when those dependencies extend beyond an individual model or DGN file.

2. The Conceptual Problem: Parametric Dependencies Across DGN Files

Large OpenRoads projects cannot reasonably be developed within a single DGN file. For performance, worksharing, responsibility assignment, ProjectWise workflows, and BIM management purposes, the project is usually divided into multiple files.

A simplified dependency chain may be represented as:

Geometry.dgn → Superelevation.dgn → Primary Corridors.dgn → Secondary Corridors.dgn → Drawings.dgn → Sheets.dgn

In practice, the dependency structure can be considerably more complex. A primary roadway corridor may generate an Edge of Shoulder feature, while a second corridor uses that feature as a control for a barrier, retaining wall, grading element, gore area, or another roadway component.

OpenRoads understands many of these relationships at the civil-object level. However, when the objects are distributed across several referenced DGN files, changes are not necessarily propagated automatically through the complete project dependency chain. THIS IS CREATING AN IMPORTANT BIM MANAGEMENT PROBLEM IN LARGE PROJECTS.

3. A Typical Example

Consider a geometry file containing the horizontal and vertical alignment of an Express Lane. That geometry is referenced by a superelevation file and by one or more corridor files.

A primary corridor generates 3D features such as Edge of Pavement, Edge of Shoulder, Median, barrier control lines, and grading limits. Other corridor models may then use those generated features as external controls.

Alignment / Profile → Superelevation → Primary Corridor A → 3D Edge of Shoulder → Secondary Corridor B → Barrier / Wall / Grading → Drawings and Sheets

A change to the original alignment may therefore affect every object downstream of that change. Updating the original Geometry DGN does not necessarily guarantee that every downstream DGN has subsequently been opened, regenerated, processed, and saved in the correct dependency order.

The project may therefore contain models that are internally valid but represent different generations of the design. This is particularly dangerous because an outdated downstream model may appear geometrically correct when opened or referenced, with no immediately obvious indication that its upstream source has changed since the model was last processed.

4. BIM Execution Plans Currently Compensate for This Limitation

On large projects, this issue is often managed procedurally through the BIM Execution Plan (BEP). A typical workflow may require geometry to be updated first, followed by profiles, superelevation, primary roadway corridors, secondary/dependent corridors, terrain or grading models, drawings, and finally sheets.

This works, but it effectively means that the BIM Execution Plan and the project team are manually performing a function that should ideally be managed by the software itself. The BIM team is effectively maintaining a project dependency graph outside OpenRoads.

This introduces a significant human dependency into an otherwise highly parametric modeling environment.

5. Limitations of Batch Processing as a Workaround

Batch processing can partially automate regeneration. A batch procedure can sequentially open a collection of corridor DGN files, execute the appropriate processing command, save each file, close it, and continue with the next file. For a large project containing many corridor models, this can already be a very time-consuming process.

More importantly, the correct processing sequence may itself contain dependencies. Consider two corridors stored within the same project folder:

Corridor A → Generated 3D feature → Corridor B

Corridor B may depend on a feature generated by Corridor A. A typical example is a gore area, where the geometry or template behavior of Corridor B is controlled by a feature generated by Corridor A.

In this situation, simply processing all DGN files in a folder is not enough. The system must guarantee that Corridor A is successfully regenerated before Corridor B is processed. The same situation may occur recursively: Corridor A → Corridor B → Corridor C.

Therefore, the problem is not simply one of batch processing. It is fundamentally a dependency-graph and processing-order problem. Unless the batch process explicitly understands the dependency relationships between civil objects contained in different DGN files, there is no guarantee that the processing sequence corresponds to the required dependency sequence.

Alphabetical file order, folder order, ProjectWise order, or any other arbitrary file sequence is not sufficient. WHAT IS REQUIRED IS A TOPOLOGICAL PROCCESSING ORDER DERIVED FROM ACTUAL CIVIL DEPENDENCIES.

6. Proposed Solution: Project-Wide Civil Dependency Manager

OpenRoads and OpenRail, OpenBrideg Modeler would benefit greatly from a project-level Civil Dependency Manager. The system would automatically identify dependencies between civil objects, including dependencies that cross DGN boundaries.

Conceptually, the project could be represented as a directed graph G = (V, E), where V represents civil objects or DGN models and E represents dependency relationships.

Geometry → Superelevation → Corridor A → Corridor B → Barrier Corridor → Drawing → Sheet

Once this graph is known, OpenRoads could automatically perform a topological sort and determine the correct processing sequence. The user would no longer need to know or manually maintain the exact regeneration order.

7. Dependency Status

Each civil model or DGN could have a clearly identifiable status such as Current, Out of Date, Upstream Dependency Changed, Processing Required, Broken Dependency, Missing Reference, or Processing Failed.

A designer changing an alignment would therefore immediately understand the downstream consequences of that modification. This can be partially known using the Dependency Viewer Tab in ProjectWise but this functionality is far away to solve the problem.

8. Automatic Topological Processing

The Dependency Manager could provide a command such as “Process All Out-of-Date Dependencies.” OpenRoads, OpenRali, OpenBridge would then determine the required sequence automatically, based on the actual dependency graph rather than file names or folder organization.

If Corridor B depends on Corridor A, OpenRoads must guarantee that A is successfully processed before B, regardless of where those files are stored or how they are named. If processing Corridor A fails, the system should not blindly continue processing Corridor B. Instead, Corridor B and all its downstream dependents should be flagged accordingly.

9. Change Propagation Rather Than Immediate Reprocessing

Automatic dependency management would not necessarily mean that every change must immediately trigger regeneration of an entire project. On very large projects this could be computationally inefficient.

A better approach would separate change detection from model regeneration. When Geometry changes, OpenRoads could immediately mark the downstream superelevation, corridors, barriers, drawings, and sheets as Out of Date. The user or BIM manager could then decide when to execute “Process All Out-of-Date Models.”

This would preserve performance while guaranteeing model consistency.

10. ProjectWise Integration

ProjectWise would be a natural environment in which to extend this concept. When a Geometry DGN containing modified civil objects is checked in, ProjectWise/OpenRoads could identify all downstream civil dependencies and mark the corresponding documents as potentially out of date.

This could provide project-level visibility without requiring every dependent DGN to be manually opened merely to discover that an upstream dependency has changed. Responsible designers would immediately know that their models require regeneration or review.

This would also significantly improve multidisciplinary coordination and auditability.

11. Dependency Viewer

A graphical dependency viewer would be particularly valuable. It could show the project as a navigable dependency tree or graph and allow users to select any civil object and answer two critical questions: “What does this object depend on?” and “What depends on this object?”

Geometry → Superelevation → Main Corridor → Gore / Barrier / Retaining Wall Corridors → Drawings → Sheets

Such a viewer would be useful not only for processing but also for troubleshooting complex OpenRoads models.

12. Why This Fits the OpenRoads Philosophy

This proposal would not require changing the fundamental modeling philosophy of OpenRoads. On the contrary, it would extend that philosophy to the project level.

OpenRoads already provides sophisticated dependency management inside individual civil models. The ITL template system is an excellent example: Points → Constraints → Components → Display Rules → End Conditions. Similarly, civil objects already establish relationships such as Alignment → Profile → Corridor → 3D Features.

The missing layer is project-wide dependency management across DGN files. OpenRoads is already highly parametric at the object level. The next logical step would be to make the entire project parametrically aware.

13. Main Benefits

A Project-Wide Civil Dependency Manager would reduce the risk of outdated corridor models, automatically identify downstream impacts after geometry changes, guarantee topological processing order, reduce dependence on manual BIM Execution Plan procedures, make batch processing more reliable, improve coordination between multiple designers, strengthen ProjectWise workflows, simplify troubleshooting, and provide clear visibility of upstream and downstream dependencies.

Most importantly, it would address a fundamental contradiction in the current workflow: OpenRoads provides an extremely powerful parametric modeling environment, but maintaining those parametric relationships across a distributed multi-DGN project still requires significant manual coordination.

14. Core Principle

OpenRoads should not only know how to regenerate a civil model. It should also know which models need to be regenerated, why they need to be regenerated, and in what order they must be regenerated.