Candidate Selection
Candidate Selection
Candidate Selection is the process of pre-selecting viable elements to be considered for treatment. It is a filter process that removes elements from consideration where they are clearly not in need of, or suited for, treatment based on the current condition.
The primary purpose of Candidate Selection is to reduce the number of elements put forward for possible triggering of one or more treatment types and then - if treatments are triggered on such elements - put forward into the Optisation stage. By filtering out elements that clearly do not need a treatment, the burden on the Optimisation stage is significantly reduced, and with it also the model run time.
Once the candidate elements to be considered for treatment are selected, the model will execute further logic to determine which treatments can realistically be considered for treatment. Note that more than one treatment type is typically considered for each candidate element. It is then the job of the optimisation algorithm to determine the optimal set of treatments to be applied to which candidate elements.
Candidate Selector Class
In the Default Road Network model, a dedicated C# class called ‘CandidateSelector.cs’ holds all the logic that determines which elements are viable candidates for treatment.
Users should refer to the latest open source version of this class for up-to-date details about the rules involved in Candidate Selection. Below are some of the rules applied in then current (Sept-2025) model:
1. Consider Earliest Treatment Period
The Earliest Treatment Period is an element specific value that can be assigned to each element in the model input set. The value should be stored in the ‘file_earliest_treat_period’ column in the input set. Note that this value should be the modelling period (i.e. 1,2,3, etc) and not the calendar period (i.e. 2025, 2026, etc.).
If the current modelling period is less than the specified earliest treatment period for the element, the element will NOT be considered for treatment.
The Earliest Treatment Period value specified in the ‘file_earliest_treat_period’ column allows you to exercise fine-grained control over when specific elements can be considered for treatment.
This is useful in cases where an element may already be in a poor condition, but you want to delay the treatment because there are some developments scheduled to take place in say two years from now and you do not want to treat that element before that time.
2. Is a Second Coat Needed?
If a chipseal section has recently been rehabilitated and a follow-up coat is needed, then the element is automatically considered for treatment. This rule is dependent on the Surface Function code. A second coat is deemed to be required if the surface function code is “1” (recently rehabilitated) or “1a” (pre-seal repairs carried out in preceding year).
3. Is there a Committed Treatment in the Near Future?
If there is a committed treatment scheduled within a certain number of periods from the current period, then the element is NOT considered for treatment.
The minimum number of periods to a committed treatment allowed is a lookup variable in the ‘candidate_selection’ lookup set with key ‘min_periods_to_next_treat’. You can modify this value in the lookup set as needed.
4. Surface Life Achieved below Specified Threshold?
If the element is not in need of a second coat, and the Surface Life Achieved is below a specified minimum, then the element is deemed to be “too recently treated” and is NOT considered for treatment. This check is in place to prevent newly treated elements from being considered again for treatment when a second coat is not explicitly needed (check 2 above).
There are separate thresholds for minimum SLA for Asphalt and Chipseal surfacings. Both thresholds are lookup variables in the ‘candidate_selection’ lookup set with keys ‘min_sla_to_treat_ac’ and ‘min_sla_to_treat_cs’ for Asphalt and Chipseals, respectively. You can modify these values in the lookup set as needed.
5. Is a Minimal Distress Threshold Reached?
A final check is done to ensure that the element has reached a minimal distress threshold. These thresholds can be modified in the lookup tables, and for certain networks where age (and not condition) is a key determinant for treatment, you may want to open up these thresholds to allow more elements to be considered for treatment.
There are currently two ‘gates’ that control the minimum distress threshold - one that considers surface distress by looking at the Surface Distress Index (SDI) and another that looks at the Pavement Distress Index (PDI). The thresholds related to these two indexes can be controled by the lookup variables ‘min_sdi_to_treat’ and ‘min_pdi_to_treat’ in the ‘candidate_selection’ lookup set.
Note that an element will be considered for treatment trigger checking if either of the two minimal condition thresholds are met.
The above summary provides only a general outline of the aspects involved in Candidate Element selection. For a detailed understanding of the most up to date Candidate Selection logic, consider downloading the C# Project and inspecting the CandidateSelector.cs class.
For information on how and where to access the C# code for the default road network model, please contact Lonrix.