Linear Reference System Rookies

take on

Highway Inventory

by

Paul Burke

Richard Mader

Abstract

In theory, street attributes such as number of lanes and speed limits should be easily represented as events on a system of routes in a linear reference system.  Such events could be easily understood by non‑technical users.  For example, a description such as "The speed limit on Main St. is 35 mph between Adams and Washington Streets", would be one record in an event table. With this advantage in mind, we set out to implement an event based highway inventory.

Introduction

The Southern California Association of Governments (SCAG) is the Metropolitan Planning Organization for six counties in Southern California.  (See Figure 1.)  Arguably, the most significant project of SCAG is its triennial Regional Transportation Plan (RTP).  Central to this plan is the performance of the infamous freeways and boulevards of Southern California.  Planners at SCAG are ever vigilant of changes to the highway system and their effects on the region’s mobility and air quality.

Two years ago, the Modeling/GIS section began an inventory of major streets within the six counties comprising the  SCAG region.  The inventory contains information pertaining to existing levels-of-service as well as planned highway improvements.   Its primary purpose is to define the highway network for the RTP transportation demand model, but it will also support other programs such as the Highway Performance Monitoring System.

This past year, GIS staff began a conversion of the inventory from Arc/Info INFO tables to linear events.  As of June, 2001, that conversion is not yet complete.  However, we have already gained experience that should help us in subsequent encounters with linear reference systems.  This paper summarizes SCAG’s that experience.  More specifically it attempts to answer the following questions:

1.      What was wrong with the existing Highway Inventory?

2.      Corollary:  How did we hope to improve our system?

3.      Was there a divide between the ideal and practice of linear events?

4.      Have we crossed that divide?

5.      Where do we go from here?

We feel compelled for the sake of logical consistency to reveal that we answered “yes” to Question 3.   As rookies we have perhaps reached this conclusion later than many other transportation analysts, but we offer our findings in the hopes that they may help others who are considering linear events for their own applications.

What was wrong with the existing Highway Inventory?

The Highway Inventory is a database of arterials in the six county region comprising the SCAG.  It includes level-of-service attributes for over 7000 streets and highways.  It houses attributes such as posted speed, number of lanes and median type that are not provided in our base map.  The data was collected in most cases by field inspection for each inventoried street.

We originally opted for the most basic design for the inventory, namely, a one-to-one correspondence between level-of-service attributes and street centerline features.  This approach offers simplicity in database queries and mapping.  All that is needed is a common (key) field between the street centerline arcs and their respective record in the inventory table.

If the inventory were stable or small, then our initial design would have sufficed.  But the inventory is not stable; it requires updates to reflect street improvements as well as to correct for gaps and other errors in the database.  Street improvements include changes to existing conditions as well as near- and long-term projects included in the Regional Transportation Plan.  Most of the gaps and errors to the database stem from the manual process of  transcribing level-of-service information from paper or spreadsheet sources.  Manual selection of the arcs is prone to error since many arcs are too small to detect (less than 25 meters).   Figure 2 shows one such gap, which is only detectable at a scale considerably less than 1:30000 Figure 2.

Nor is the database small.  SCAG’s centerline basemaps (one for each county) includes all streets, major and minor in the SCAG region totaling close to 700,000 arcs.  The highway inventory is restricted to major streets, but they still amount to some 140,000 arc segments.  Most street attributes tend to be constant over a long range of ten to twenty blocks.  For instance, Hollywood Boulevard is composed of 91 arcs in the basemap.  Figure 3  In Phase I of the inventory, a posted speed of 35 was observed for the entire length of Hollywood Bl.  Each of the 91 arcs is attributed with the same posted speed.

The inventory also suffers design flaw with respect to metadata.  All of the original level-of-service data were originally collected from the same source at the same time.  The data was grouped in a single table to facilitate concurrent digitizing of all attributes.  Changes to the database, however, may effect only one attribute and may derive from different sources.  For example a county DOT  may report a street-widening from 2 to 4 lanes, while the a city planner may report a speed change for the same street segment effective one year later.  A separate (normalized) table for each level-of-service attribute would allow for each attribute to have its own source and data-of-modification.  Separate tables would correct the design flaw but would then require multiple edits even if attribute updates did occur concurrently. 

Corollary:  How did we hope to improve our system?

Since most street attributes tend to be constant over a long range of street segments, it is preferable to maintain the information across that range as a single data record.  A single data record containing the attribute and its metadata is far easier to maintain than the same information related to every arc within the range.  Consider the benefit when updating the attribute; only one edit operation is needed and only one record is retired to a historical archive.  Linear events offer this advantage.

Another appeal is the similarity between linear events and how we describe locations in the English (or presumably any other) language.  When we wish to convey to someone the speed limit along a segment of a street or highway, we mention the name of the street and refer to landmarks or other streets that fall along or cross the street in question.

We envision an enhancement to the inventory that could only be implemented using an LRS.  We plan to define carpool lanes along with the locations of carpool “slip” ramps.  These ramps usually occur midway between freeway on/off ramps so they cannot be represented using whole arcs.  Dynamic segmentation, a key feature of linear reference systems, allows for the creation of events at the ramp locations.  Without dynamic segmentation we would need to split arcs at the ramp location, and incur additional basemap overhead.

One final hope is to use the linear event system as a means of making the inventory available on more than one basemap.   SCAG relies on a commercial vendor, Thomas Brothers Maps, for its street centerline file.  In some instances, it is preferable to offer the inventory to users of Census TIGER files, or to county maintained centerline files.  Events that are defined using route names and cross streets would in theory be portable to linear reference systems built on other basemaps.

Was there a divide between the ideal and practice of linear events?

It is not completely accurate to portray the authors as “rookies” with regard to linear reference systems.  Both authors had prior experience with an Arc/Info route-system that represented the links in a transportation model on top of a detailed centerline basemap.  However, that route-system did not rely on events of any kind to represent model features.  It is only with our most recent experience with the highway inventory that leads us to conclude: the promise and practice are indeed separated by a considerable margin.

We have not encountered many urban myths concerning linear reference (LRS) systems.  We suspect that several myths may be quietly circulating and would like to address them before they reach wider distribution:

Myth: Events are easy to define:

They may be easy to define, but they can be difficult to geocode. To define an event using Arc/Info requires three values: a unique route id, a from- and to-measure.  Take for example an event defined by the following sentence: “There is a School Zone speed limit of 15 mph on Student Street between Chalk Way and Eraser Lane.”  Assuming you have defined you LRS on street names, you can fetch the route id by querying your LRS for “Student Street”.  Perhaps, you can even add separate queries for Chalk Way and Eraser Lane.  This allows you to visualize where the event should be placed.  To actually code the event, however, you cannot use the cross streets as starting and ending points for the event. You will need to somehow fetch the measures of Student Street at the intersection of the two cross streets. 

Myth: Events are easy to draw: 

In fact, events are encumbered by their route-systems. Route systems do not carry their own coordinates.  Therefore to display routes Arc/Info (and Arcview) must relate each route to its set of reference arcs.  For a route system of say 20,000 routes, tied to 100,000 arcs, this added query adds significant delay to screen refreshes.

Myth: Events are portable:

Events are only portable if you can transfer them to a site with a compatible LRS.  Event tables are very small.  Linear reference systems are likewise small, but they must reside on an Arc/Info coverage.  Basemap coverages can be very large, and unless you have the time to calibrate measures between two different basemap coverages, the only way to assure compatibility of LRS is to maintain identical copies of a single basemap.  LRS systems are not at all portable, even if moving to near identical basemap.

Have we crossed that divide?   (Are we able to make use of a LRS?)

We are happy to report that most of the problems we encountered initially have been resolved.  Our progress followed these milestones:

1.      Created route-systems (LRS) for each county basemap and exported the route-systems as measured shape files.

2.      Migrated the Phase I Highway Inventory to preliminary events.

3.      Created Cross street (point) events as an aid in referencing highway project (linear) events.

4.      Convert the preliminary events to attribute specific events.

5.      Geocoded first batch of Phase II inventory features as events.

A brief discussion of each of these milestones follows.

Milestone 1: Created Route-Systems

The SCAG LRS was developed almost entirely as an automated process.  This was done for two reasons.  The first was financial.  The cost of creating the system would be substantially reduced if a large amount of labor was not required.  The second reason was to maintain a high level of consistency in the reference system structure. We did not reference the entire street network.  We excluded local streets and alleys, and included streets classified as collectors and above.  Thomas Brothers, like most centerline providers, maintains a type category that was used  for the first selection filter.  SCAG had previously assigned its own highway classification for major streets and any street within this classification was also a candidate for the LRS.

Routes would be defined using separate criteria for freeways, freeway ramps and non-freeways.  The non-freeways were created using street names that were processed to drop the direction prefix.  For example, N. Main St. would have been simplified to Main St.  Any street names that was generated from the highway classification was applied to an entire county.  This process led to the inclusion of some local streets we didn’t need to reference.  For instance a major street named 2^nd Avenue in one city would trigger inclusion of all 2^nd Avenues, even from cities that classified it as a minor street.  The consequences of these extra local streets was minimal; some additional space was needed.  Not having a route is much more disruptive to the workflow as it must be interrupted to create the new route.  The route names for freeways were created using the freeway numbers.  Interstate 10, for example, became 10.  Fortunately in California numbers between federal highway routes and state highway routes do not overlap.  Ramps were all identified as ramp.

Once all the route names were created a unique number was assigned to each.  This number was used as the route index in the first iteration of Arcroute.  Arcroute creates separate routes for non-contiguous routes.  The system-created item “route#” replaced the original route index so as to uniquely identify each route.  This process also broke up all the ramps into individual routes.

The system worked quite well for the vast majority of the street network.  The contractor behind the effort (GIS/Trans) also developed a method to differentiate between the two different directions of the freeway.  This also was instrumental in creating a “clean” route system.

The most significant problem encountered were large interchanges between freeways.  These were manually checked because in a few cases the route defined would start up one side of the freeway, start crossing over the other side using a flyway, and then jump down to the freeway traveling in the opposite direction.  Although there are a large number of freeway interchanges in the SCAG region, checking these was a manageable effort.

As mentioned earlier, route-systems as themes in Arcview can be aggravatingly slow to refresh.  This problem is resolved by exporting the route-system as a “measured” shape file.  There is no direct means to accomplish this using Arcview or Arc/Info, however, Esri provides an easy-to-use macro,  route2polylinem.aml, for performing the operation.

Milestone 2: Migrated the Phase I Highway Inventory to preliminary Events

The original highway inventory was developed on a 1995 Thomas Brothers street centerline file, whereby inventory attributes were tied to arcs.  Fortunately we had upgraded the files from 1995 to 1999 with the assistance of an intern.  The 1999 street file and 2000 street file are almost the same.  Thomas Brothers maintains an id between data set years called grph.  The value of this field doesn’t change unless the configuration of the arc changes. 

The first step in the process was to join the data that did match to the 2000 arcs.  The section table was also joined to each arc.  The SCAG LRS was set up so there was only one section record per arc to avoid one to many situations for use in these types of data capture situations.

It was a relatively simple matter then to create a table with the from-measure, to-measure, route-id, and all the inventory data.  Dissolveevents was run against this to collapse adjacent sections with the same data values. 

The final task was to identify and correct for places where the 2000 data didn’t match the 1999 data.  A dialog was set up using ArcView 3.2 that would allow a user to capture the data elements from the 1999 file and put in the routes and measures from the 2000 file.

Milestone 3. Created Cross-Street Events

This task was simple in concept, though it required a rather complicated algorithm to implement.  Each route in the route system was traced and a point event was added for every cross street along the route.  Each table record include the route ID, the measure and the name of the cross street at the measure.  The table includes entries for both major and minor streets.  We opted to forgo the Arc/Info and Arcview environments and instead wrote the algorithm in Fortran and Unix C-Shell.

Milestone 4: Converted the preliminary Events to Attribute-specific Events.

This task resulted in separate tables for each attribute in the original inventory.  Table 1 shows those resulting tables and the type of items included in each table.  All attribute tables include two types of location data: measure (LRS) data to relate the event to the LRS, and address (Geocode) data that allows the event to be located in non-technical terms.  All attribute tables include their own metadata.

Milestone 5: Geocoded Phase II inventory features as events.

Our final achievement is an arcview interface for editing linear events.  It allows us to geocode events using cross streets instead of actual from- and to- measures.  The event editor utilizes the cross street events to realize this feature.  Figure 4 shows a screen shot of the editor form.

Figure 4

Table 2. summarizes our success to date in our linear event venture:

Where do we go from here?

As this paper has shown, we are at the very beginning of our history with linear events.  We have yet to complete our migration of Phase I inventory, and we have not even received all of the information for Phase II, let alone added it to our inventory.  That said, we have enough practical experience with route-systems and events to conclude that an event-based inventory is worth our commitment.  We have found the events easier to create and maintain.

Our list of issues in need of near term resolution includes:

1.      The migration of LRS from the 2000 to the 2001 basemap.

2.      Identifying routes created from unnamed street segments in the basemap.

3.      Adding existing streets to the subset of major streets comprising LRS.

4.      Adding planned streets that are not yet present in the basemap.

5.      Updating cross street event table as needed.

6.      Adding carpool lanes.

We should note that most of these issues do not arise from the use of linear reference system.  Migration to new base maps, for instance, would be just as necessary with our original inventory design.

Perhaps the most exciting challenge facing SCAG is this:  how to take advantage of our linear events?  How do we go beyond the LRS as a database management solution to realize new methods of data analysis?  The answer to these questions is the subject of another paper.

Thanks to Farid Azfar, Alexander Lew, Patricia Milos and Linda Serret for their help in almost all facets of the migration effort.

The SCAG centerline basemap is licensed from Thomas Brothers Maps Inc.

Author Information

Paul Burke, Senior Planner, Southern California Association of Governments, 818 W. 7^th Street, Los Angeles, CA, 213-236-1938, 213-236-1803,burke@scag.ca.gov

Richard Mader, Senior Planner, Southern California Association of Governments, 818 W. 7^th Street, Los Angeles, CA, 213-236-1837, 213-236-1803,mader@scag.ca.gov