Design rules are built by Continuum Industries and inspired by engineering and routing common sense, standard practices and suggestions from users. They cover most aspects of what a complete routing and early design study should take into account.

Critically, the design rules' code is not editable by the user. Users can vary parameters in design rules built by Continuum Industries (that's us, people behind Optioneer!). We will continuously improve and expand the scope of design rules; users can share their suggestions to influence the development roadmap. Moreover, we are open to building custom design rules upon request - let us know if that is of interest.

All evaluations in a given engine run (a single case set up by Optioneer app user) use the same design rules and parameters. Moreover, all evaluations share the same underlying geospatial dataset. Each option uses its own route attributes and a subset of geospatial data (sampled along the route).

Dependencies between different types of inputs and data sources are summarised in the diagram below. The diagram uses three ‘example’ design rules which cover crossings, geometry and path selection.

Design rules evaluate three fundamental quantities:

Some design rules only evaluate objectives or constraints and some, in rare cases, only calculate metadata (usually when the design rule is in early stages of development). Once evaluation is complete, objectives, constraints and metadata are aggregated from all design rules. The result of this calculation is later used to determine how good a given option is in comparison to others.

In the example above, the ‘Geometry’ design rule doesn’t add to the objective value and only contributes to constraint violation and metadata.

In general, Optioneer concentrates on ensuring that solutions are feasible (i.e. constraint-free) and optimal (i.e. the objective value, such as cost or penalty are minimised).

Objectives' calculation in Optioneer relies on calculations of different engineering quantities such as length, area, volume, or ‘number of’. These quantities are found based on engineering models and geospatial data; the methods are explained in detail in sections describing individual design rules.

Constraints are similar and their values are calculated as proportional to constraint violation - the larger the constraint violation, the higher the value. They are usually defined as a ratio of value to the limit, instead of depending on engineering quantities.

The example below explains how the design rules' evaluation happens (at a very high level). In this example, Optioneer evaluates designs based on path feasibility and cost, geometry and linear feature crossings.

Option A and Option B are both candidate options for connecting the same two endpoints. Both designs go through an Ancient Woodland, but Option A covers a longer path through the area than Option B does. If going through an Ancient Woodland is defined as a constraint, Option B will be preferred over Option A. Geometry constraints seem fine for both Option A and Option B.

Both Options cross a few different types of linear assets. Option A, however, avoids two crossings that Option B goes through which means that if every crossing carries a cost associated with it, the overall cost of crossing other linear infrastructure will be lower for Option A than Option B (which makes it a preferred choice from this perspective).

The table illustrates how objectives are aggregated. Constraints follow similar logic - they are added up from different design rules and the final value is used to determine the overall quality of proposed option.

NB: The example above uses arbitrary ‘cost’ as a score. This score can be expressed in terms of real capital costs (if the data is available) or penalty points or any other metric that the user is interested in. The engine can be configured to use a single objective type at the moment.

Design rules are only one part of Optioneer engine and are used in the evaluation step. Together with generation of options and shortlisting of the best ones, Optioneer can use design rules to suggest good quality, feasible designs to users.

In the example used before, the Optioneer engine would find Option C that combines the ‘best of both worlds’ from Option A and Option B. In this instance, Option C will be preferred over Option A and Option B (avoids Ancient Woodland and minimizes the number of crossings).

The three Options' evaluated parameters are summarised in the table below.

Option C has a higher objective than Option A (which means it is a bit ‘worse’ in terms of the objective) but doesn’t violate any constraints. In this situation, Option C will be suggested to the user as the best result as it is feasible first and then of good quality.

In absence of Option C, the Optioneer engine would suggest Option B to the user as it is more feasible than Option A, despite the higher cost. The balancing between objectives and constraints is a challenge for Optioneer engine and something that the team at Continuum Industries are actively investigating (and improving).