The primary purpose of setting up the LRS in AgileAssets Asset Management System is to be able to locate the various transportation events on the linear network. For example, maintenance work performed by maintenance / bridge crews on sections / bridges in the route network can be located on the LRS. Crashes that occurred on various routes, at various points can be located on the LRS. This section describes how events are located on the LRS in the Agile System.
After the network is defined the locations within the system are linearly referenced and store in a table named SETUP_LOC_IDENT. This following sections address this table in greater detail:

Basic Event Location Attributes

Event located event within the system is located by specifying the following set of information (they match the LRS fields described in Chapter 8.1):

• ROUTE_ID – a unique route identifier related by key to the route name in SETUP_NETWORK_LINES
• LANE_DIR – a value that indicates the directionality of the event, it may have on of 3 values 0,1 or 2. Normally these values translate to 0=All directions/Both Directions, 1- North or East or Increasing milepoint direction, 2 –South or West or decreasing milepoint direction.
• LANE_ID – a unique lane number numbered according to convention, for most clients the lanes are numbered beginning at 1 for the outside lane and increasing towards the median on both sides. Other options are available.
• OFFSET_FROM – Event begin measure
• OFFSET_TO – Event end measure

LOC_IDENT Column

"LOC_IDENT" is a field used by the system to uniquely identify all events on the LRS. The location data (on both Base LRM and Alt. LRM) for each LOC_IDENT is stored in a table called SETUP_LOC_IDENT. This table records only the location information and the name of the table that contains the attributes regarding this location. The attributes of the location for each LOC_IDENT is then stored in the corresponding table, with the same LOC_IDENT value.
The value for LOC_IDENT is generated by a sequence for every event that is recorded by the system. An event can be described the identification of a location on the LRS for a particular table where the particular table stores all the attribute information regarding that location. For example, when new sections are created, LOC_IDENT values are generated for each section as each section is a separate event on the LRS. Another example is when condition (performance measure) data is collected for a specific site, another LOC_IDENT value is generated (when saving this information into the system) even if the locations is exactly the same as location of a section. The reason is the corresponding attributes are different and stored in different tables and therefore they comprise separate events on the LRS.

SETUP_LOC_IDENT Table

The table SETUP_LOC_IDENT has a set of columns for each LRM. Only the columns for the basic LRM (default Agile LRM) will be mentioned in this document. The SETUP_LOC_IDENT has the following columns for the basic LRM. The following table also shows a sample of the data stored in the table.

Column for Base LRM

Example Data from SETUP_LOC_IDENT Table

The SETUP_LOC_IDENT table contains a record of all the location referenced events within the system. Each event is referenced by a unique identifier LOC_IDENT that also serves at the primary key for the table. It is important to note that this table stores the location information for each event only. The attribute data for the event is always stored in another table that references the event LOC_IDENT. To facilitate the location of the associated event table the column SOURSE_TABLE is used to identify the attribute table name.
In all the other tables the actual linear reference of a given event is stored in this table. The related key is always the LOC_IDENT column.
When a system is configured with multiple LRMs, each LRM's column are added to the SETUP_LOC_IDENT table. Below is an example of the table configuration with a Base LRM and County-based Alt. LRM.

SETUP_LOC_IDENT Structure (Example with a county-based LRM)

Note: In many county-based LRMs, County name is a part of overall route identifier, if a location event crossed county boundary, its beginning route name (COUNTY_ROUTE_FROM) can be different with its end route name (COUNTY_ROUTE_TO). On the other hand, for events that do not span county boundaries, COUNTY_ROUTE_FROM will be the same as COUNTY_ROUTE_TO.

LOC_REF_xxx Records in SETUP_LOC_IDENT

A special set of records in SETUP_LOC_IDENT (where SOURSE_TABLE='LOC_REF_xxx', and xxx is the LOC_REF_ID from SETUP_LOC_REF described in Section 8.1), is what the system uses to map between the Base LRM and Alt LRM. In the following example from Section 8.2.2:

• If you enter an event in Alt LRM, using County BALLADONIA, Route H001A, 1 to 3, the system translates it to Base LRM using linear interpolation: Route H001A from 2 to 4, and then store both sets of measures in the corresponding SETUP_LOC_IDENT record.
• If you enter an event in Base LRM, using Route 001A, 7 to 9, the system translates it to Alt. LRM using linear interpolation: County CANNING, Route H001A, 2 to 4, and then store both sets of measures in the corresponding SETUP_LOC_IDENT record.

Example Alternate LRM Mapping Screen

SETUP_LOC_IDENT Table Data with a County-based LRM Example

Event Geometry

In the system, for any table that has a LOC_IDENT column (i.e., the location data in the table is based on the LRS), a "GEOM" database column (data type Geometry) can be optionally added to the table to store the spatial geometry of the data. Whenever a linear location is updated, the corresponding GEOM column is also updated with a spatial geometry to match the linear location, using dynamic segmentation against SETUP_NETWORK_LINES.