Design Rule: Features within Catchment

How Optioneer can 'look beyond the centerline' and report on important features within specified catchments of the centreline.

Adam Anyszewski avatar
Written by Adam Anyszewski
Updated over a week ago

Design Rule Purpose

The purpose of this design rule is to report on the number of individual features that can be found around a centreline. The User is provided with individual option metrics which show the totals, disaggregated by feature type. This information is useful when comparing various options and assessing the viability of corridors.

How to Configure

There are three configurable parameters for this design rule which refer to defining three catchment distances in terms of meters.

There are three versions of this data that act on three distinct datasets:

  • Constraints

  • Environmental

  • Linear Feature

Once values are defined by the user, the number of features will be calculated with respect to the input alignments. In this example, we are presenting two alignment options, west (blue) and east (red).

The result for west route alignment (blue) catchment area is as follows. GIS features which are within the catchment are highlighted in the figure below.

For the east route (red) the alignment is as follows. GIS features that are within the catchment are highlighted in the figure below.

The condition of the for a GIS feature to be included in the catchment of the route is that, if any part of that feature overlaps with the 'catchment' area, the feature will be included as present in catchment. It is up to the user to later define how severe the impact of the feature presence is.

Important Notes

  1. Boundaries are defined from the centerline to the boundary. That means that catchment includes everything that is narrower catchments too.

  2. Defined catchments to not appear on the map. User receive metrics which summarise how many features are present. Other design rules can help identify which features pose the highest risk, while this design rule allows for a quick, quantitative assessment.

  3. If Optioneer is used in generation mode, information about features within catchment of the route is not used to determine the optimal path but it provides richer information to the user.

  4. Currently, the GIS datasets used in this design rule are not configurable. The design rule will use 'constraints', 'environmental' and 'linear features' datasets by default.

  5. The numbers reported are dependent on how underlying datasets are structured. Sometimes a road might be split into sections, sometimes a few buildings can be represented as a single polygon. Despite this limitation of GIS data, usually data layers are consistent throughout a project area and therefore the values are useful for comparison between different options.

Input / Output Summary

Input parameters

Name

Default value

Unit

Distance defining 'corridor'

50

meters

Distance defining 'proximity'

200

meters

Distance defining 'catchment

500

meters

Output parameters

Name

Example value

Unit

'Corridor ' + name of GIS layer.
โ€‹

Example: 'Corridor Buildings'

122

items

'Proximity ' + name of GIS layer.
โ€‹

Example: 'Proximity Offshore Wrecks'

25

items

'Catchment '+ name of GIS layer.

Example: 'Catchment Electricity Transmission Lines'

4

items

Did this answer your question?