USING THE GEORGIA DEPARTMENT OF TRANSPORTATION'S ROAD
CHARACTERISTICS DATABASE FOR INTERSECTION LEVEL CALIBRATION:
AN APPLICATION OF THE ArcInfo DYNAMIC SEGMENTATION MODEL

ABSTRACT

The Georgia Department of Transportation's (GADOT) Planning Data Services road characteristics database (RCFILE) and their digital road maps include enough information to implement a dynamic segmentation model. The RCFILE contains more than 20 events stored by milepoint along each route. Events such as surface types and bridges are stored in the RCFILE. The link between the RCFILE and the digital map base enables a direct placement of the RCFILE's events, with some restructuring, onto the digital road map. County road maps produced by the GADOT contain such information as surface type and bridge locations. By using the information in the RCFILE and the digital road map, a route system was built and calibrated to the intersection level. This paper covers the procedures used in creating the routes, placing calibration labels, calibrating the routes, and restructuring the RCFILE into more useable event tables. The problems that occurred will be discussed along with solutions.

INTRODUCTION

The overall project included both intersection level calibration and a cartographic product. Only the intersection level calibration is covered in this paper. See Esri Procedings 1996 Paper number 170 and Paper number 290 for more information.

The project goals were to provide the Georgia Department of Transportation (GADOT) with a route system per county for all of Georgia that would be coherent with the road characteristics data base. The road characteristics data base, or rcfile, has road characteristics such as surface type, bridge locations, signalization and number of lanes. These events are all recorded linearly by mile. It also shows the exact mile point (to nearest 0.01 mi) at each intersection. This information could be used to calibrate the route system at the intersection level.

The road arc coverages that were obtained from the GADOT came from a variety of different sources. Sources such as USGS Quadsheets, digital orthographic quarter quadrangles and ground surveys. The accuracy of the road measures in a coverage varies from county to county. By calibrating the road coverages to the RCFILE's intersection data, the accuracy of the road measures would be more consistant throughout the coverage. This would make the placement of the events from the RCFILE nearly exact.

The ArcInfo Dynamic Segmentation (Dy Seg) model provides some tools to aid in accomplishing this task. The model defines a route as a collection of sections linked to a set of arcs. A section shows direction, measure and location on the arc to which it is linked. The model contains functions to make routes, to give them directions and measures, and to utilize this information spatially. For example, routes are created with the function 'makeroute' and remeasured with 'remeasure', and 'eventarc' will create a coverage from an event table and a route system. The purpose of this paper is to discuss the procedures used in creating the route system, placing calibration labels, calibrating the routes, and restructuring the rcfile into more useable event tables. The problems that occurred will be covered along with the solutions.

BACKGROUND

THE ORIGINAL DATA:

Two main data objects were used in this project: The digital road coverage and the RCFILE. A brief discription of both are described below.

The original road coverages contained the arcs representing the roads. The arcs were tagged with the rclink number. Most of the routes were built. The calibration labels were in a separate coverage. The road coverage contained the following types of errors: unsnaped arcs, overlaps, gaps, double labels, arcs tagged with the incorrect rclink and some routes were built in the wrong direction.

The RCFILE contains at least two entries for each road in the state of Georgia, except a few privately owned roads. The items in the RCFILE that were used in this project are described in Table 1.

Table 1. Items used in the RCFILE.

There were inconsistancies in the RCFILE. For instance, one route's intersecting route might be listed in the wrong order. There may be two begins or ends for the same rclink in the description field. These are usually typing errors. Other contradictions are present but not mentioned. These errors were difficult to trackdown. It usually took a combination of examining the inventory sheets as well as the roads corresponding intersections. Sometimes a hand map had to be drawn.

ROAD UPDATES:

Roads were updated on using 1993 NAPP photography in the form of Digital Orthophoto Quadrangles, or 1:15840 scale hardcopy photo enlargements and the most current county inventory sheets. Each updated road was tagged with an rclink, a source, and the update item changed to new or modified.

A lookup table was created at this stage which consisted of the rclink, the milepoint and the description. This table is a ascii file that could be called up with vi. Vi is a great tool for searching for a specific route (rclink) because of speed and ease of the search. This file was kept open whenever the county was being worked on.

PROCEDURES

PRELIMINARY CLEANUP:

Building a route system requires the arc node structure to be clean or free from gaps, overlaps and splits. A 'clean' was run with 0.01 dangle length and fuzzy tolerances. Then to remove dangles and unintersected arc, a 'generalize' with a tolerance of 1 meter was run on all the arcs. Further, arcs with length < 8 meters were examined and deleted if they were not legitimate part of the roads. An AML (small_arcs) was created to zoom in on each selected arc and pause for the user to determine if it was good or not. If an arc was extended to another arc, the route was not extended and had to be remade or the section position was changed so the route moved to the end of the extended arc.

MAKING ROUTES:

The route system was named DOT and rclink was added to the route attribute table. The arc coverage already contained the rclink number and was used to help create the routes.

The process of making routes was divided into four basic procedures.

1) Simple routes
2) Looping routes
3) Combined routes
4) Split routes

Simple routes

Simple routes are routes that have one direction and all underlying arcs have the same rclink as the route. Road 523 on Figure 1 is a simple route. The route is made by pointing to an arc in the route. All arcs are selected with the same rclink. The beginning and ending point are placed on screen. Then makeroute was used to create the route using the first point as the start point. At any time in this project when 'makeroute' was run the length option was subsituted with 'length / 1609.344' to to convert meters to miles.

Figure 1. Example of simple route.

Looping route

Looping routes are routes that intersect themselves. In Figure 2, routes 619 and 654 are looping routes. Two procedures were used to create the route. One, the first arc in the route was selected and 'makeroute' run. Then each arc in succession was appended to the route and remeasured using route_himeas option. After all the arcs were appended the entire route was remeasured using the values from the RCFILE. Unfortunately this procedure would crash out because of too many equations. The model apparently can only record a limited amout of equations. This is where the second loop route procedure was used. The second procedure was to select all arcs in a path up to where it the route intersected itself. Make the route giving it a start point. Then appending the arcs for half of the loop if possible and remeasuring with the route_himeas option. The append was continued until the looping route was finished. Then the entire route was remeasured with the exact RCFILE's mile points obtaind from the lookup table. If only one arc was the intesected itself the sections were turned on and direction checked and if needed the section was flipped.

Figure 2. Example of looping route.

Combined routes

Combined routes are routes that were joined with another route for a specified distance. This means in the RCFILE there is no intersection information for the joined part of the route. It is denoted in the RCFILE's description field as COM. It also means that the common section of the route will contain arcs with different rclinks. These routes were built as separate routes with the same rclink. For example, in Figure 3, Route 3 begins at county line runs for 5 miles normally, then it runs common to Route 5 for 5 miles and exits the county. This route would be built as two separate routes with the same rclink. The first route would measure from 0 to 5 and the second route would measure from 5 to 10. Calibration labels were placed at the ends of the routes that ran common to Route 5. By building the route as multiple routes, the procedure ran faster and if part of the routes arcs were edited, only that portion of the route needed to be remade.

Figure 3. Example of a Combined route.

Split routes

Occasionally on divided roads the median will become large enough to be shown on a county map. Like the combined routes, these roads had multiple routes also. One route was built on a contiguous path of the road. Then individual routes were built on all split sections. Route 402 on Figure 4 is a split route.

Figure 4. Example of a Split route.

Route Making Notes

Each of the above procedures to make routes was automated as much as possible with menus and AMLs. The AMLs were optimized as much as possible to avoid changing features, becuse it was found that changing the edit feature was inefficient with respect to time. Another inefficient function was the 'makeroute' command. For example, A Fulton County (Atlanta area) change in edit feature and the 'makeroute' function each would take 3 minutes.

One other major problem encountered while making routes was the dot-id on the route was not always unique. If the road coverage was projected those routes would get associated with another route. One county lost as many as 200 routes. However, if the dot-id's in the route table were calculated to dot# before the project this would not happen.

Placing calibration labels

Three methods were developed to place labels. The calibration labels were linked to the routes by rclink and contained miles gathered from the RCFILE.

First

An AML program was made to place the calibration labels on an individual route. It gathers all the intersections, the corresponding milepoints, finds the coordinates to place the labels, then places the labels. For roads that intersected more than once, the program paused and asked the user to choose the correct node to place the label. One advantage of this program was that there was little chance of typing error. One problem with this program was that the node would sometimes not be highlighted. Technical support reported that this is a bug in the ArcInfo program. Because of this the program was used sparingly and another method was used. Another disadvantage was that the program would take a while to run. It would take between 20 seconds to 20 minutes to run depending on the size of the county and the number of intersections along the route.

Two

Another AML program was created to manually place the calibration labels. This program asked to select the intersections to place the labels, asked for the rclink, then asked for the milepoints. The program was fast for routes that had few intersections. However, the possibility of typing errors was increased and on longer routes selecting each intersection was more difficult.

Three (Fastest process for placing labels)

The calibration labels were placed using a combination of a 'c' program and two AMLs. The 'c' program read the intersections from the RCFILE and created two files, alllabels and multiint. Alllabels contained the rclink, mile point and coordinates for placing the labels. Multiint contained rclink the intrclink (rclink of the intersection) and a mile point. Multiint also contained dead-end label point information, rclink and mile. Two AMLs were created to read these files and place the calibration labels. The first AML (putlabel2) reads alllabels and places the labels automatically. The second (multiint) reads the multiint file and automatically places the dead ends if the corresponding route is built. Then for the multiple intersecting routes the multiint program zooms in on the smallest route and lets the user determine which node the label is placed on. This method was fast and no typing errors were possible. A disadvatage was that if the coverage was not consistant with the RCFILE a double label would be created on an end of the route. However, this later made it easier to find the problems in the road coverage and the RCFILE.

Double labels

One error that can cause calibration problems is labels that occur at the same location with the same rclink but different mile points. This error was called double labels. There were three reasons double labels. are caused by three reasons. One, a mile point on a label is not contained in the RCFILE. This type of label was deleted. Two, an intersecting route does not intersect the calibration label's route. This was fixed by examining the road coverage and the RCFILE's description field. The double label was moved if the errors could be corrected, or deleted, if the problem could not be corrected. Three, a route does not exist in the coverage but exists in the RCFILE. When encountering the first two problems the program putlabel2 places the labels at the end of the route. Two AML programs were written to rid the coverage of this problem. One program searches through the labels and makes a file of the coordinates of the double labels. The second program reads the file and uses a zoom pan to move to each label on screen. Any problem that could not be solved was recorded in a notes file created for each county.

Displaying and correcting route errors.

A function 'Sho_route_err' was written to show the route errors. Basically the back environment option of 'routemeasureerrors' was used. This displays the sections in the background in green. Overlapping measures in the sections show up as white. Gaps in the measures are represented by squares with an x through them. Looping routes will show a gap symbol most of the time. Most of these are solved by running a 'makeroute' procedure. If that does not solve the problem it is probably a digitizing error.

Calibration

This is a process which creates the calibration label coverage, runs the 'calibrateroutes' command and then displays the errors that occur. Errors that occur are points not falling on route, overlapping sections and section measures are reversed. The points problem is solved by snapping the labels or moving them to the correct intersection. Some times a dangle is the cause. Note however, more than one route with the same rclink gives point not on route errors. After snaping these with a small snapping distance these errors were ignored. Usually a 'makeroute' would solve the overlapping sections. If 'makeroute' does not solve this problem there is an overlaping arc to be removed. The final error reversed measure meant that the calibration labes are in reverse order or a double label is present. The cause is either a typing error in the RCFILE or a digitizing error. The solution is to move the labels and arcs to the correct position. This procedure was run three times to make sure all errors were corrected.

Remaining route errors

Same as Sho_route_err above. Except, the function calfix is run on routes that are remade. Calfix is a program that will remeasure the sections of an individual route using the calibration points. The only condition on this program is the sections have to have the increasing measures correspond with the record numbers. For example, imagine a route that has two sections that are traveling from point a to point b then to point c. If section 1 is from point b to point c, and section 2 is from point a to b the calfix program would not calibrate correctly. Section 1 must be from a to b and section 2 must be from b to c. The quickest way to fix this problem is to make the route then save. After the save the sections will be in perfect order.

Events

Two INFO programs were created to produce event tables from the RCFILE: one for bridges and one for surfaces. The bridge INFO program looks at the description in the RCFILE and finds all that contain BRS, UPR, BRR and similar types. The program then places the corresponding rclink, milepoint, type and predifined symbol into the bridge event table. The surface INFO program looks at the surface_u item and gathers the first and last occurences of the same surface type. Then records the rclink , the from and to mile, a predefined symbol and type in the event table. Then, using the event table and the route system through 'eventsource' both the surface coverage and bridge coverage were created.

Final check

The surfaceu coverage is placed on top of the road_edit coverage to find missing routes. The missing routes are either not made properly or their are inconsistencies with the RCFILE (event table) and the route coverage. In the later case the problem is that the event measures do not go as high as the route measures. The inconsistency is recorded in the notes file. And if the road does not have a route, the route is made.

CONCLUSIONS

The procedures listed above can produce a clean route system that has been calibrated to the intersection level. The routes systems measures are consistent with the RCFILE's. Any event listed in the RCFILE can now with few modifications produce a coverage or plot or be queried spatially. The route system produced should give the GADOT a versatile tool for displaying RCFILE information spatially.

The most significant problems encountered were caused by the coverage having digitizing errors and inconsistencies between the RCFILE and the coverage. These problems are found and corrected though a series of checks and rechecks.

There were two significant accomplishments during this project. One is the placement of calibration labels at every intersection in a semiautomatic fashion at the rate of at least 200 a day. With a little more time, the semiautomatic process can become automatic. The second accomplishment is that a program was developed that can calibrate a single route using the calibration label located on the routes.

REFERENCES

1. Systems Inventory Data Collection Coding and Procedures Manual, Georgia department of transportation planning data services bureau 1994 revised edition.
2. ArcInfo User's Guide, Dynamic Segmentation modeling linear features, Environmental Systems Reasearch Instutute, Inc., Copyright ©1991. Esri.

AUTHER INFORMATION

James W. Price
Carl Vinson Institute of Government
University of Georgia
201 N. Milledge Ave.
Athens, GA 30602-5482
Telephone: (706) 542-2736
Fax: (706) 542-9301
E-mail: james@bogey.lislab.uga.edu