Analytics

INTRODUCTION OF LINEAR REFERENCING SYSTEM (LRS)

The LRS integrates disparate roadway data using the data's linear locations as a common link. A linear location is described in terms of a linear referencing method (LRM). Therefore, in order to achieve full data integration and accessibility, the system must have functions available that can dynamically transform a location described in terms of one LRM into another LRM. For example, an event described in reference to a milepoint may be easily transformed to an improvement project station reference.

LRS components

The LRS is designed as a three-tier distributed system composed of clients, business logic, and data stores, all of which are logically connected via a network. The business logic contains services and facilities that implement the linear transform, linear overlay, and data staging operations that are part of the LRS application.

The LRS may become the focus of several client systems that require the transformation, overlay, and staging services of the LRS. These systems can be developed to interoperate with the LRS business logic tier through the network. External applications interoperate by passing LRM data over the network. The LRS application programming interface (API) described in this document is an interoperable component that runs against the business logic.

Client applications

The client applications tier is composed of GeoMedia® clients and other applications that can communicate with the business and database tiers. Examples of non-GeoMedia clients that can access the other layers are Oracle® Forms, SQL*Plus and other command-line interfaces, and interoperable systems that are specifically designed to access the LRS functionality across the network.

Business logic

The business logic tier is composed of a set of Java classes and stored procedures that implement major functions of the LRS. These procedures include the code that performs linear transformations, linear overlay, and staging functions.

Database

The database tier consists of two Oracle schemas. One schema contains the geodata library (GDL), while the other schema contains the LRS. The GDL schema and the LRS schema are logically separated, and can be physically separated into different database instances if required.

LRS subsystems

The LRS has several subsystems, each providing some element of linear location reference required by the Iowa DOT. Each subsystem can be independently managed and maintained as a set of asynchronous processes. The datum and route subsystems are the essential, underlying linear location control for the Iowa DOT.

• Datum — provides the most stable description of a linear location over time, and provides the most commonly simple location form to which all LRM location forms can transform. The key components of datum include anchor sections and anchor points. The anchor section is the primary object that all other subsystems will reference, either directly or indirectly, via the route management system. Anchor points define the ends of anchor sections.
• Route — provides the underlying network and posted routes to which most LRMs are dependent. Transport nodes and links capture the Iowa DOT navigable network. Transport nodes exist at standard vehicular turning points; transport links indicate basic traffic flow (i.e., one way or bidirectional travel).
• LRS milepoint — provides a continuous location reference. An LRS milepoint is the accumulated distance, in miles, from the beginning to the end of a route within a specified transportation system. Typically, the measurement begins at the first road intersection prior to a state, county or municipal line. As a result, the same route can have different milepoint values based on the extent of the transportation system.
• Reference post — provides localized, but consistently placed points of reference from which to measure a linear location. The reference post LRM uses the mileposts along the primary routes. Note that the LRS does not allow using the post values as a representation of accumulated distance; this subsystem applies the posts and relative offsets to locate events. For example, the accumulated distance of 10.06 is not the same location as reference post 10, offset 6 miles.
• Project station — provides location reference regarding to roadway engineering stationing. The stationing LRM is composed of project sections. Project sections are defined by the beginning and ending of an improvement project. Each project section has a beginning station value and an ending station value. These values are used to interpolate positions of station posts or events along the project section. The smaller the project section, the more accurate the position of a station post or event. Each new road improvement project, even if in the same location, has a new set of project sections and beginning/ending station values.
• Coordinate route — provides the ability to use coordinate route data and transform it to a linear location. This is done by snapping the x,y location to the cartography, and using the cartography datum relationship to assign it a true linear location.
• Segmental — defines the roadway as a set of predefined control segments to which events are indexed; highway performance monitoring system (HPMS) and a generic segmental system are supported.
• Literal — provides a consistent method for literal description location use. A literal description is an observational account of a location using existing route names or roadway features. Roadway intersections are the most common reference feature, but others have substantial potential, as almost any physical roadway feature or landmark may be used as long as it is under the Iowa DOT's jurisdiction. For example, a pavement section location may be described as "on Iowa 45 at Maple Avenue, plus 100 meters towards the Skunk River Bridge, for 1200 meters."

Changes generated in one of the subsystems can affect other subsystems. These affects are managed as events that can be trapped and used by other subsystems. As these subsystems exist within the LRS schema, database triggers and referential integrity constraints can be used to provide the firing mechanisms for triggers.

System interface

The LRS application programming interface (API) provides the functional interfaces needed to integrate linear data with different LRMs. The API enables data staging, and provides the underlying information and control necessary for transformation and overlay operations to be performed on different LRMs. The API provides the following functions.

• Utility functions provide the means for controlling linear operations (transformation and overlay), as well as general system settings.
• Linear location transformation provides functions to transform one linear reference event to another - specifically, one with a different LRM.
• Linear overlay provides functions for linear overlay operations (i.e., determining the portion of an event that is either in common or different from another event). Three types of linear overlay operations are supported: difference, intersection, and union.
• Linear data staging provides the means by which existing LRS, legacy system and center-line data may be integrated with the LRS. Additionally, the LRS API provides functional interfaces to manage system and user preferences and to obtain system information.