Generating options
The Optioneer engine takes user-defined start and endpoints (and waypoints) to build the initial vertices of the route. It then places points between user-defined areas of interest and uses interpolation functions to ‘connect the dots’ into a route. This process happens simultaneously in both horizontal and vertical planes.
These points are the fundamental building block of every option evaluated by the Optioneer engine. They enable the engine to derive a range of attributes for each route option (more below on evaluation). Attribute values are sampled around every 30 meters.
NB: In cases where a route has already been defined and so the points are effectively fixed in the horizontal plane, users can also input this route into Optioneer to evaluate it and generate a corresponding vertical profile. We refer to this type of use case as 2D optioneering rather than 3D optioneering.
Evaluating options
The evaluation step is performed for every route option generated by the Optioneer engine.
In simple terms, the engine builds the input geospatial data into a raster dataset, takes the set of points and attributes for each route option generated, and then passes all of this data through a set of so-called ‘design rules’.
Design rules
Design rules are units of design logic that can be used to check compliance with engineering or environmental requirements, calculate basic quantities, estimate capital or operational costs, and derive other metrics using a combination of geospatial data, user-defined parameters, penalties and costs.
Geospatial data
The Optioneer engine uses raster datasets and is capable of automatic conversion of vector datasets into raster data and applying the necessary transformations to make sense of the data. A couple of examples of data used by the Optioneer engine are shown below.
Shortlisting of best options
Evolutionary computation
The process of generation and evaluation is repeated until a range of good solutions (options) is found and returned to the user. Optioneer uses a suite of evolutionary algorithms which work on the basis of the machine creating a lot of potential solution candidates and then comparing these against one another to determine which option should be suggested to the user. This approach is very similar to natural evolution and survival of the fittest - hence the name evolutionary computation.
The process
The diagram below uses slightly more technical language to describe the process. In short, the Optioneer engine first creates (usually a few hundred) candidate routes and evaluates these. These options are then ranked and the best solutions are kept and the worst are discarded. Good solutions are then recombined, mutated and evaluated again to determine if a better solution can be found. The process is repeated, usually a few hundred times, until Optioneer arrives at the final set of options that are presented to the user.
Limitations
Optioneer uses evolutionary computation technology as it is very versatile and allows the engine to tackle multiple types of problems in various locations around the globe. The user has control over the criteria upon which evaluation is done and can therefore have control over the process. This, however, comes with a few limitations:
Optioneer can be sensitive to wrong input assumptions as it doesn’t understand the engineering logic. It is up to the user to ensure that the configuration is correct.
Optioneer will struggle in situations where no good solutions can be found. As the engine works on the basis of ranking and comparing, it will struggle to determine what is better if all solutions appear bad! An example of this might be if start and end points are in no-go zones or if there is no feasible at all between the two points.
As Optioneer explore the problem from a ‘fresh start’ each time, even runs that feature the same inputs might return results that are not exactly the same. Results from multiple runs should used to highlight areas where the most suitable solutions can be found.
As the process is very computationally expensive, a single evaluation has to be very quick (to allow millions of operations to happen within a reasonable timescale). As a result, the models used in Optioneer are usually a good approximation of a more sophisticated model which can be used at a later stage of the design process.