Wende A. O'Neill and Elizabeth A. Harper
Linear Location Translation within GIS
Abstract
Using a single linear location referencing method within transportation agencies is unrealistic and unacceptable. A GIS based solution provides the capability to translate spatial references within ARCVIEW 2.1 using Avenue scripts and a customized user interface. Location translation is supported among the following referencing methods, spatial coordinates, street address, route-reference post-offset, and route-milepoint. This paper discusses some of the issues that arise in the development of location translation systems. A description of the data model and database requirements of the system designed for UDOT is included. The context in which this location translation system was developed was to facilitate crash reporting in urban areas. However, UDOT has already begun to explore a variety of other transportation applications for which the location translation module will be used, including routing of field crews and support of customer complaint and response activities. Avenue scripts were written to translate linear references, customize data views and generate reports. The system is operating within ARCVIEW 2.1 on a digital database developed for Utah County.
Background
Linear location methods are used by transportation agencies to locate events, like crashes, and facilities, like bridges and culverts, along roads, railroads, transit routes and other transportation features. Linear location methods generally contain a name and a distance measure which indicates an offset from a known point. Some transportation agencies use a wide variety of linear location methods. The acceptance of GPS as a data collection technology and the desire to map transportation feature characteristics have increased the desire to include spatial coordinates as locational references.
To integrate databases and facilitate sharing of information, there is a need to translate among location referencing methods. Most GIS offer the ability to translate or project spatial coordinates into a variety of methods, such as state plane, UTM, longitude/latitude, etc.. Many GIS that have incorporated dynamic segmentation tools allow users to build routes referenced using a particular linear referencing method. However, no system allows translation among a variety of linear location referencing methods.
The purpose of this application was to demonstrate how multiple linear referencing methods can be incorporated into a GIS-T application, and, more specifically, how translation among multiple linear location methods and spatial coordinates takes place in a GIS environment. There are a wide variety of linear location referencing methods. This initial application focused on those identified by local agencies and state DOT personnel as being appropriate for automating a crash reporting system used by these agencies.
A description of the linear location methods used in this application is followed by a discussion of the database and algorithms generated to demonstrate location translation within GIS-T.
Linear Location Referencing Methods
Two focus group sessions were held with representatives from State Police, County Sheriff's Office, County Public Works Office, MPOs, and State DOT. One purpose of these sessions was to identify the primary location methods used to report crash locations in urban areas. In the state of Utah, the standard location referencing method is a route: reference post: offset identifier. State roads are posted with reference posts in rural areas. A route mile point method is not used because the reference posts have not been updated with changes to the road system. However, calibrated mile points for each existing reference post exist in the Highway Reference System. Reference posts are not used in urban areas to reduce sign clutter and maintenance costs. Consequently, when an incident is reported in an urban area, the location reference generally is not in the UDOT accepted standard address format and must be manually converted for input into the highway safety databases.
The location methods desired to automate this process include street address, route: reference post:offset, route:mile point, and spatial coordinates. Basically, an incident's location can be input using any one on these methods and output to all of these methods. An additional output method is called a grid address, which is needed for incidents that occur on local roads. Each of these methods is described below.
Street Address
Standard street address components are:
number, prefix, name, and suffix (some systems include a direction component too.)
e.g. "249 W. Jamestown Rd." is recognized as
number = 249
prefix = W.
name = Jamestown
suffix = Rd.
Typical geocoding algorithms parse a street address into several components then use these components to find matches or near matches in a database. The number is the key to locating a point or event along a street segment. Numbers are either associated with a specific parcel or, when used in a standard (i.e. TIGER) address matchable database, are found by interpolation between four elements constituting an address range; namely low address left, high address left, low address right, and high address right.
During the development stage of this application, a great deal of attention was paid to the use of street addresses to reference crash locations. Concerns arose on 1) the accuracy of this approach as a field collection method, 2) the data quality issues associated with building an address matchable database from scratch, and 3) the algorithmic error issues associated with geocoding street addresses to identify crash positions. Each of these topics is explored in more detail in a forthcoming paper in the Transportation Research Record.
Route: Reference Post: Offset
The Route: Reference Post: Offset (RPO) location referencing method commonly is used by state DOTs to keep track of all events (structures, accidents, traffic, inventory, etc.) in their engineering databases. An example of the standard address adopted by UDOT for an event that occurs along a highway segment is:
0089B 154+0.64 157+0.33
where:
0089 = route name
B = calibration direction indicator
154 = beginning reference post number
0.64 = offset in the primary direction from reference post 154
157 = ending reference post number
0.33 = offset in the primary direction from reference post 157
The standard address for point events, such as crash locations, contains only one reference post number and offset. Rules have been established by state DOTs for identifying the closest downstream reference post on divided and undivided highways. These rules are programmed into the scripts for translating other addresses into RPO. Basically, the direction of flow in the positive reference post incremental direction (primary direction) must be specified to correctly identify the side of the road on which an incident or event occurs.
When a user reports a RPO address, the translation algorithm verifies that this address conforms to the rules, and adjusts any address that does not. For example, if an officer drives some distance in the primary direction and reports the upstream reference post number and a negative offset, this is converted to the downstream reference post number (or lower reference post number) with positive offset for consistency.
In generating a RPO address, the algorithm also verifies that the event actually occurs on a state or federal aid eligible road. In the UDOT implementation, if the event is not on a road in these categories, then it is assigned to a reporting district (or grid address) for local use.
Route: Mile Point
Route mile point (RM) linear referencing is a slight variation of the RPO. The known point in a mile point system is the beginning of the route as opposed to a reference post placed along the route. Advantages and disadvantages of this approach to linear referencing are covered by Deighton and Blake. In the application developed for UDOT, all non-state, federal-aid eligible roads are reported using RM. It is important to identify the primary direction for these routes so an incident is placed on the correct side of the digital line.
Map Coordinates Issues
The standard GIS approach for identifying event locations is the use of map (or spatial) coordinates. This method provides the foundation for all of the linear referencing methods discussed above. In multiple referencing applications, it is also desirable to generate the spatial coordinates of an event from any of the location referencing methods mentioned here.
In the application described here, users have a tool for entering coordinates by pointing at the map and the translation algorithm includes rules for matching coordinates to a street centerline. The implementation rules include ways to resolve conflicts, such as when the coordinates lay an equal distance from two centerlines (such as at an intersection or in the median of a divided highway).
A major issue is how to generate an address when location is specified by map coordinates. Rules are established for which street name to use when converting to an address from another linear referencing method. For example, if a user points to a segment on 1200 South (SR 265) in Orem, which name should be reported in the address? Also, the question of directionality arises when a user points to a street centerline. Should the address be odd or even (i.e. left or right of the centerline)?
Grid Address
Grid addresses are used by local agencies to sort and query incidents on local streets that have been assigned to a grid location in the statewide database. Each locality creates a space filling grid which covers all the streets in the jurisdiction. The grid cells are not necessarily uniform in size or shape. Each grid cell is assigned an identification number. This number, along with a jurisdiction code, forms the grid address which is an output method for all roads.
Translation Options
To summarize, the application described here allows users to identify the location of a crash by entering an address based on three different linear referencing methods or pointing to a map base. The reported output address depends on the type of road on which the crash occurred. Local roads have the following valid input methods: street address and map coordinates. Output methods for local roads are street address, map coordinates, and grid address. Non-state FAE roads have the following valid input methods: street address, route: mile point, and map coordinates. Output methods for non-state FAE roads are street address, route: mile point, map coordinates, and grid address. State roads have the following valid input methods: street address, route: mile point, route: reference post: offset (standard or non-standard form), and map coordinates. Output methods for state roads are street address, route: mile point, route: reference post: offset (standard form), map coordinates, and grid address.
Databases
A single road centerline digital file is required as the foundation of this application. An address matchable database and a route system (RAT & SEC files) are constructed from the centerline representation. Several other polygon databases are optional. The application generates a point database that stores the multiple output addresses for each crash. Representations of spatial features in the centerline file and required fields in each database table are described below.
Route Theme
The route theme is built in ArcInfo. Line segments that make up this theme are roads that belong to the state route system or are federal aid eligible. Local roads are part of the master centerline file but are not built into a route system. A Route Attribute Table (RAT) associates the route name to an internal route identification number. All state routes use the standard route name format (e.g. NNNND = four digit number plus direction code). Federal aid eligible routes that are NOT state routes use the numeric code assigned by the DOT or MPO.
The Highway Reference System adopted by UDOT does not accommodate multiple routes over a single road section. Each road is designated with the primary route number. So, for instance, where SR 91 and SR 89 overlap, the standard addresses in the RPO format for this section refer to reference posts on 0091B only. When building the secondary route (e.g. SR 89), any arcs that belong to another route (e.g. SR 91) are not included in the route structure. So, Route 89 is represented by disjoint segments as opposed to a continuous, connected set of arcs. Including shared arcs in both route definitions creates extra records in the section table that never are used by the translation algorithms. Further, inclusion of these arcs as part of the secondary route increases processing time as well as database size.
Routes designated with N(egative) and P(ositive) directions are built twice in the route structure even if the same digital centerline is used. The from and to measures and reference post numbers along these routes are numerically different and in opposite directions.
A primary direction field is added to the RAT to verify user input on the lane group in which the event occurred and to identify the correct address range (odd or even).
A section table (SEC) is created by ARCINFO when a route system is built. This table follows the basic structure prescribed by Esri. The Utah Highway Reference System contains the calibrated mile point of every intersection along a route. These values are used to populate the from and to measures in the SEC.
Route Event Table
A route event table, in .dbf format, is created from the highway reference system to allow conversion between RPO and RM addresses. This table has three fields, a route identification number, reference post numbers, and accumulated mileage to each reference post. The route event table contains point references for each of the reference posts along a route. Since non-state federal aid eligible roads are measured in offset from the zero mile point, only state routes are included in the route event table. In the event that an address is entered either by map or by street address and the route is identified as a non-state federal aid eligible route, the SEC table is used to convert the address to mile point. If an address is entered either by map or by street address and the route is identified as a state route, the route event table is used with the SEC table to convert the address to RPO and RM.
Street Address Theme
The street address theme is associated with a single table. It contains default information, such as the shape, length and Roads ID# fields, as well as several fields that facilitate address geocoding. Address geocoding fields may be developed as a dBase or ASCII file, then joined to the attributes of theme. Four fields are used to identify the address ranges on either side of a road segment, namely leftadd1, leftadd2, rightadd1, and rightadd2. Prefix, Name and Suffix fields are used to identify the appropriate street segment, and the Jurisdiction field enhances address matching by helping to distinguish locations with the same street address. For instance 103 N Main St. occurs in Provo, Orem and other jurisdictions in Utah County. Most geocoding processes allow some amount of relaxation of spelling or Prefix and Suffix specifications. Also, several alias names may be established for particular roads to improve matching. However, neither the geocoding process nor the address conversion capabilities can identify incorrectly assigned address ranges.
Crashes Theme
The crashes theme contains points representing the location of the crash. A user ID is generated which indicates the user, date and time of data entry. This application was designed for remote use in local police agencies. Consequently, a database field indicates that a crash has been added and not yet transmitted to UDOT. When crashes are transmitted to UDOT this field is changed. These are the only data items about the crash which are presently entered. Reporting and display can be selective based on dates of entry and status of submittal to UDOT. An archive and purge option provides the ability to remove all the crashes from the theme and start fresh adding new crashes. Without archiving and purging all the previously entered crashes will remain in the coverage regardless of whether they have been transmitted.
Avenue Scripts
Several Avenue scripts were written to develop a complete application for translating locations for crash reporting. As shown in the main screen, new menu items were added for display options and transmitting data, as well as positioning the crash. Further, the application allows interactive or batch processing options. The discussion below focuses only on the scripts written for location translation. The philosophy in developing these scripts was to use as many existing scripts as possible. So, for example, Esri's "Reverse geocode" script was adapted for use within the translation algorithms. Also, all street address matching uses Esri's gecoding algorithms.
Following is a brief description of the linear location translation algorithms written for the application. A more detailed discussion on error and network representation issues may be found in a forthcoming paper by O'Neill and Harper in the Transportation Research Record. In each of these algorithms, arc topology and ratio mathematics are used to determine position along an arc within the appropriate address range. These algorithms DO NOT assume that the direction of the digital line (arc) is the same as the direction of the route or the direction of increasing addresses. These relationships are determined on the fly so that the correct mathematical equations are used to position the event in all systems.
Route: Reference Post: Offset
From the "Position Crash" menu item, users select "Route: Reference Post" which initiates the translation script. Input information includes the State Route Name which is selected from a pull-down list, a Reference Post Number which is selected from a pull-down list, Offset which is a negative or positive real number, and Lane group which is selected from a pull-down list. The pull-down lists are populated using the RAT and the route event (.dbf) table.
After the input information is validated, the route event table is used to determine mile point of reference post. This value is added to the offset to get the mile point of the crash. Based on the from/to measures in the SEC table, the next step is to identify the appropriate arc on the route. Next, the street address is calculated from the address range information in the AAT and knowledge of the lane group and primary direction of the route. Finally, Esri's geocode algorithm is used to place a point at the address location and thus return the map coordinates.
The data entry procedures keep users from attempting to give a route reference post address for a local road. However, if a non-state FAE route is chosen, the reference post defaults to zero. Finally, many state routes will not have street addresses, such as interstates, so no street address is generated if the address range fields in the AAT are blank.
Mile Point
When users select "Milepoint" from the "Position Crash" menu, they are prompted to provide the following input information: Route Name from a pull-down list, mile point (any positive real valued number), and lane group from a pull-down list. The route event table is searched to determine the reference post and offset for the given mile point if the route number is associated with a state route. The rest of the algorithm is identical to the RPO address. Based on the from/to measures in the SEC table, the next step is to identify the appropriate arc on the route. Next, the street address is calculated from the address range information in the AAT and knowledge of the lane group and primary direction of the route. Finally, Esri's geocode algorithm is used to place a point at the address location.
Street Address
Input information for street address basically mimics the data required by Esri'S geocode algorithm. Users must supply address number, prefix, street name, suffix, and possibly,
jurisdiction. If users identify the jurisdiction they are interested in when the application begins, there is no need to enter jurisdiction during the crash positioning activities. Map coordinates are determined from the geocode process and the appropriate arc is identified in the AAT. The procedure then determines route and mile point using the arc id and the from/to measures from RAT and SEC. Distance along the arc of the street address from the downstream node is calculated for the necessary interpolation between mile points. Finally, the route event table is used to determine reference post and offset of the estimated mile point.
Map Coordinates
Users can identify the location of a crash using the map display. A tool button is provided to position crash events by map. The scale change and pan tool buttons provided by Esri are left active to assist users in locating the street and block on the map display. Once the user clicks on a location on the map display, the map coordinates are obtained and Esri's reverse geocode script (somewhat modified) is used to generate the street address. If the chosen location is close to an intersection, the list of all blocks emanating from that intersection is provided so the user can select the appropriate block. Once the street address is generated, the alorgithms for the route: mile point and route: reference post: offset addresses are used as explained above.
Grid Address
The grid address is an output address only. It is generated for every input type address unless the crash location falls outside the urbanized areas. This algorithm uses the point in polygon tools (Select by Theme) provided by Esri. Basically, the algorithm tests each grid theme to determine if the selected crash falls completely within a grid polygon. The jurisdiction name and gird identification number are used to make up the grid address.
Summary
The prototype application which was developed using these algorithms has shown that multiple linear referencing can be accomplished using desktop GIS capabilities. The application is practical to implement and may be used to support additional analysis capabilities which rely on multiple location referencing and spatial analysis. Some examples of additional analyses include: field crew scheduling, customer complaint, and response, decision support systems, facility management and policy analysis.
The biggest constraint to implementation is the development of an accurate and complete database. Database issues are being addressed and should not present insurmountable problems for full implementation. Additional location referencing methods such as GPS and intersection offset are methods which will be explored and added to the application in the future. In addition, UDOT will pursue the possibility of providing electronic transfer of crash data entered through the system, directly to the safety management systems in Salt Lake City; further enhancing the functionality of the application.
Two additional functions have been added to the existing application. One of these is the ability to convert transit time points to all other linear location methods mentioned above. The second is an interactive routing function that allows users to enter the address of the origin and the destination using any location reference methods described here. The shortest path is determined between the origin and destination, however, no new nodes are created for addresses which fall within a road segment. This application does not use the Network Analyst package developed by Esri. A description or text directions (as well as visual display) of the optimal route is printed to the screen. This application will aid in moving GIS to the field, for instance, in dispatching maintenance or emergency response crews. A crew lunching at MacDonald's in the 200 block of Main Street will have the best path to 0089B 345+1.21 (an RPO address) at their fingertips. Both of these enhancements are in the testing phase.
Acknowledgment
The authors would like to thank Mr. David Blake, Roadway Management Engineer, Utah Department of Transportation, for his continued support and enthusiasm for this project.
References
"Improvements to Utah's Location Referencing System to Allow Data Integration", Deighton, Richard A.; Blake, David G, Deighton Associates, Ltd., Canada.
"Integrating Roadway Data into a Corporate Database", Deighton, R.A.; Lea, N., Richard Deighton Associates, Whitby, Ontario
Wende A. O'Neill
Associate Professor
Department of Civil and Environmental Engineering
Utah State University
Logan, UT 84322-4110
Telephone (801) 797-2616
FAX (801) 797-1185
EMAIL oneill@lab.cee.usu.edu
Elizabeth A. Harper
Manager of Data Resources
Massachusetts State Highway Department
10 Park Plaza, Rm 4150
Boston, MA 02116
Telephone (617) 973-8244
FAX (617) 973-8035
EMAIL eaharper@msn.com