Design Rule Purpose
The purpose of this design rule is to identify crossings with existing linear features (roads, railways, power lines, water courses etc.) and minimise the cost and risk of these crossings where possible. Crossings are disaggregated by type of feature crossed. There are various parameters that can be enforced on a crossing, by type - the method used, associated cost, minimum required crossing angle etc. This design rule can be used in both generation and evaluation modes.
How to Configure
Optioneer analyses millions of possible centrelines when generating options; each of these options will likely interact with a lot of various existing linear features.
The first operation that this design rule performs is identification of crossings. Locations and types of crossings along the centerline are recorded as part of option parameters.
Optioneer takes in the information provided in system config and the dataset to identify all crossing positions, numbers and parameters, disaggregated by crossing type.
Configurable parameters of each crossings are summarised in diagrams below. More detail is given in the Input and Output Section of this Article - see here.
Alike to the Environmental and Routing Constraints design rule, undesirable crossing types can be minimised by assigning a higher penalty.
Calculation of the crossing angle is approximate and can sometimes be off by up to 5 degrees. This is due to a fast-crossing-detection method that Optioneer uses which is based on a down sampled map.
Optioneer might struggle to find feasible solutions if a lot of complex linear features are packed in a small area; this is due to sampling resolution and the fact that Optioneer can't handle very fine adjustments of the route. Please see the best practices section at the bottom of this article for how to best deal with routing through areas congested with linear crossings.
Start and end points of the route shouldn't be placed in linear feature crossings.
If Optioneer cannot find a diverse range of solutions which meet the criteria specified by the User, it may suggest some route which violate the minimum angle change.
Input & Output Summary
This design rule requires a specific dataset called 'linear_features'.
Please note: values below can be configured by-type of linear feature as provided in the 'linear_features' dataset. If a given type of linear feature doesn't have a specific parameter set, the default values will be used which are also configurable.
Min. crossing angle
Crossing cost (per individual crossing)
points (can be currency if the rest of the project is using currency as a measure)
Average level of linear feature
Average width of linear feature
Crossing clearance required
Permitted crossing angle constraint violation (see note below)
The 'Permitted crossing angle constraint violation' parameter allows Optioneer engine to consider options that violate some crossing angle requirements and proceed with optimising these options and presenting results to the user. Thanks to this, Optioneer doesn't spend most of its runtime trying to find a very clever solution for a tricky situation, but comes up with an acceptable solution and develops the option further as a whole. The user can later use in-app tools to resolve issues manually.
Total number of crossings
Total cost of crossings
Number of crossings [by type]
crossings of [linear feature type]
Locations of crossings
N/A, see below for view in Optioneer and via Excel exports
location-at-index, by type
plot on Vertical Profile Chart and Map
Example offshore project in Optioneer - see Map Chart, Vertical Profile Chart and option metrics on the right-hand side.
^^ Remove this and have something like this- this
Information shown in the screenshot above can be also exported for use outside of Optioneer: