At Continuum Industries (CI), we have worked on infrastructure projects ranging from a few hundred metres to several hundred kilometres. While these projects may be for similar assets - for example, an electricity transmission line - the focus of the analysis tends to differ depending on their scale and therefore they benefit from a tailored approach when working in Optioneer.

This article will outline some key considerations we suggest you keep in mind if you are working with a high number of any of the following project features:

If you are working on a specific project with us then it is highly likely we have collectively built up a project data register with the required datasets, GIS operations and 'scoring' (or 'weightings') for use in Optioneer.

Data registers serve as a log of the different assumptions used to arrive at the final setup in Optioneer. If your project covers areas with fundamental differences - for example, offshore portion and onshore portion - then we recommend keeping these in separate areas of the data register. Additionally, leave a column for dated and signed comments so that decision making is recorded. This allows specialists in the project team to easily navigate where they should provide input. Furthermore, Optioneer has been developed to specifically assess either offshore or onshore assets in order to capture the greatest level of design logic for each asset type.

It is worth noting that data layers should be aggregated where possible to minimise the number of layers per dataset. For example, if all rail crossings are equally prohibitive to development then we recommend keeping this as one layer rather than splitting into each subtype (single track, multi track, narrow gauge etc.). This keeps the project area from becoming overly detailed and ensures the software works optimally. However, in the case that you will need to understand how many single track crossings a route will require verses multi track crossings, then upload these as separate data layers. Optioneer cannot disaggregate GIS data internally so upload the data based on the outputs you require, only disaggregating to the required level of detail.

Configurations are unique combinations of design parameters (specified in the "Parameters" page in Optioneer) that can be used to evaluate route options. Think of them as a collection of assumptions that can be modified and saved as the project progresses. A read-only copy of the Configuration used to produce each set of Results is stored to maintain a record of evolving project assumptions. In the figure below you will see the 'Past results (Read Only)' option in the Parameters page -toggle this to view or hide the read-only Configurations.

Since the 'live' set of Configurations may be edited, and there may be many Configurations per project, we recommend naming them in a systematic manner to maintain clarity. For example, one format that we have used to date:

YourInitials_Objective_CreationDate[YYMMDD]

So for Jill Bloggs looking to create a Configuration that will generate routes prioritising environmental feasibility, her Configuration name might be:

JB_Environment_220311

Note that whenever Results are calculated with a particular Configuration, a time-stamped record of this is maintained. Therefore, the CreationDate part of the name is simply for a quick reference when scanning over and selecting particular Configurations. It may be necessary to add version numbers (v1, v2, v3 etc.) if multiple configurations of the same type are generated on the same day. We would recommend avoiding terminology like 'final' or 'complete' as further iterations may still be required.

As with Configuration naming, the naming of Points and Lines used in the analysis should also be meaningful. Each Point or Line has a unique ID to allow tracking of these data objects in case of name changes. Note that a description field is available for user-generated descriptions of each Point or Line, which has typically been used to capture details for inclusion in the project. For example:

Either in the description or name field, indicate whether the Point is a start point, end point or way point because it is generally important that the Points are selected in the correct order. For example, the order of Points selection for water pipelines may determine whether the scheme is pumped or gravity fed.

Results are produced from Optioneer analysis where Points/Lines are combined with a particular Configuration, which uses a user-specified set of GIS data. Results may be either:

The common base for Results are Options, which are indicative route alignments with stored data which has been calculated during the evaluation of the route.

Results should be named in keeping with naming of Configurations, Points and Lines in that names should be descriptive and meaningful. For example:

StartPointName_EndPointName_Objective

Note that each Result has a unique ID, creator ID and creation Date. Tags may be used to add further detail and classify Results. The Results Library also indicates the status of each set of Results (e.g. running, failed, complete).

Tags can be used to collect different Results you wish to view at once. For example, if you refer to heat maps in a report, tag the relevant Results with 'Heatmap' so these can be made visible simultaneously - this has been done in the example above. A similar thing can be done with the Results that you refer to in the report.

Results may be filtered, deleted, or expanded to look at the underlying Options.

As with all software, the less information you have stored, the more efficiently it will run. We suggest deleting redundant Results and deleting Options from Results that are suboptimal. Please be aware that deleting something on your Optioneer deletes it for everyone in the project space.

Any questions, just get in touch via the chat function!