ALRS data model

The advanced linear referencing system (ALRS) supports the use of a single polyline feature class, known as centerlines, to store the geometry for multiple road and highway definitions, known as routes. The route definitions are stored in a route table, which has a many-to-many relationship to centerlines. This means that routes are typically made up of multiple centerline features, and centerline features can participate in multiple routes. The many-to-many relationship between routes and centerlines is maintained through a cross-reference table known as the centerline sequence table. The centerline sequence table contains a reference to each centerline, indicating which routes a given centerline participates in. Because route IDs are not unique in the ALRS, the centerline sequence table also contains a reference to the LRS Network, named NetworkId. The combination of NetworkId and RouteId creates a way of uniquely identifying each route in the ALRS.

In addition to geometry, routes must also have measures. Measures on routes are what the ALRS uses to display event layers in their correct locations on a map. Measures are added to routes through a process known as calibration. To explicitly control how routes are calibrated, the ALRS uses a calibration point feature class. Calibration points are point features that store measure values, route references, and network IDs. The combination of these three items constitutes a linear referencing method (LRM). LRMs are created by applying calibration points to routes to create an LRS Network.

By default, the ALRS looks for feature classes and tables with a specific set of names:

• Centerline—The polyline feature class that stores the route geometry
• Route—The table that stores the route attributes
• CenterlineSequence—The cross-reference table that manages the relationship between centerline and route
• CalibrationPoint—The point feature class that stores the route measure values
• Redline—The polyline feature class that stores markup features for communicating LRS changes

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 during the ALRS creation process.

Note:

These feature classes and tables, with all necessary fields, can be generated automatically using the ALRS setup wizard.

Legacy:

The route table will be deprecated at the next release of Roads and Highways. Also, the RoadwayID field in the centerline feature class and centerline sequence table will be deprecated; the RoadwayIDGUID field in the centerline feature class and centerline sequence table will change to CenterlineID and will remain a GUID field type.

Centerline feature class

The centerline feature class provides a single source of geometry for all LRS Networks 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 routes or be aggregated to form larger routes.

Note:

The tolerance and resolution settings of the centerline feature class are propagated to the networks, intersections, and event feature classes registered with Roads and Highways. Once these are set, they cannot be changed. For more information about resolution, tolerance, and measure precision in the ALRS, see step 5 of Creating a new ALRS.

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	Data Type	Length	IsNullable	Description
RoadwayId	String	255	Yes	Unique ID for the centerline geometry. This will default to RoadwayIdGuid once the ALRS is created.
RoadwayIDGUID	GUID			Unique ID for the centerline geometry.
FromDate	Date	8	Yes	The date the centerline feature becomes operational.
ToDate	Date	8	Yes	The date the centerline feature is retired.

The RoadwayId field is initially mapped to a unique identifier in your centerline feature class. This could be any string 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 named RoadwayIDGUID. This is a global unique identifier that the ALRS will use to manage your centerlines from this point on.

The RoadwayId field is only used for initial data loading into the ALRS schema. It is the ID field you use to map your centerlines to your routes. If you plan to use the initial data loading tools, you will not need a RoadwayID field, since Esri Roads and Highways populates the RoadwayIdGuid field during ALRS creation.

The FromDate and ToDate fields on the centerline feature class are not used by Roads and Highways, but they can be used to specify time ranges on centerlines for the purpose of filtering centerlines by time on a map.

Note:

The centerline feature class should be z-enabled to work with the Roads and Highways data loading tools.

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 composed of one or more fields stored in the route table. To correctly identify routes for each LRM, you must have at least one record in the route table for each uniquely identified route. Some examples of valid route identifier field combinations are as follows:

• 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 string fields to uniquely identify a route. You can also create additional fields to help amplify the route information.

Note:

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 at least one record for each centerline-route-network combination. The minimum fields required for centerline sequence are as follows:

Field	Data Type	Length	IsNullable	Description
RouteId	String	255	Yes	Unique ID for the route.
RoadwayId	String	255	Yes	Unique ID for the centerline. Will default to RoadwayIdGuid once ALRS is created.
RoadwayIDGUID	GUID			Unique ID for the centerline geometry.
NetworkId	ShortInteger	5	Yes	Unique ID for the ALRS network in which each route participates.

If the ROADWAYIDGUID field is not mapped to during the creation of the ALRS, it will be added to the centerline sequence table and populated with correct values.

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 the 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.

The following are the minimum attribute requirements for calibration points:

Field	Data Type	Length	IsNullable	Description
Measure	Double	8	Yes	Measure value to be stored on routes in an LRS Network
FromDate	Date	8	Yes	Date the calibration point becomes active
ToDate	Date	8	Yes	Date the calibration point is retired
RouteId	String	255	Yes	Unique identifier of the route
NetworkId	ShortInteger	5	Yes	Unique identifier of the LRS Network

Geoprocessing tools are provided to help generate calibration points, update calibration points, and detect nonmonotonic calibration on your routes. See Generate Calibration Points, Update Calibration Points, and Detect Non-Monotonic Routes.

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 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 event data.

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	Data Type	Length	IsNullable	Description
FromMeasure	Double	8	Yes	Starting measure of the alignment change.
ToMeasure	Double	8	Yes	Ending measure of the alignment change.
RouteId	String	255	Yes	Unique identifier for the target route.
RouteName	String	12	Yes	Optional name for the route.
EffectiveDate	Date	8	Yes	Date the route change becomes effective. This date will be applied to events affected by the change.
ActivityType	ShortInteger	5	Yes	Type of change being made, for example, Realign Route, Extend Route, and so on.
NetworkId	ShortInteger	5	Yes	Unique identifier of the LRS Network.

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.