Data in the ALRS
The advanced linear referencing system (ALRS) is constructed by combining a centerline feature class, a route table, a cross-reference table, and calibration points to generate route layers called LRS Networks. In order to create an ALRS, your database must meet these minimum schema requirements.
By default, the ALRS looks for feature classes and tables with a specific set of names:
- Centerline—The polyline feature class that holds the route geometry
- Route—The table that holds the route definitions
- CenterlineSequence—The cross-reference table that manages the relationship between Centerline and Route
- CalibrationPoint—The point feature class that holds the route measure values
- Redline—The line feature class that stores markup features for communicating new highway alignments
It is not required that you name your feature classes and tables exactly as described here, but by using the standard naming convention, you can reduce the amount of configuration required to create an ALRS.
Centerline feature class
The Centerline feature class provides a single source of geometry for all LRS Networks that you build within an ALRS. Every feature within the Centerline feature class represents the single, fine-grained unit of the highway. These can be used to represent a one-to-one relationship with control sections or be aggregated to form larger routes based on user-specified route definition.
The table below shows the fields required in the Centerline feature class. If you name your fields as described below, the Advanced Linear Reference System setup wizard will recognize the names and configure the ALRS accordingly; otherwise, you will be given an opportunity to map to fields having different names to serve the same purpose.
Field Name | Mapped To | Description |
|---|---|---|
RoadwayId | RoadwayId | Unique ID for the centerline geometry. This can be either integer or string. |
FromDate | FromDate | The date the centerline feature was operational. |
ToDate | ToDate | The date the centerline feature was retired. |
The RoadwayId field is initially mapped to a unique identifier in your centerline feature class. This could be any text or integer field that uniquely identifies your features, including ObjectID. When you run the Advanced Linear Reference System setup wizard, a new field is created called RoadwayIdGuid. This is a global unique identifier that the ALRS will use to manage your centerlines from this point on.
Route table
The route definition table helps define what a route is and how it is segmented according to an agency's business rules. A route can represent a local road, state road, highway, or any other polyline feature that has a unique identifier and a system of measures. Routes are built in the ALRS by merging Centerline features based on a common route identifier. The route identifier can be comprised of one or more fields stored in the route table. In order to correctly identify routes for each linear referencing method (LRM), you must have at least one record in the route table for each uniquely identified route. It's okay to have multiple records in your route table that identify a route, but only the first instance of the unique identifier field or combination of fields will be used to construct the route. Some examples of valid route identifier field combinations are listed below:
- RouteID—123456
- RouteName—US64
- RouteType, HwyNum, TravelDir—US_64_WB
- RouteName, TravelDir—US64_WB
The route table must have, at a minimum, a FromDate, a ToDate, and one or more fields to uniquely identify a route. You can also create additional fields to help amplify the route information. If the fields used to create the route ID are not unique in the route table, only the first instance encountered by the ALRS is used when rendering routes.
Centerline sequence table
The centerline sequence table acts as a cross-reference table to define the many-to-many relationship between centerlines and routes. One centerline feature can participate in many routes, and a route is typically made up of more than one centerline. The centerline sequence table also contains a network ID to indicate in which LRS Network each route participates. The use of the network ID helps differentiate between LRMs because route IDs may not be unique across networks. Your centerline sequence table must have one record for each centerline-route-network combination. The minimum fields required for centerline sequence are as follows:
Field Name | Mapped To | Description |
|---|---|---|
RouteId | RouteID | Unique ID for the route. This can be one or more fields. |
RoadwayId | RoadwayIdGuid | Unique ID for the centerline. Will default to RoadwayIdGuid once ALRS is created. |
NetworkId | NetworkId | Unique ID for the ALRS network in which each route participates. |
Calibration point feature class
Route measures are assigned to routes using the calibration point feature class. Routes are calibrated by calculating an interpolated distance between any two calibration points along a route. Calibration points are specific to an LRS Network and make up the measure component of the LRM. You should follow these rules for calibration point placement to get the best possible calibration of your routes:
- You must have one set of calibration points for each LRS Network in your ALRS.
- You must have a minimum of two calibration points per contiguous route section, ideally at the ends of each contiguous section.
- Calibration points should be monotonic, meaning strictly increasing or strictly decreasing. Nonmonotonic routes will calibrate, but event locations will be difficult to manage, and event behavior may be unpredictable.
- Additional calibration points can help calibrate loops and roundabouts.
- Add a calibration point if you want to lock down a particular location with a specific measure value.
Field Name | Mapped To | Description |
|---|---|---|
Measure | Measure | Measure value to be stored on routes in an LRS Network |
FromDate | FromDate | Date the calibration point becomes active |
ToDate | ToDate | Date the calibration point is retired |
RouteId | RouteId | Unique identifier of the route |
NetworkId | NetworkId | Unique identifier of the LRS Network |
Geoprocessing tools are provided to help generate calibration points, update calibration points, and detect non-monotonic calibration on your routes. See Accessing the Roads and Highwaysgeoprocessing tools to learn how to access the Esri Roads and Highways geoprocessing tools.
Redline feature class
The redline feature class contains the basic information required to perform many of the route editing functions available in Roads and Highways. The redline feature can be thought of as a placeholder for a future route editing operation. It is used as a markup feature so that LRS users don't have to be LRS maintainers. It can be very disruptive to a user's workflow to discover differences between the LRS and the real world. Instead of stopping work to wait for the LRS to be updated, you can enter a redline feature into the geodatabase to indicate where the route should be, notify the GIS team, and continue working with your asset data.
Redline features can be entered as accurately or as generally as you like. It is expected that a GIS analyst will verify the redline feature and ensure that accurate geometry is entered into the database. A roughly sketched redline indicates that a change to the LRS is required and provides a general location, but it will be up to the GIS analyst to research the requested change and add the data into the GIS correctly.
Note:Redlines do not need to be M- or Z- enabled to work with Roads and Highways.
The following are the minimum required attributes for the redline feature class:
Field Name | Mapped To | Description |
|---|---|---|
FromMeasure | FromMeasure | Starting measure of the alignment change. |
ToMeasure | ToMeasure | Ending measure of the alignment change. |
RouteId | RouteId | Unique identifier for the target route. |
RouteName | RouteName | Optional name for the route. |
EffectiveDate | EffectiveDate | Date the route change becomes effective. This date will be applied to events affected by the change. |
ActivityType | ActivityType | Type of change being made, for example, Realign Route, Extend Route, and so on. |