HomeDeterioration Modelling

This topic covers all elements of Deterioration Modelling in JunoViewer Web

Line Marking Deterioration Model Outline Messages in this topic - RSS

Danielle Turner
Danielle Turner
Administrator
Posts: 3


3/22/2021
Danielle Turner
Danielle Turner
Administrator
Posts: 3
1. Line Marking Deterioration Model Outline

1.1. Conceptual Outline


The JunoViewer line marking model follows a workflow that differs from standard deterioration models. This is mainly due to the following requirements for a line marking model:
  • Line marking improvements generally cannot be effectively applied over short, fragmented segments. Therefore, line marking segments should be relatively long so that areas with a need for improvement can be long enough to warrant intervention in that area.
  • The line marking model should be capable of merging an existing FWP for general road maintenance with a line marking segment set. However, since the segments in a road works FWP will often be shorter than a typical line marking segment (e.g., 500 m), the deterioration algorithm should be capable of handling the merging of several road maintenance interventions within a single line marking segment.
  • The line marking model should include the intelligence to identify which lines (e.g., barrier line or edge line) will be affected by maintenance in the merged FWP. This requires special rules for matching the lane in which road works is being done with the line codes that will be affected by such work.

The deterioration model developed for forecasting of reflectivity is illustrated conceptually in Figure 1 and Figure 2. In Figure 1, we show an example of a road section with lanes only in an increasing direction, and with a single 500 m long line marking segment.


Also shown (as coloured dots) are the individual, available reflectivity measurements, which are generally taken at 1 m intervals. The colour of these dots denotes the relative reflectivity value, with red indicating sub-standard, blue medium and green acceptable reflectivity. The gaps in the available reflectivity data reflect the true state of affairs since it was observed that reflectivity measurements often contained segments in which no data was available along a specific line.




Figure 1: Conceptual outline of line marking model – segment layout and data positioning

The JunoViewer line marking model will automatically extract the latest available data at each measurement point (generally at 1 m spacings). A time limit (in years) can be set to limit how far the model needs to go back in time to retrieve the latest reflectivity data.

Figure 2 shows an illustrative example in which three treatments from the road works FWP have been merged with the 500 m line marking segment. Conceptually, every reflectivity point that is covered or touched by these treatments will be reset by the treatment (assuming that part of the treatment will be a full re-establishment of line marking using new materials).


Figure 2: Conceptual outline of line marking model – merging road works FWP treatments

Thus, at the end of the 2020 modelling year, all of the points touched or covered by the SMA treatment that will be placed in 2020 will be reset to a value that is specified in the model. Similarly, points touched or covered by the SMA in 2023 or by the OGPA in 2022 will be reset in those years.


At the end of each year, the model scans the reflectivity points, including any points that were reset by treatments in the merged FWP. An increment is then applied to step forward each reflectivity point to the next year. This process is repeated for each line marking segment and each modelling year.


Given the large number of raw reflectivity points in each segment, the model calculates – for each line marking segment - a single, specified percentile value to represent the line marking segment reflectivity in that year. This percentile would be a lower percentile (e.g., 20th percentile) and the value would represent the predicted future condition for that line marking segment.


Proceeding in this manner, the model can merge the planned treatments in a specified road works FWP with the current reflectivity condition. Any reflectivity points that are affected by planned treatments are reset to specified values, while any points that are not affected by planned treatments are deteriorated using a fixed, line-specific deterioration value.


1.2. Model Setup Steps

The Line Marking model requires the following preparation and inputs[1]

1. Prepared 500m segment set covering both directions of all sections in the network:


This segment set needs to be manually prepared. JunoViewer’s segment set creation tool can be used to create and export a set of 500 m segments (other lengths can also be used, e.g., 300 m). However, for sections that are not direction specific, duplicate segments need to be created for the opposing direction, and this need to be done manually using Excel. The prepared segment set then needs to be imported into JunoViewer as the base FWP for line marking.

Segments in the FWP that are in the decreasing reference marker location (i.e., direction “Decreasing”) needs to be assigned the lane code “R1+R2+R3+R4+R5”. Conversely, segments in the increasing direction need to be assigned lane code “L1+L2+L3+L4+L5” (note: no space between plus signs). Once the segment set is prepared in Excel, it can be uploaded to JunoViewer, imported as a FWP and assigned a version code.

[1] Given that this is a first version of the Line Marking model, and also the agile nature of JunoViewer tool development, the steps and details noted below may be modified in future versions of the model.


2. Preparing the Deterioration Model Setup (DMS) file:

A special DMS file has been prepared for the line marking model. Click here to download an example of the Line Marking DMS. You will note that in this DMS, the Treatment Assignment Model parameter on the General sheet is set to “linemarking_model”. This is needed to ensure that the special line marking model is run instead of an alternative model.

This DMS can be used as a basis for the line marking model and requires minimal modification. To keep the model simple and easy to use, the model does not at present, allow a significant degree of customization. Table 1 shows the model parameters that can be customized in the DMS.




3. Linking the Line Marking FWP and the DMS

The step is the normal procedure for defining a model setup. In the Forecast Models page, select the line marking FWP defined in step 1. Select to add a new model setup, and link the DMS prepared in step 2. Do not specify a budget or committed treatments since the Road Works FWP specified in the DMS will automatically be applied by the model as committed treatments.

Note that the line marking model does not trigger any new treatments. At this stage, the model simply applies the Road Works FWP treatments and uses this to reset the reflectivity points as explained in the preceding section.

4. Run the Model and Export Full Model Report

With the DMS linked to the line marking FWP, you can run the model. For a medium sized network with 500m segments, a model run typically takes only a few minutes to complete. Once the model is completed, you need to export the Full Model Report.
Given the specialized nature of the model, many of the elements of the full model report (e.g., annual spending, treatment quantities summaries etc.) will not apply and will essentially be empty.

The outputs to be extracted from the Full Model Report can be found on the sheets named “bl”, “el”, “ll1”, “ll2” etc. These sheets contain the specified percentile of the reflectivity on each 500 m segment. Data on these sheets can be analysed to obtain estimated future reflectivity condition for the network. The remainder of the Full Model Report should be ignored since these outputs do not apply to the Line Marking model.




In addition to the “Full Model Report”, a special Line Marking output report will be generated automatically as part of the Deterioration Model Run. This report is in Excel format and contains Reflectivity data for each line code (i.e. model parameter). You can access this report from the My Long Running Processes page, by opening the Log for your model run and clicking on the Download button after you have selected the log item showing the LineMarking Report output.


1.3. Model Requirements



The JunoViewer Line Marking model is easy to implement. However, since the model executes a predetermined workflow, there are several underlying assumptions with respect to data structure and model parameters that need to be adhered to, otherwise errors will occur. Specifically, the following data and DMS structure needs to be in place before you run the model:

Line Marking Table:
The model assumes there is a table named “linemarking” in your JunoViewer database, with the columns as shown in Table 2. Note that the reflectivity for different lines is stored in columns “bl_val”, “el_val”, etc., mapping to line codes “bl”, “e”, etc., respectively.



Table 2. Note that the reflectivity for different lines is stored in columns “bl_val”, “el_val”, etc., mapping to line codes “bl”, “e”, etc., respectively.


Number of Lanes from Carriageway Table:

If your model extracts the number of lanes from the Carriageway table (option specified in DMS), then you should have a “carriageway” table defined in your JunoViewer database. This is a standard JunoViewer table for New Zealand networks. Please contact Lonrix if you need assistance in setting up this table.

Number of Lanes from Info Column:

If your model extracts the number of lanes from an info column in the road works FWP, then you should ensure that the specified column name exists in the specified road works FWP. If the specified info column does not exist in the road works FWP, an error will be reported by the model.

Model Parameters:

Apart from the normal mandatory model parameters that describe quantity (parameters: “length”; “areaM2” and “shoulderAreaM2”) the line marking model only allows parameters with name codes that map directly to columns in the line marking table. The following model parameter codes are allowed:
  • Parameter code “bl” mapping to reflectivity column “bl_val” (see Table 2)
  • Parameter code “el” mapping to reflectivity column “el_val”
  • Parameter codes “ll1”, “ll2”,…,”ll5” mapping to reflectivity columns “ll1_val”, “ll2_val” etc. (see Table 2)

Your DMS does not have to contain parameters to match all of the reflectivity columns (e.g., you can have only parameters “bl”, “ll1” and “el”), but you cannot have any additional parameters (e.g., surface age) in your line marking model. This requirement follows from the specialized looping algorithm that uses raw reflectivity values which does not apply to typical modelling parameters.


edited by dani_merc on 5/5/2021


edited by dani_merc on 5/5/2021
0 link