GPS to LRM: Integration of Spatial Point Features with Linear Referencing Methods
|
|
Principal Investigator
Shauna L. Hallmark
Assistant Professor of Civil and Construction Engineering, Iowa State University
Funded jointly by
the Research and Sponsored Programs Administration,
U.S. Department of Transportation (Project MTC-A-4)
and the Iowa Department of Transportation (Project 00-68)
Preparation of this final report was financed in part through funds provided by
the Iowa Department of Transportation through its research management agreement with the Center for Transportation Research and Education.
Midwest Transportation Consortium
2901 South Loop Drive, Suite 3100
Ames, Iowa 50010-8632
Phone 515-279-8103
Fax 515-279-0467
www.ctre.iastate.edu/mtc/
October 2001
Table of Contents
1. INTRODUCTION
1.1. Background
1.2. Use of GPS for Collection of Transportation-Related Spatial Data
3. HANDLING OF POINT BUSINESS FEATURES WITHIN THE IOWA DOT’S LRS
3.1. LRS Datum
3.2. Point Data Accuracy Requirements
3.3. Integration of Point Data within the Iowa DOT’s LRS
3.4. Point Feature Integration Protocol
4. PILOT STUDY
4.1. Point Features
4.2. Spatial Representation of LRM
4.3. Datum
4.3.1. Anchor Points
4.3.2. Anchor Sections
4.4. Map Matching
4.4.1. Program Input
4.4.2. Program Logic
5.1. 2D or 3D GPS to 1D LRM
5.1.1. Loss of Spatial Information in Converting to 1D
5.1.2. Spatial Modeling
5.1.3. Recommendations
5.2. Point feature Data Collection
5.2.1. GPS Inaccuracies
5.2.2. Recommendations
5.3. Cartography and LRM Accuracy
5.3.1. Spatial Accuracy of the LRM
5.3.2. Linear Offset Error
5.3.3. Recommendations for Linear Offset Error
5.3.4. Lateral Offset Error
5.3.5. Recommendations for Addressing Horizontal Offset Error and Placement Errors
5.3.6. Matching to the Wrong Segment
5.3.7. Recommendations for Matching to the Wrong Segment
5.3.8. Currency
5.4. Data Transfer between LRMs
5.4.1. Data Transfer between LRMs Based on the Same Cartographic Reference
5.4.2. Unequal Segment Lengths for LRMs
5.4.3. Recommendations for Unequal Segment Lengths
5.5. Integration of GPS Route Data
5.5.1. Issues
5.5.2. Recommendations
6. SUMMARY
Appendix A: Map-Matching Program Code
Appendix C: Error in Lateral Offset for Test Segments
List of Figures
Figure 1. Iowa DOT LRS Pilot Study Area (GeoAnalytics et al., March 2001)
Figure 2. Pilot Study Areas in Ames, Iowa
Figure 3. Pilot Study Areas in Nevada, Iowa
Figure 4. Digitizing Point Features
Figure 5. Determining Edgelines
Figure 6. Centerline Determination
Figure 7. Calculation of Roadway Centerline
Figure 8. GPS vs. LRS
Figure 9. Inaccurate GPS Point Mapping to the Wrong Segment
Figure 10. Insufficient Polyline Resolution
Figure 11. Inaccurate Linear Offset Due to Insufficient Polyline Resolution
Figure 12. Distribution of Error
Figure 13. Cartography Alignment Error
Figure 14. Actual Centerline Versus Cartography Illustrating Insufficient Polyline Resolution
Figure 15. Points Mapped to Wrong Side of Segment (Cartography vs. Centerline)
Figure 16. Distribution of Error for Lateral Offset
Figure 17. Unequal Segment Lengths with Point Transferred as Distance between LRM
Figure 18. Point Feature Stored as Percentage Transferred between LRM
Figure 19. Point Mapping to Different Roadway Segments
Figure 20. Segmented GPS Route Information
Figure 21. Converting GPS Route Information to Point Data for Transfer to LRM
List of Tables
Table 1. Sample Output from Map-Matching Program in ArcView
Table 2. Matching Point Features to the Correct Street Segment with and without Route Identifiers.
Table 3. Distance along Segment where Street Light Was Located for Datum vs. LRM (N Avenue)
Table 4. Comparison of LRM vs. Datum Segment Length
Table 5. Adjusted Linear Offset for L Avenue
Table 6. Adjusted Linear Offset for K Avenue
Adjusted LRM Linear Offset (feet)
Table 7. Linear Offset Error before and after Calibration
Table 8. Point Features Referenced to Wrong Side of Roadway
Table 9. Comparison of Lateral Offset Calculated from Datum and LRM for Union Street
Table B.1. Distance along Union Road Segment where Street Light Was Located for Datum vs. LRM
Table B.2. Distance along Todd Drive Segment where Street Light Was Located for Datum vs. LRM
Table B.3. Distance along Airport Road Segment where Street Light Was Located for Datum vs. LRM
Table B.4. Distance along L Avenue Segment where Street Light Was Located for Datum vs. LRM.
Table B.5. Distance along K Avenue Segment where Street Light Was Located for Datum vs. LRM
Table C.1. Error in Lateral Offset for Airport Road Segment
Table C.2. Error in Lateral Offset for K Avenue Segment
Table C.3. Error in Lateral Offset for L Avenue Segment
Table C.4. Error in Lateral Offset for Todd Drive Segment
Table C.5. Error in Lateral Offset for N Avenue Segment
Global positioning systems (GPS) offer a cost-effective and efficient method to input and update transportation data. The spatial location of objects provided by GPS is easily integrated into geographic information systems (GIS). The storage, manipulation, and analysis of spatial data are also relatively simple in a GIS, since location, expressed in terms of coordinates, has the advantage of universal spatial applicability. However, many data storage and reporting methods at state departments of transportation and other transportation agencies rely on linear referencing methods (LRMs); consequently, GPS data must be able to link with linear referencing. Unfortunately, the two systems are fundamentally incompatible in the way data are collected, integrated, and manipulated. In order for the spatial data collected using GPS to be integrated into a linear referencing system or shared among LRMs, a number of issues need to be addressed. This report documents and evaluates several of those issues and offers recommendations. Although the report focuses on integrating GPS data with a LRM, spatial point features collected with other methods such as “heads-up” digitizing of orthophotos are similar to GPS data and the same incompatibilities exist in their integration into an LRM. Consequently, discussion of the issues in integrating spatial point feature data collected with GPS applies to spatial data collected using similar techniques.
In order to evaluate the issues associated with integrating GPS data with a LRM, a pilot study was created. To perform the pilot study, point features, a linear datum, and a spatial representation of a LRM were created for six test roadway segments that were located within the boundaries of the pilot study conducted by the Iowa Department of Transportation linear referencing system (LRS) project team.
Various issues in integrating point features with a LRM or between LRMs are discussed and recommendations provided. The accuracy of the GPS is discussed, including issues such as point features mapping to the wrong segment. Another topic is the loss of spatial information that occurs when a three-dimensional (x, y, x) or two-dimensional (x, y) spatial point feature is converted to a one-dimensional representation on a LRM. Recommendations such as storing point features as spatial objects if necessary or preserving information such as coordinates and elevation are suggested. The lack of spatial accuracy characteristic of most cartography on which LRM are often based, is another topic discussed. The associated issues include linear and horizontal offset error. The final topic discussed is some of the issues in transferring point feature data between LRMs.
Prior to the widespread use of geographic information systems (GIS), state departments of transportation (DOTs) relied on linear referencing methods (LRMs) to collect and store location information associated with the characteristics and condition of transportation systems (O’Neill and Harper, 2000). Linear referencing locates objects (point events) in terms of their distance and direction along a segment from a known set of points. Linear events, such as a section of roadway with a homogenous surface type, may also be located using linear referencing.
As GIS became more common, most DOTs implemented some type of geographic information system to maintain spatial data such as roadway networks or inventories of roadway features. Most agencies also integrated linear referencing systems into their GIS. Linear referencing systems (LRSs) were integrated both to maintain legacy databases (O’Neill and Harper, 2000) and because linear referencing is a natural fit for many data collection and reporting techniques used by DOTs and other transportation agencies. LRSs are widely used in transportation since it is often easier to locate items by their distance along a roadway than to collect actual position. Some data, such as pavement condition, are often collected on-road using a distance-measuring instrument (DMI) and are stored as a location (at 0.25 miles) or a segment (from 0.25 miles to 0.5 miles) referenced from a known point such as an intersection or milepost. Linear referencing is also an efficient and logical method for storing roadway attributes and reporting information. For instance, describing the location of an accident as “1/2 mile west of Milepost 149 on I-80,” is a more easily understood by an ambulance driver than a set of coordinates.
Although linear referencing serves an important function, collection of positional information like sign or traffic signal locations using this method can be difficult and in many cases impractical. Features located using linear referencing also lack spatial resolution. Two-dimensional (2D) or three-dimensional (3D) data must be converted to one-dimension (1D) and can only be described in terms of their relationship to another object. This makes many types of analyses in GIS difficult.
The widespread availability of global positioning systems (GPS) technology in recent years has fundamentally altered the way spatial data can be collected. A GPS receiver captures signals from an orbiting network of GPS satellites. Using information from at least four satellites, a GPS receiver is able to calculate its distance from each satellite and, through trilateration, calculate its position on earth. Consequently, a GPS can fairly accurately locate and store planar coordinates (usually latitude and longitude) for a particular point. Corresponding attribute data can be either manually or digitally data-logged, and then attached to the point feature in a database. Line and polygon features may also be collected with GPS by relating a line or series of lines between two or more points.
The portability and ease of use characteristic of GPS allow collection of spatial data in a context not before realized. With GPS the collection of positional information in locations where it is difficult or even dangerous to collect data with traditional methods is now possible. The technology also allows collection of real-time data. The use of GPS is also cost effective, since most mid-range priced GPS ($100 to $500) offer sufficient accuracy for collection of the type of data used in many transportation applications (typically one to five meters with differential correction).
An abundance of research exists on the applications of GPS for collection of transportation-related data, including transportation asset data; these applications are numerous and range in complexity from simple applications (such as collection of bus stops locations) to sophisticated (such as real-time vehicle tracking for intelligent transportation systems [ITS]). GPS and GPS/GIS systems have been used in transportation applications in a variety of situations including
· Emergency dispatch systems
· Travel speed and delay (Guo and Poling, 1995; D’Este, Taylor, and Zito, 1999)
· Sign inventory (Poling et al., 1994)
· Railroad crossings and wetland boundaries (Brich and Fitch, 1997)
· Congestion management for route identification and traffic monitoring (Quiroga and Bullock, 1996)
· Collection of roadway grade (Awuah-Baffour et al., 1997)
· Field data collection
· Travel time studies (D’Este et al., 1999)
· Collection of location attributes for transportation GIS data sets (Brich and Fitch, 1997)
· Real-time vehicle tracking
· Establishment of survey baselines, control densification, vehicle location, tracking buses, emergency response (Czerniak and Reilly, 1998)
· Highway inventory data (Britch and Fitch, 1997)
· Location of motor vehicle crashes (Miller and Karr, 1998)
· Household travel surveys (Murakami and Wagner, 1997)
GPS offers a cost-effective and efficient method to input and update transportation data. The spatial location of objects provided by GPS is easily integrated into GIS. The storage, manipulation, and analysis of spatial data are also relatively simple in GIS since location, expressed in terms of coordinates, has the advantage of universal spatial applicability (Goodwin et al., 1995). However, many data storage and reporting methods at state DOTs and other transportation agencies rely on linear referencing methods; consequently, GPS data must be interoperable with linear referencing. Unfortunately, the two systems are fundamentally incompatible in the way data are collected, integrated, and manipulated. In order for the spatial data collected using GPS to be integrated into a linear referencing system or shared among LRMs, a number of issues need to be addressed. This report documents and evaluates several of those issues and offers recommendations.
The original focus of this research was the integration of point features collected using GPS within a LRS, since GPS is currently the most common method of collecting the spatial location of roadway features. However, other methods are also available to collect spatial data. Prior to the widespread availability and use of GPS, traditional surveying was the common method to establish a feature’s coordinates and elevation. Although surveying is fairly time consuming and is not likely to be used for extensive data collection, it still may be the source of positional information used in a GIS. Roadway features may also be collected from remotely sensed images. Cartographic coordinates for a feature can be determined by identifying and recording its position on ortho-rectified aerial or satellite photos. As a result, the spatial location of objects may be collected with various methods. The final product, coordinates and elevation (if included), is similar to GPS data and the same incompatibilities exist in its integration into an LRM. Consequently, discussion of the issues in integrating spatial point feature data collected with GPS applies to spatial data collected using other techniques as well.
The ultimate goal of this research was to make recommendations on the integration of spatial point features collected using GPS with the linear referencing system being implemented at the Iowa Department of Transportation (Iowa DOT). Therefore, a brief description of the rules and methodology for their use in the LRS as described in various project documents reported to the Iowa DOT by the LRS project team follows.
A base datum will be created as part of the Iowa DOT LRS. The datum will consist of anchor points and anchor sections. Anchor points are geographic locations that establish the beginning and ending point for an anchor section. Anchor sections are distinct segments created by measuring the distance between the FROM and TO anchor points. The datum will be created and anchor sections measured using the most accurate and cost-effective method available, such as distance-measuring instruments. At the time this report was written a final method had not been selected.
Anchor sections per se have no spatial component. They only reflect a distance measure between two anchor points. However, it is expected that a spatial representation of the datum will be created that does have a geographic component. A spatial representation may be created using methods such as the video-log van with GPS or digitizing high-resolution orthophotos.
According to the Iowa DOT LRS pilot study, the method used to locate business data to a LRM should be able to do so within ±32.81 feet (±10 meters at 90%) (GeoAnalytics, Dec. 2000).
Ultimately it is intended that spatial data such as GPS points will be linked to the spatial representation of the datum. Feature coordinates would be mapped to the geographic representation of the datum, then output as a location reference in any of the specified LRM (GeoAnalytics, June 2000). The LRS is also designed to take as input a point feature’s linear offset along a route for a LRM supported by the LRS, transform the point’s offset to the datum, and then output that point’s location as a linear offset along the corresponding route for any other supported LRM. Transformation for each LRM is dictated by logic rules imbedded in the LRS (see GeoAnalytics, June 2000, pages 89–122 for more information). The supported LRMs include
The protocol for integrating spatial point data into the LRS is as follows:
1. Oracle Spatial will be used to establish a relationship between a point event and cartography. This will be accomplished similar to the existing dynamic segmentation capabilities of MGE Segment Manager. It is assumed that a linear offset will be established for the point feature along a specific LRM.
2. Oracle Spatial will be used to establish a relationship between cartographic elements and the LRS datum similar to conflation. The resulting relationship will resemble: a specific line segment is at Position X along Anchor Section Y.
3. Point features will be located along the datum from the initial LRM using a combination of 1 and 2 above for transformation to a different LRM. However, unlike LRMs, point locations cannot be directly related to the LRS datum. They must first go through cartographic transformation. It is assumed that the resulting relationship for a particular point event would resemble: Point Event A is Distance M along Anchor Section Y.
In order to accomplish the research objective of evaluating the issues associated with integrating GPS data (or independent geographic point features) with a LRM, a pilot study was performed. To perform the pilot study, test data were necessary, including point features, a linear datum, and a spatial representation of a LRM. A pilot study was selected that included six test roadway segments that were located within the boundaries of the pilot study conducted by the Iowa DOT LRS project team, as shown in Figure 1. All segments were located either in Ames or Nevada in Story County, Iowa, and are shown in Figures 2 and 3. A description of how each set of data elements was collected or created is discussed in the following sections.
A limited number of GPS points were available from a U.S. Department of Transportation project also being conducted by the researchers as part of the National Consortium on Remote Sensing in Transportation—Infrastructure. The GPS points were collected using kinematic GPS, resulting in centimeter accuracy. However, only a limited number of GPS points were collected due to cost constraints. Therefore, in order to have data for each of the six test segments, a point feature data set was created by digitizing the location of roadway features on digital orthophotos. Six-inch resolution orthophotos were available for portions of Story County, including parts of Ames and Nevada. The images were from the Iowa DOT. They originally were obtained by the Iowa DOT from the Story County Planning and Zoning Department, Story County, Iowa. The images were taken in 1998 by Aerial Services, Inc. The digital images were stored in tagged-image file (TIF) format.
The images were used as a background layer in ArcView-GIS. A point data layer was created, and after features were visually identified on the orthophotos, a point representing their spatial location was digitized. The process is shown in Figure 4. Information such as type of feature or ID number was added to an attribute table. Roadway features collected included streetlights, stop signs, and drainage structures. These features were selected since they were fairly common so that a significant number of each feature could be collected for each roadway segment.
In order to integrate point features with a LRM, a spatial LRM was necessary. Many LRMs, such as milepost LRMs, are based on distance measurements in the field and consequently have no spatial component. Since GPS points can only be linked to a LRM if a spatial representation is available, a test LRM based on the base record database (GIMS) cartography was created.
A single LRM route was created for each of the six test locations. To create an individual segment, all links along the base record database between the established beginning and ending point of the test segment were selected and a single route created. All links had to be selected and a route created since a single pilot study segment may have been composed of numerous individual arcs (lines) in the GIMS cartography.
At the time this project was initiated, the Iowa DOT LRS project was in the pilot testing stages and no anchor section or anchor point data sets were available. A set of anchor points and an anchor section was created for each test segment using heads-up digitizing of the street centerline on six-inch resolution orthophotos. The process is described in more detail in Sections 4.3.1 and 4.3.2. The anchor points and anchor section were created to represent a “datum” that represented the centerline and topography of each test segment as accurately as possible.
Spatial accuracy of the six-inch photographs was determined by comparing the spatial location of points in the images with spatial locations for the same points taken with a GPS with centimeter accuracy. A root mean square error (RMSE) test was performed and it was determined that 95% of the points fell within 3.89 feet of their location as measured by the GPS.
For each of the six sections, a set of anchor points was located according to the business rules established for the Iowa DOT LRS (GeoAnalytics et al., March 2001). The “beginning” (FROM) and “ending” (TO) points for anchor sections were marked. Most anchor points were located at the center of an intersection. The center of the intersection was defined as the point where the centerline of each approach met.
Anchor sections were created using the following protocol:
1. The FROM anchor point established the beginning of the segment.
2. The roadway centerline was determined by the following method:
a. A series of lines were drawn along the length of the segment from one edge of the roadway to the other perpendicular to the centerline; significant changes in cartography were characterized by more lines (see Figure 5).
b. An ArcView Avenue script was created that calculated the center of each line and created a point at the center of the roadway (see Figure 6).
3. The TO anchor point was established according to the business rules for the Iowa DOT LRS.
4. An Avenue script was written by Mr. Michael Pawlovitch of the Iowa DOT to create a polyline from the set of center and anchor points (see Figure 7).
The anchor sections represented a fairly geometrically correct spatial representation of the street centerline. GeoAnalytics et al. (March 2001) evaluated several data collection methods for creation of a datum for the Iowa DOT LRS project, including “heads-up” digitizing of high-resolution orthophotos (six-inch pixel resolution). They reported that the high-resolution images met the accuracy requirements for creation of both anchor section distances and anchor point coordinates.
The only major problem with the use of imagery to create anchor sections is that they only offer a planar view of the ground surface. As a result significant changes in vertical roadway profile cannot be accounted for. However, none of the study locations included significant changes in vertical alignment, so it is assumed that the anchor sections created provide a fairly accurate representation of the actual street segments.
As part of the pilot study, a map-matching program was created to “snap” a point feature to the nearest segment in a designated layer in order to calculate linear offset from the FROM node of the segment and establish a linear reference for the point. The program was written in Avenue script for ArcView 3.1 (the program can be obtained by contacting the author at shallmar@iastate.edu). The program’s logic follows.
The program requires and prompts the user for
The program logic is as follows:
1. Using the join command in ArcView, join the point and line feature layers by their “shape” fields, which uses ArcView’s logic to select the line in the line feature layer that is physically the closest to each point in the point feature layer.
2. Create a database.
3. Select the first point and the associated line segment selected as part the join command.
4. Select the FROM node for the line.
5. Starting at the FROM node, walk the line segment in 0.01% increments (for a one mile segment this represents about 6 inches; for a two mile segment this represents 12 inches).
a. Calculate the distance (Point_Distance) between the current point on the line segment and the point feature.
b. Compare this to the value for Point_Distance:
i. If the distance value is smaller than Point_Distance, then Point_Distance takes on the distance value;
ii. If the distance value is larger than Point_Distance, Point_Distance retains its original value.
6. When step 4 is completed, the variable Point_Distance should contain the shortest distance between the point feature and a point on the line.
7. Create a point (Closest_Point) on the line at the location where Point_Distance is the smallest.
8. Calculate the distance along the segment from the FROM node to Closest_Point.
9. Calculate latitude and longitude for Closest_Point.
10. Report to database:
a. Point feature ID
b. Line segment ID
c. Total length of line segment
d. Distance from line segment FROM node along the segment to Closest_Point (linear offset distance)
e. Point_Distance, which represents the shortest distance from the segment to the point feature (horizontal offset distance)
11. Repeat steps 4 through 10 for each of the point features.
The program outputs the linear distance along the route segment from the beginning node to the “snapped” point. The point’s linear and horizontal offset from the route segment centerline are recorded. The program output is a database as shown is Table 1. Program code is provided in Appendix A.
| Point ID |
Latitude |
Longitude |
Matched Route ID |
Route Length (feet) |
Linear Offset (feet) |
Horizontal Offset (feet) |
| 34 |
4869272.40 |
3471173.97 |
76 |
4787.7 |
345.8 |
15.1 |
| 35 |
4869448.26 |
3471173.92 |
76 |
4787.7 |
521.7 |
26.3 |
| 36 |
4869659.27 |
3471112.29 |
76 |
4787.7 |
747.0 |
6.9 |
| 37 |
4869784.56 |
3470937.61 |
76 |
4787.7 |
963.2 |
41.9 |
| 38 |
4869988.69 |
3470856.88 |
76 |
4787.7 |
1190.7 |
24.9 |
| 39 |
4870160.38 |
3470860.64 |
76 |
4787.7 |
1362.5 |
17.1 |
| 40 |
4870343.72 |
3470868.81 |
76 |
4787.7 |
1546.0 |
24.0 |
| 41 |
4870381.79 |
3470869.65 |
76 |
4787.7 |
1584.1 |
13.3 |
| 42 |
4870461.99 |
3470871.44 |
76 |
4787.7 |
1664.3 |
15.0 |
| 43 |
4870518.64 |
3470872.73 |
76 |
4787.7 |
1721.0 |
12.2 |
| 44 |
4870822.83 |
3470798.07 |
76 |
4787.7 |
2043.7 |
20.6 |
| 45 |
4870929.33 |
3470942.55 |
76 |
4787.7 |
2223.2 |
30.0 |
| 46 |
4871007.93 |
3471081.81 |
76 |
4787.7 |
2383.2 |
20.6 |
| 47 |
4871132.99 |
3471095.64 |
76 |
4787.7 |
2536.0 |
32.4 |
| 48 |
4871291.94 |
3471079.94 |
76 |
4787.7 |
2696.0 |
26.3 |
| 49 |
4871422.43 |
3471076.52 |
76 |
4787.7 |
2826.5 |
22.1 |
| 50 |
4871601.73 |
3471082.93 |
76 |
4787.7 |
3006.0 |
27.7 |
| 51 |
4871726.21 |
3471089.30 |
76 |
4787.7 |
3130.6 |
34.9 |
| 52 |
4871927.98 |
3471074.70 |
76 |
4787.7 |
3333.2 |
26.8 |
| 53 |
4872081.36 |
3471016.04 |
76 |
4787.7 |
3498.2 |
18.8 |
| 54 |
4872400.43 |
3470883.90 |
76 |
4787.7 |
3843.6 |
27.1 |
| 55 |
4872580.14 |
3470835.30 |
76 |
4787.7 |
4030.8 |
24.2 |
| 56 |
4872991.98 |
3470837.51 |
76 |
4787.7 |
4442.8 |
25.9 |
| 57 |
4873186.42 |
3470839.21 |
76 |
4787.7 |
4637.2 |
23.9 |
This section discusses issues in using global positioning systems to collect point feature data that will be stored or used in conjunction with linear referencing methods. In particular, issues relating to the transfer of this type of data through a LRS to different LRMs will be discussed.
Although both spatial and linearly referenced locations can be precisely located if correctly referenced to an accurate datum, there are several problems that may occur when point features are mapped to a LRM. First, spatial information may be lost when point features are converted to linear distances. Spatial modeling of linearly referenced objects may be more difficult in a GIS. Finally, the accuracy of a point located using linear referencing is dependent on the accuracy of the cartography on which the corresponding LRM is based. The loss of spatial information and modeling are discussed in the sections below. The issue of cartography accuracy is covered in Section 5.3.
Mapping points to a spatial LRM entails “snapping” the point to the nearest cartographic segment. The point is referenced by linear offset, which is computed along the centerline, typically referenced in relationship to a FROM node or anchor point. Noronha et al. (2000) describe this phenomenon of a 2D or 3D point being transformed to a 1D linear reference as linear transformation error. When a cartographic feature is “snapped” to a centerline segment, the 2D or 3D point is essentially constrained to the one-dimensional alignment of the centerline, resulting in a loss of accompanying information such as elevation or offset from the edge of pavement. LRMs do not uniquely define an object’s location on the earth’s surface except in relationship to other features (O’Neil and Harper, 1997). Although an object can be accurately located using LRMs, no direct relationship exists between a linearly referenced location and other cartographic features so spatial modeling is more difficult in many GIS packages.
A comparison of the two systems is illustrated in Figure 8. According to linear referencing, the speed limit sign is located 3.1 miles from Milepost 124 on the centerline of Interstate 15. That is the extent of the spatial information provided by the LRM (although information can be preserved as attributes). As a set of Cartesian coordinates, the speed limit sign is at a specific latitude and longitude. It is located 3.1 miles east of Milepost 124. It is 30 feet north of the centerline.
Most GIS packages used in transportation (ArcView, Transcad, ArcInfo, MapInfo, etc.) represent features as a combination of nodes and arcs between nodes. As such, common GIS modeling tools utilize a feature’s spatial location to determine its relationship to other features, such as proximity. A feature’s topological relationship to other cartographic entities can be established and operations such as overlay or spatial join performed. Distance and direction from other entities can be calculated as well. Spatially locating a feature with GPS, orthophotos, or similar methods, results in a set of coordinates that describe the feature’s unique physical location on the earth’s surface (O’Neil and Harper, 1997). Once spatial location is established, the feature represented as a point, can easily be integrated into and modeled in most GIS. This process is much more difficult with linear referencing. Even if a GIS is capable of linear referencing, they frequently do not have common spatial analysis tools to handle features that are referenced in this manner.
Point features may be maintained as cartographic elements in order to preserve spatial information. As such, they can be updated, modeled, and analyzed as individual entities in a GIS. Features can be transferred to a LRM “on the fly” as needed using a map-matching program, such as the one described in Section 4.4. This solution makes the most sense for features that will regularly be modeled or updated spatially. The main advantage of storing features as individual points is that spatial modeling is fairly simple. Maintaining individual points also avoids constraining a feature to inaccurate cartography.
The main disadvantage is that most roadway features are relevant in relationship to a specific roadway. If no relationship exists between a feature and the corresponding roadway, the feature may erroneously map to the wrong segment if the roadway alignment changes. For example, assume the case of an accident that occurred on a two-lane road called Main Street and is stored as a point feature. If Main Street was replaced by a new four-lane divided highway, the accident will be mapped to the nearest roadway and will be located along the new highway and would be incorrectly attributed to the new road. If features are maintained as individual points, some relationship should be established with a corresponding LRM for situations such as roadway alignment changes. LRM information such as segment ID and linear offset can be stored as attributes.
However, the majority of features collected and maintained by DOTs are more likely to be updated and used according to their relationship to a roadway and would not be maintained as point features. For example, although a sign inventory may initially be collected using GPS, sign maintenance is carried out by maintenance crews who refer to individual signs by their position along a specific roadway rather than their cartographic position. A number of features, such as accident locations or sign inventories, are analyzed as linear offsets and should logically be stored that way as well. Other features may not specifically be analyzed or used as linear offsets along a roadway but have historically been maintained as such. Either way, storing these features as individual cartographic elements and then transferring them to a LRM as needed is cumbersome. They are better suited to storage and maintenance in a LRM. Additionally, if features are stored in conjunction with a LRM, changes in roadway alignment will be automatically updated and points will remain associated with the correct roadway segment. The disadvantages are that spatial modeling is more difficult as discussed previously. Additionally, points constrained to a LRM are subject to inaccuracies in the cartography and network pathologies (as will be discussed later). If the centerline database on which the LRM is based is corrected in the future, providing an improved representation of the roadway centerline, features will need to be converted back to points and then re-mapped. If the feature’s original coordinates are not preserved, propagation of error will result if linear offset is transferred from the original LRM to an updated one.
In order to preserve spatial information about the feature, 2D or 3D attributes, such as x, y coordinates, elevation, or horizontal offset from the roadway centerline, can be stored in data fields. If coordinate information is preserved, future conversion of the data to cartographic features is possible, allowing spatial modeling as needed.
Problems inherent in the data collection methods used to spatially locate point features is the first issue that influences linking them to a LRM. Lower cost GPS, which rely on a single reading, are often only accurate to around 49 feet even with selective availability (S/A) turned off. For more accurate GPS, location is reported as the average of multiple location readings, resulting in a “circle of uncertainty.”
When a point with inaccurate spatial position is mapped to a LRM or cartography, the linear offset distance may be measured either longer or shorter than it actually is. Inaccurate position may also result in the point feature “snapping” to the wrong segment as shown in Figure 9. Other data collection methods, such as digitizing location on orthophotos, may result in spatial inaccuracies as well.
With higher accuracy data collection methods (less than ±3 feet), none of the data collection accuracy issues is expected to be relevant. However, higher accuracy methods are also more costly and time consuming than lower accuracy methods.
Consequently, although lower accuracy data collection methods may result in a point being matched to the wrong segment or in inaccurate calculation of linear offsets (which will require some adjustment to the data later), the benefits of significantly lower costs and time savings may outweigh the disadvantages for some applications. As a result, the application should determine which data collection method has the most appropriate accuracy. Sign locations may only need to be located to within 20 feet of their true position, while mileposts may need to be located within inches.
Point features with inaccurate spatial positions may be “snapped” to the wrong segment. However, even features that are located with high-accuracy data collection methods may “snap” to the wrong segment if they are physically closer to that segment’s centerline. For example, a sign located on a roadway with several lanes may actually physically be closer to the centerline of the minor intersecting roadway with only one lane. In either case, a fairly simple solution is the use of route identifiers during data collection. In the field, data collectors can easily identify and record the street segment corresponding to the feature collected. Street names or link numbers can be used. Identifying information such as physical orientation of the feature in relationship to the street network, hierarchy, and logic is available to assist data collectors in selecting the appropriate roadway for matching. The same method can be used when locating features with digital images
In order to evaluate the impact of using route identifiers, a test set of 23 street signs and 41 streetlights were located as point features along a test segment in the pilot study. The point features were collected as described in Section 4.1. Each feature was assigned the route ID for the proper roadway link in the GIMS database. The corresponding link for each feature was established by visual inspection of the aerial photos.
The features were also mapped to the GIMS database using a spatial overlay function, which snaps an object in one spatial data set to the nearest object in another (point to nearest line, line to nearest line, etc.). As shown in Table 2, 43% of the signs and 10% of the streetlights were snapped to the wrong segment using the spatial overlay. With the use of route identifiers all features snapped to the correct road segment.
| Table 2. Matching Point Features to the Correct Street Segment with and without Route Identifiers |
||
| Street Signs |
Street Lights |
|
| Total number of features |
23 |
41 |
| Correctly matched to street segment using route identifiers |
23 (100%) |
41 (100%) |
| Correctly matched to street segment using spatial overlay |
13 (57%) |
37 (90%) |
The main advantage of route identifiers is that with the additional time spent identifying the corresponding street segment during data collection, features can be accurately referenced to the correct segment. An additional benefit is that when features are assigned to routes in the field that cannot be matched to the street database, it may indicate a missing segment or roadway in the street database.
The most significant disadvantage to use of route identifiers is that with some methods it may be time consuming to record that information during data collection. Manual identification of the corresponding segment is also subject to error if data collectors are unsure of street names or identifying link numbers or if data are entered incorrectly. However, with other data collection methods, this process may be automated. For example, video-logging methods may already include the route. Handheld data-loggers can also be coded with pull-down menus to facilitate entering the route.
In order to link spatial point features to a LRM, a spatial representation of the LRM is necessary. Otherwise features must be referenced to a LRM with a spatial representation or to cartography and then be translated. Most spatial representations of LRM are based on cartography, which often contains inaccuracies. This section describes the issues of matching point features to a LRM based on cartography or to cartography itself.
As of the time this report was written, the Iowa DOT LRS intended to develop a spatial representation of the datum that will serve as the base for the LRS. The datum and spatial representation of the datum will be created using the most accurate method that is also cost effective. If a spatial representation of the datum is available, point features may be mapped directly to the datum and then translated to other LRM as needed. If a highly accurate cartographic representation of the datum is created using a method such as head-up digitizing of high-resolution orthophotos, many of the issues discussed in the section may not be significant.
One of the most significant issues in relating GPS data to a LRM is the spatial accuracy of the cartography on which the LRM is based, since cartography often contains spatial inaccuracies and/or lack or currency. In contrast, most GPS data are highly accurate. Consequently mapping a fairly accurate point feature to less accurate cartography influences the accuracy with which the point can be initially referenced to a LRM and affects how a point is later transferred between LRM.
The two common types of errors in cartography are spatial alignment errors and insufficient polyline resolution (Noronha et al., 2000). Alignment errors include missing segments, inaccurate representations of street segments, and spatial inaccuracy. Road segments may be missing as a result of digitizing error or because the database is not current. Inaccurate representation of the street centerline is usually due to digitizing error, but may also occur when street alignment changes but the database is not updated. Spatial accuracy is a measure of where cartography is located in relationship to its actual real world location. A cartographic representation of a street centerline may correctly represent roadway geometry but be offset from its actual position by some distance.
When GPS points are matched to cartography with spatial alignment errors, they may be matched to the wrong position along a roadway segment, resulting in inaccurate specification of linear offset. With alignment error, features may also be matched to the wrong street segment because it is artificially closer to a feature than the correct segment.
Insufficient polyline resolution occurs when a line segment lacks “shape,” as shown in Figure 10. It is the result of either basing cartography on maps that lack spatial detail or digitizing an insufficient number of arcs. Lack of polyline resolution results in artificially short or long referencing segments, as shown in Figure 11. The figure illustrates how a point is inaccurately referenced due to lack of polyline resolution and for purposes of illustration assumes an even distribution of inaccuracies along the segment. As a result, even if GPS points are matched to the correct location along a segment, calculation of linear offset may be under- or overestimated.
The most logical solution is to base spatial representations of LRM on the most spatially accurate and up-to date cartography feasible. Depending on the accuracy required, this may entail creation of a new spatial representation of the LRM using methods such as heads-up digitizing of orthophotos. However, since this is not always feasible, the following sections describe specific spatial accuracy issues as well as offer recommendations.
In order to use a spatial point feature in a LRM or to reference the point among LRM, the point must be mapped to a corresponding segment and the linear offset along the segment calculated to reference the point’s location. As discussed, both alignment errors and insufficient polyline resolution may result in linear offsets segments that are either longer or shorter than the actual street they are representing.
The magnitude of linear offset error was evaluated of as part of the pilot study. Streetlights along each of the six test segments were located and digitized as point features and then mapped to both the “datum” and cartography based LRM. The points were located using the map-matching algorithm described in Section 4.4. Linear offsets for the points mapped to the pilot LRM were compared against linear offsets for the same points mapped to the pilot “datum.” It was assumed that the “datum” accurately represented the street centerline and that the points were mapped to the correct location. Linear offset error was calculated by
error = offsetdatum – offsetLRM (1)
where
error = linear offset error
offsetdatum = linear offset for point i along datum
offsetLRM = linear offset for point i along LRM
Table 3 provides the result of error calculation for the N Avenue segment. Table 4 shows a summary of results for the remaining five segments; error calculations for the remaining five segments are provided in Appendix B. A distribution of the error for each segment is provided in Figure 12.
The error can likely be attributed to both alignment error and insufficient polyline resolution of the base record street database. Although determining the magnitude of each was beyond the scope of this project, alignment error was obviously present, as shown in Figure 13. Insufficient polyline resolution may also have contributed to the error, as shown in Figure 14, for the Airport Road test segment. The measured LRM and “datum” length for each of the six segments is shown in Table 4. Differences up to nearly 111 feet were noted. For four of the segments, cartography was from 70 to 111 feet longer or shorter than the measured datum segment length. Differences of less than 10 feet were noted for two of the segments; both were located in Nevada.
| Table 3. Distance along Segment where Street Light Was Located for Datum vs. LRM (N Avenue) |
|||
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 223 |
25.3 |
64.3 |
-39.0 |
| 224 |
350.5 |
351.0 |
-0.5 |
| 225 |
791.8 |
735.8 |
56.0 |
| 226 |
1237.7 |
1179.3 |
58.4 |
| 227 |
1366.4 |
1307.9 |
58.5 |
| 228 |
1361.8 |
1303.4 |
58.4 |
| 229 |
1752.5 |
1692.7 |
59.8 |
| 230 |
1890.4 |
1830.4 |
60.0 |
| 231 |
2022.6 |
1964.7 |
57.9 |
| 232 |
2365.0 |
2294.2 |
70.8 |
| 233 |
2711.0 |
2637.3 |
73.7 |
| 234 |
2929.3 |
2856.2 |
73.1 |
| 235 |
3170.6 |
3097.7 |
72.9 |
| 236 |
3393.6 |
3321.2 |
72.4 |
| 237 |
3859.0 |
3787.2 |
71.8 |
| 238 |
3942.9 |
3870.7 |
72.2 |
| 239 |
4116.4 |
4043.4 |
73.0 |
| 240 |
4232.5 |
4159.6 |
72.9 |
| 241 |
4453.1 |
4380.8 |
72.3 |
| 242 |
4617.5 |
4545.6 |
71.9 |
| 243 |
4940.4 |
4868.3 |
72.1 |
| 244 |
5405.8 |
5333.3 |
72.6 |
| 245 |
5713.8 |
5641.3 |
72.5 |
| Segment |
LRM Length (feet) |
Datum Length (feet) |
Difference (feet) |
| N Avenue |
5,642.5 |
5,746.0 |
103.5 |
| Airport Road |
13,921.9 |
13,811.2 |
-110.5 |
| K Avenue |
5,189.9 |
5,197.1 |
7.2 |
| L Avenue |
6,213.3 |
6,208.2 |
-4.9 |
| Todd Drive |
4,787.2 |
4,860.5 |
72.8 |
| Union |
7,257.9 |
7,358.8 |
100.9 |
If the linear offset error can be attributed to inaccuracies in alignment, an offset adjustment can be made. With inaccurate alignment, a segment may represent the roadway geometry fairly well but be incorrectly positioned spatially. This may result in a segment being horizontally or vertically offset from the actual street centerline, as shown in Figure 13. If the amount of offset can be estimated, the position of point features mapped to the LRM can be adjusted by the amount of offset.
The test segment L Avenue is illustrated in Figure 13. As shown, the base record cartography on which the test LRM was based was fairly similar in shape and length to the datum segment. The length of the LRM segment was 6,213.3 feet and the length of the datum segment was 6,208.2 feet, with a difference of only 4.9 feet. The cartography, however, was offset 37 feet to the west. To adjust for offset, the point features mapped to the LRM were adjusted by this distance using
offsetadjusted for point i = offsetLRM for point i – 37.0 feet (2)
where
offsetadjusted = adjusted linear offset for point i (feet)
offsetLRM = linear offset along LRM for point i (feet)
|
N
Avenue |
|
||
| |
|
||
| |
|
||
Table 5 provides the results of adjusting the linear offset. The reduction in error for the point features before and after their linear offset along the LRM was adjusted is provided as well. Initial error was calculated using equation 1. Error after adjusting the offset was calculated using
erroradjusted = offsetdatum – offsetadjusted (3)
where
erroradjusted = difference between actual position of point i according to the datum
and its adjusted position along the LRM (feet)
offsetdatum = linear offset along datum for point i (feet)
offsetadjusted = adjusted linear offset for point i (feet)
As shown in Table 5, the average error of 36.4 feet was reduced to an average error of 0.6 feet. After adjusting for linear offset, error for all segments was less than 3 feet.
A similar scenario was present for the K Avenue segment. The LRM segment and “datum” segment have similar geometry and length. The length of the LRM segment was 5,189.9 feet and the length of the datum segment was 5,197.2 feet, for a difference of 7.2 feet. However, the cartography was offset approximately 16 feet to the west of the datum. Table 6 shows the reduction in error due to adjusting offsets by 16 feet as for the L Avenue. Error was reduced from an average of 19 feet to less than 2.5 feet for all points.
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Adjusted LRM Linear Offset (feet) |
errorLRM (feet) |
erroradjusted (feet) |
| 291 |
182.5 |
219.9 |
182.9 |
-37.4 |
-0.4 |
| 293 |
339.0 |
376.5 |
339.5 |
-37.5 |
-0.5 |
| 294 |
633.2 |
671.0 |
634.0 |
-37.8 |
-0.8 |
| 295 |
516.5 |
554.2 |
517.2 |
-37.7 |
-0.7 |
| 296 |
961.0 |
996.6 |
959.6 |
-35.6 |
1.4 |
| 297 |
1399.3 |
1435.2 |
1398.2 |
-35.9 |
1.1 |
| 298 |
1403.1 |
1440.2 |
1403.2 |
-37.1 |
-0.1 |
| 299 |
1576.9 |
1612.9 |
1575.9 |
-36.0 |
1.0 |
| 300 |
1766.9 |
1804.3 |
1767.3 |
-37.4 |
-0.4 |
| 301 |
1920.8 |
1957.1 |
1920.1 |
-36.3 |
0.7 |
| 302 |
2135.6 |
2173.4 |
2136.4 |
-37.7 |
-0.7 |
| 303 |
2333.1 |
2369.7 |
2332.7 |
-36.6 |
0.4 |
| 304 |
2525.5 |
2563.5 |
2526.5 |
-38.0 |
-1.0 |
| 305 |
2690.6 |
2725.1 |
2688.1 |
-34.4 |
2.6 |
| 306 |
2760.2 |
2795.9 |
2758.9 |
-35.7 |
1.3 |
| 307 |
2893.0 |
2930.1 |
2893.1 |
-37.1 |
-0.1 |
| 308 |
3066.9 |
3101.6 |
3064.6 |
-34.7 |
2.3 |
| 309 |
3255.6 |
3291.7 |
3254.7 |
-36.1 |
0.9 |
| 310 |
3620.6 |
3658.3 |
3621.3 |
-37.7 |
-0.7 |
| 311 |
4132.2 |
4167.8 |
4130.8 |
-35.6 |
1.4 |
| 312 |
4366.9 |
4403.9 |
4366.9 |
-37.0 |
0.0 |
| 314 |
5123.0 |
5159.4 |
5122.4 |
-36.4 |
0.6 |
| 315 |
5349.0 |
5385.6 |
5348.6 |
-36.6 |
0.4 |
| 316 |
5443.4 |
5478.8 |
5441.8 |
-35.4 |
1.6 |
| 317 |
5577.5 |
5613.0 |
5576.0 |
-35.5 |
1.5 |
| 318 |
5815.9 |
5851.6 |
5814.6 |
-35.7 |
1.3 |
| 319 |
5721.5 |
5757.1 |
5720.1 |
-35.6 |
1.4 |
| 320 |
5978.5 |
6014.3 |
5977.3 |
-35.8 |
1.2 |
| 321 |
6153.6 |
6189.5 |
6152.5 |
-35.9 |
1.1 |
| Average error |
-36.4 |
0.6 |
|||
| Maximum error |
-38.0 |
2.6 |
|||
It should also be noted that the maximum error for K Avenue was only around 18 feet. Although offset was calculated to demonstrate how error could be reduced, an error of less than 20 feet may not be significant enough to warrant the effort of calculating and adjusting error.
Although adjusting the linear offset for point features significantly reduced error, the process may be time consuming since the problem first must be identified and then an offset distance measured and adjustments made to the linear offset distances. Either a spatial representation of the datum or another means to identify the correct location of the centerline, such as high-resolution aerial photographs, is also necessary to identify and measure offset. However, the process is relatively simple and as demonstrated above may significantly reduce error.
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
errorLRM (feet) |
erroradjusted (feet) |
|
| 378 |
161.1 |
177.5 |
161.5 |
-16.4 |
-0.4 |
| 379 |
455.3 |
471.2 |
455.2 |
-16.0 |
0.0 |
| 380 |
660.0 |
675.7 |
659.7 |
-15.7 |
0.3 |
| 381 |
759.8 |
777.4 |
761.4 |
-17.6 |
-1.6 |
| 382 |
1013.4 |
1029.7 |
1013.7 |
-16.2 |
-0.2 |
| 383 |
1130.9 |
1149.0 |
1133.0 |
-18.1 |
-2.1 |
| 384 |
1453.1 |
1469.8 |
1453.8 |
-16.7 |
-0.7 |
| 385 |
1436.5 |
1453.2 |
1437.2 |
-16.7 |
-0.7 |
| 386 |
1584.1 |
1600.6 |
1584.6 |
-16.5 |
-0.5 |
| 387 |
1513.4 |
1530.0 |
1514.0 |
-16.6 |
-0.6 |
| 388 |
1805.5 |
1822.7 |
1806.7 |
-17.2 |
-1.2 |
| 389 |
1871.0 |
1887.0 |
1871.0 |
-16.1 |
-0.1 |
| 390 |
1807.6 |
1824.8 |
1808.8 |
-17.2 |
-1.2 |
| 391 |
1925.0 |
1942.0 |
1926.0 |
-17.0 |
-1.0 |
| 392 |
2050.8 |
2066.6 |
2050.6 |
-15.8 |
0.2 |
| 393 |
2242.0 |
2259.7 |
2243.7 |
-17.6 |
-1.6 |
| 394 |
2415.6 |
2432.0 |
2416.0 |
-16.4 |
-0.4 |
| 395 |
2561.1 |
2577.3 |
2561.3 |
-16.1 |
-0.1 |
| 396 |
2939.5 |
2956.2 |
2940.2 |
-16.7 |
-0.7 |
| 399 |
3796.0 |
3812.5 |
3796.5 |
-16.5 |
-0.5 |
| 400 |
4510.1 |
4526.6 |
4510.6 |
-16.5 |
-0.5 |
| 401 |
4835.4 |
4850.5 |
4834.5 |
-15.1 |
0.9 |
| 402 |
5162.8 |
5176.4 |
5160.4 |
-13.6 |
2.4 |
| Average Error |
-16.4 |
-0.4 |
|||
| Maximum Error |
-18.1 |
2.4 |
|||
Linear offset error may also be attributed to differences in the segment lengths calculated by different methods. Cartography that does not accurately represent roadway geometry will result in a segment that is shorter or longer than the actual roadway as discussed in Section 5.3.1 and may result in point features mapping to the wrong location along the segment. Ries and DuChateau (2001) suggest a calibration process that adjusts the linear offset distance for a point feature using the following equation:
offsetcalibrated = (offsetLRM * distdatum)/distLRM (4)
where
offsetcalibrated = calibrated linear offset distance for point i
offsetLRM = linear offset along the LRM for point i
distdatum = length of datum segment
distLRM = length of LRM segment
This process was applied to adjust the linear offsets for point features mapped to the LRM for four of the six test pilot segments. Initial linear offsets calculations were described in Section 5.3.2. For each point feature on a segment, the initial linear offset was calibrated using equation 4. The error between the linear offset for the LRM segment and the linear offset along the datum segment was calculated for each point before and after the LRM linear offset was calibrated. Results are provided in Table 7. As shown, the average error was reduced significantly using calibration.
| Segment |
Maximum Error (feet) |
Average Error (feet) |
Standard Deviation of Error (feet) |
95% Confidence Interval for Error (feet) |
| N Ave. linear offset along LRM |
73.7 |
60.2 |
26.7 |
48.6 to 71.7 |
| N Ave. calibrated linear offset along LRM |
42.5 |
8.1 |
23.4 |
-2.0 to 18.2 |
| Airport Rd. linear offset along LRM |
-91.8 |
-75.6 |
5.6 |
-77.1 to 74.1 |
| Airport Rd. calibrated linear offset along LRM |
-79.8 |
-21.4 |
32.3 |
-30.2 to -12.6 |
| Todd Dr. linear offset along LRM |
63.2 |
49.9 |
14.1 |
43.9 to 55.9 |
| Todd Dr. calibrated linear offset along LRM |
47.6 |
14.2 |
19.9 |
5.8 to 22.6 |
| Union Ave. linear offset along LRM |
90.0 |
48.6 |
26.4 |
39.1 to 58.1 |
| Union Ave. calibrated linear offset along LRM |
35.3 |
-4.6 |
22.1 |
-12.6 to 3.4 |
When point features are mapped to a LRM, they are primarily referenced according to their linear offset from a reference location. For some feature types, such as accidents, no other spatial location information is required. In other applications, a feature’s lateral relationship to the centerline may be important (perpendicular offset from the centerline). Snowplow operators may need to know not only how far a sign is from the last milepost but also how far it is from the edge of the roadway. With inaccurate cartography, calculation of lateral offset distance may be affected as well as placement (north of the centerline, south of the centerline, etc.).
Streetlights were located as point features and mapped to the six pilot study segment LRMs and “datums” to evaluate lateral offset and placement. Table 8 illustrates the number of features that were referenced to the wrong side of the roadway (e.g., north rather than south) by segment. As shown, from 13% to 44% of points were located to the wrong side of the segment, as illustrated in Figure 15. Table 9 provides a comparison between the lateral offset distances calculated from the centerline of the base record cartography (LRM) with the lateral offset distance calculated using the “datum.” The table illustrates lateral offset error for Union Street. Data for the other five segments are provided in Appendix C. Figure 16 shows the distribution of error for each of the six segments. Errors in lateral offset up to 90 feet resulted among the six test segments, and lateral offset errors of 20 to 60 feet were common.
The magnitude of lateral offset error is more significant than linear offset error. Lateral offset establishes the distance an object lies from the centerline. Most objects are only 20 to 100 feet from centerline anyway, so lateral offset error of 20 to 60 feet could double the recorded distance.
| Table 8. Point Features Referenced to Wrong Side of Roadway |
|||
| Segment |
Matched to Wrong Side of Segment |
Total Number of Points |
Percent Matched to Wrong Side of Segment |
| N Avenue |
6 |
23 |
26% |
| Airport Road |
24 |
54 |
44% |
| K Avenue |
3 |
23 |
13% |
| L Avenue |
6 |
29 |
21% |
| Todd Drive |
1 |
24 |
4% |
| Union |
5 |
32 |
16% |
| Table 9. Comparison of Lateral Offset Calculated from Datum and LRM for Union Street |
|||
| Point ID |
Datum Lateral Offset (feet) |
LRM Lateral Offset (feet) |
Error |
| 133 |
20.1 |
30.1 |
-10.0 |
| 132 |
24.7 |
18.7 |
6.0 |
| 131 |
24.4 |
16.8 |
7.6 |
| 130 |
25.1 |
17.1 |
8.0 |
| 129 |
17.2 |
9.0 |
8.2 |
| 128 |
29.9 |
25.0 |
4.9 |
| 127 |
26.5 |
25.5 |
1.0 |
| 126 |
26.3 |
31.7 |
-5.4 |
| 125 |
27.7 |
48.9 |
-21.2 |
| 124 |
29.6 |
3.9 |
25.7 |
| 123 |
22.4 |
7.3 |
15.1 |
| 122 |
28.7 |
11.3 |
17.4 |
| 121 |
27.3 |
5.2 |
22.0 |
| 119 |
28.4 |
51.1 |
-22.7 |
| 118 |
23.9 |
56.8 |
-32.9 |
| 117 |
25.9 |
9.7 |
16.1 |
| 116 |
24.7 |
17.7 |
7.0 |
| 115 |
24.3 |
24.0 |
0.3 |
| 114 |
28.7 |
19.8 |
8.8 |
| 113 |
35.8 |
71.2 |
-35.5 |
| 112 |
26.9 |
10.6 |
16.3 |
| 111 |
25.4 |
6.0 |
19.5 |
| 110 |
30.4 |
1.9 |
28.4 |
| 109 |
31.0 |
7.6 |
23.4 |
| 108 |
31.1 |
3.0 |
28.0 |
| 107 |
26.4 |
24.4 |
2.0 |
| 106 |
26.6 |
32.0 |
-5.4 |
| 105 |
25.0 |
32.9 |
-7.9 |
| 104 |
26.2 |
36.3 |
-10.2 |
| 103 |
27.0 |
20.5 |
6.6 |
| 102 |
28.6 |
24.1 |
4.5 |
| 101 |
27.3 |
20.0 |
7.3 |
With spatial inaccuracies in cartography, lateral offsets may be calculated either longer or shorter than they should be. Points may also map to the wrong side of the street segment. To address this, placement and lateral offset information can be included as part of data collection. A feature’s lateral placement (left, right, east, west, etc.) in relationship to the roadway centerline can be noted fairly easily and added during data collection. Lateral distance from the centerline can be measured during data collection as well. If GPS were the data collection method, measurement of lateral offset would require use of a DMI or other measurement method in the field. As a result, collection of this information may be more time consuming and only be warranted when lateral offset is critical. If digital aerial photographs are used to locate point features, measurement of lateral offset can be done fairly simply using an on-screen measurement tool in GIS.
In the event that the use of inaccurate cartography is the only method available to determine lateral offset, it recommended that lateral offset not be used at all. If an object cannot be correctly placed on the proper side of the roadway and cannot be located within a few meters, the use of horizontal offset becomes fairly meaningless for most applications. A 30-foot error in linear offset along a 3000-foot segment may not be significant. A 30-foot error in horizontal offset when the object is only 45 feet from the roadway centerline is significant. Cartography that varies from the centerline more than a few meters may be considered inaccurate for the purpose of calculating horizontal offset.
Errors in spatial alignment of a LRM may result in GPS point features matching to the wrong segment. The problem may be magnified if there are significant inaccuracies in the point’s spatial location as well.
The use of route identifiers as discussed in Section 5.2.2 is the most logical way to prevent mapping of point features to the wrong segments.
Besides accuracy, the next most significant issue in basing a LRM on cartography is currency. Street databases that are not maintained and updated regularly may be missing newer road segments and road alignment changes. Point features located next to missing roadway segments would be inappropriately matched to the wrong street segment. Unmaintained databases may also have obsolete representations of roadway segments that have undergone significant realignment, which may result in point features being mapped to the wrong location along a link or being mapped to the wrong link. Completeness of the database is equally significant. For accurate mapping, an up-to-date street network is necessary, especially in areas with rapid urban growth.
Once point features are initially mapped to a specific LRM or a spatial representation of the datum and the appropriate adjustments are made, the next significant issues are those related to transfer of point feature data among LRMs. Different linear referencing methods within an agency may be based on different cartography, measurement systems, etc. As a result, the same segment of roadway may have different linear measurements. LRMs may also segment a section of roadway differently so that segments aren’t consistent from one LRM to another. These and other issues on transferring data between LRM are discussed in the following sections.
Most of the issues discussed in the following sections only apply to data collected prior to full implementation of the Iowa DOT LRS. Once an improved spatial representation of the street centerline is available, it should be used for mapping of all point features and measurement of linear offset.
Most LRMs currently in use at the Iowa DOT, which have a spatial representation, are based on the GIMS cartography. In order to transfer existing data from LRMs, it is assumed that a relationship between the base record cartography or any cartography and the datum will be established as part of the Iowa DOT LRS project. In the future, a better spatial representation of the roadway centerline should be available for use in linking GPS or other spatial points. For existing point features (data collected prior to full implementation of the Iowa DOT’s LRS) that were initially mapped to a LRM based on the GIMS cartography or other cartography, transfer of point features to other LRM that are based on the GIMS cartography, should be fairly simple with an established protocol. Linear offset distances and lateral offset, if used, should remain consistent even if transferred through the datum.
Since LRMs are created by a variety of methods, distance calculated using different methods might result in inconsistent measurements between LRM for the same segment. A significant amount of error may occur when linear offsets for point features are transferred between LRM that have inconsistencies in segment length as shown in Figure 17. A point feature is shown, whose linear offset is measured as 737 feet along LRM 1 and falls 18 feet before 2nd Street. The distance from 1st Street to 2nd Street in LRM 1 is 755 feet in length. When the point’s linear offset is transferred to the datum, which measures 776 feet between the two intersections, the point now falls almost 40 feet from 2nd Street. When transferred to LRM 2, which has measures only 725 feet between 1st and 2nd Street, the point at 737 feet falls 12 feet past 2nd Street and is now incorrectly located between 2nd and 3rd Streets.
It is assumed that all LRM will be related to the base datum so that points can be transferred from the LRM to the datum and out to another LRM. Since the base datum will be the most accurate measurement available for a segment, it is suggested that point features first be transferred to the datum before being converted to another LRM. This process is already established in the algorithm development of the Iowa DOT LRS. In order to transfer points to the datum, the appropriate offset or calibration should be applied as described in Section 5.3.3 to minimize error. Once a feature is located along the datum, a relationship can be established with another LRM. Differences in datum segment lengths and the corresponding LRM segment lengths for the second LRM can be accounted for using the calibration process described in Section 5.3.3.
If point features are mapped directly to a spatial representation of the datum, the relationship established as part of the Iowa DOT LRS project can be used to transfer linear offsets for points from the datum to any other LRM. If no relationship is established, the difference between a segment’s measured length in the datum and the measured length in another LRM can be minimized by using the calibration process described in Section 5.3.3. Noronha et al. (2000) also suggest storing linear offset as a percentage, which is directly transferable to any LRM and is similar to calibration, where
percentoffset = (offseti/lengthLRM) * 100 (5)
where
percentoffset = % of segment length that point i is offset
offseti = linear offset for point i
lengthLRM = segment length
Storing linear offset as a percentage for transfer between LRM is shown in Figure 18. The point feature illustrated in Figure 17 has a linear offset of 737 feet along the centerline from 1st Street and 2nd Street, which was measured as 755 feet. When converted to a percentage, the point lies at a distance of 97% of the segment between the two intersections. When transferred to the datum or LRM 2, the point still falls at 97% and remains located between 1st and 2nd Streets.
Point features are commonly initially mapped to whichever LRM they are associated with, depending on the agency collecting the data. However, in order to minimize error in transferring point features between LRM, it is recommended that point feature data first be mapped to the spatial representation of the datum before being transferred between LRM. If this is not possible for some reason, the most spatially accurate LRM should be used.
Anchor sections and LRM segments may be a mile or more in length. As a result a single segment may span several intersections. Even if a point initially maps to the correct roadway segment, transfer of data between LRM with unequal segment lengths may result in the feature being located to a different roadway segment in another LRM, as illustrated in Figure 19. As shown, the GPS point is located 190 feet from anchor point 228. In LRM 1 this distance falls between 2nd Street and 3rd Street. For LRM 2, the point falls between 3rd Street and 4th Street. The may occur even if the point is stored as a percentage of the segment or if the point’s distance is calibrated between the two segments.
One way to minimize the possibility of this occurring is to establish the location of significant midsegment intersections along a LRM segment or anchor section. Subsectioning a segment in this manner allows a point to be referenced to the nearest upstream and downstream intersection rather than the nearest FROM and TO nodes. This works similar to route identifiers. The location of landmarks may also be established midsegment. Referring to Figure 19, with midsegment locations the point would have mapped to the correct roadway section. Calibration or storing points as a percentage can then be used to adjust differences in the subsections.
GPS data are commonly collected and reported as points with a specific x and y coordinate (and possibly z). However, some GPS units have the option of recording and reporting positional data as a route. GPS routes can also be created if desired by linking GPS points. Travel time studies and pavement condition surveys are often reported as routes rather than discrete GPS points. GPS route data can be integrated with LRMs but pose different issues than for GPS point data.
Most route GPS data are collected using a differential GPS (DGPS) receiver that is mounted on a moving vehicle (typically a van). Since the vehicle is moving, much lower accuracies are possible than for GPS units that occupy a position and are capable of centimeter accuracy. Typical accuracies for DGPS are 3–10 meters. The accuracy influences how well data can be transferred between a GPS route and a LRM but is most significant in terms of the accuracy requirements of the particular application.
Another issue is linking GPS routes with a LRM. Linking a GPS point to a line (LRM) is fairly straightforward logistically. Linking a line (GPS route) to a line (LRM) is more difficult. The most significant problem is that the information related to the GPS route may be linear (as shown in Figure 20) and may required conflation to a LRM to transfer information. The problem then becomes one of dynamic segmentation.
A GPS route can be treated like a LRM. If protocols are in place in the Iowa DOT LRS for dynamic segmentation, data can be transferred from a GPS route to a LRM or among LRMs using this method.
Information may also be transferred by reducing GPS routes to point features, as shown in Figure 21. Breakpoints can be established that mark the “begin” and “end” points of homogenous segments. Breakpoints can be treated as GPS points for integration with a LRM with a spatial representation. Once points are linked to the LRM, the information (such as travel speed) can be linearly referenced in associated tables. Attributes of the GPS points, such as coordinates, can also be preserved.
A number of issues arise in linking spatial point features collected using a GPS or another method such as feature location using satellite or aerial images. The accuracy of the GPS or other data collection method itself affects whether the point will be mapped to the correct location and whether it will even map to the correct segment. Integrating point features with a LRM also results in loss of spatial information. The spatial accuracy of the cartography, spatial LRM, or spatial datum also affects linear offset calculations, lateral offset, and placement.
The following is a brief summary of recommendations for integrating GPS or other point features with a LRM:
1. Most points are logically stored in conjunction with a LRM. Additional spatial information should be retained in a data field, such as coordinates, elevation, and lateral offset.
2. When features are maintained as independent points, a methodology to link features on the fly to an LRM as necessary is required. Additionally, attributes that describe the corresponding LRM should be added so that features can be properly located if roadway alignment changes occur in the future.
3. The use of route identifiers provides a higher degree of success and assistance in ensuring that point features map to the correct roadway segment.
4. Locate point features along a LRM as a percentage rather than distance or use calibration to adjust for differences between different calculated lengths between LRM for the same segment.
5. To transfer point features between LRMs, first transfer point features from the original LRM to the datum and make necessary the appropriate adjustments as necessary.
6. If business data are to be stored that require a high degree of spatial accuracy, the creation of a more spatially accurate network should be considered.
7. Error may be cumulative; if a segment starts out 10 feet off from datum, that error will be propagated throughout. Consideration of this is important when transferring data.
8. Lateral offset should not be used unless accurate cartography or another method is available to measure offset and placement (40 feet north of the centerline, etc.). Otherwise, lateral offset becomes meaningless.
Awuah-Baffour, R., W. Bachman, X. Jia, S. Kimbrough, and W. Sarasau. Using a Dynamic GIS to Visualize and Analyze Mobile Source Emissions. Ninth Symposium on Geographic Information Systems for Transportation (GIS-T). Kansas City, Mo., 1997, pp. 80–91.
Britch, S.C., and G.M. Fitch. Opportunities for Collecting Highway Inventory Data With the Global Position System. Transportation Research Record 1593. Transportation Research Board, National Research Council, Washington, D.C., 1997, pp. 64–71.
Czerniak, R.J., and J.P. Reilly. Synthesis of Highway Practice 258: Applications of GPS for Surveying and Other Positioning Needs in Departments of Transportation. National Cooperative Highway Research Program, National Academy Press, Washington, D.C., 1998.
D’Este, G.M., R. Zito, and M.A.P. Taylor. Using GPS to Measure Traffic System Performance. Computer-Aided Civil and Infrastructure Engineering, Vol. 14, 1999, pp. 255–265.
GeoAnalytics. A Physical Design for the State of Iowa Department of Transportation’s Linear Referencing System: Physical Design Technical Document. GeoAnalytics, TransDecisions, and Oracle Corporation, June 2000.
GeoAnalytics. Field Pilot Results for the State of Iowa Department of Transportation Linear Referencing System. Prepared by GeoAnalytics, Dr. Alan Vonderohe, and the Iowa Department of Transportation, Dec. 2000.
GeoAnalytics et al. Field Pilot Results for the State of Iowa Department of Transportation’s Linear Referencing System. GeoAnalytics, TransDecisions, and Oracle Corporation, March 2001.
Goodwin, C.W.H., D. Siegel, S.R. Gordon, and D. Xiong. Recommendation for Location Referencing for ITS Needs. Prepared for the Office of Safety and Traffic Operation, Federal Highway Administration, McLean, Va., June 30, 1995.
Guo, B., and A.D. Poling. Geographic Information Systems/Global Positioning Systems Design for Network Travel Time Study. Transportation Research Record 1497. Transportation Research Board, National Research Council, Washington, D.C., 1995, pp. 135–139.
Miller, J.S., and D. Karr. Experimental Application of Global Positioning
System to Locate Motor Vehicle Crashes: Impact on Time and Accuracy. Transportation Research Record 1625. Transportation Research Board, National Research Council, Washington, D.C., 1998, pp. 41–49.
Murakami, E., and D. Wagner. Using Global Positioning Systems for Measuring Household Travel in Private Vehicles. Proceedings of the Geographic Information Systems for Transportation Symposium (GIS-T). Greensboro, N.C., Mar. 1997, pp. 38–48.
Noronha, V., M. Goodchild, R. Church, S. Kulkkarni, and S. Aydin. The LRMS Linear Referencing Profile: Technical Evaluation. Federal Highway Administration, U.S. Department of Transportation, Dec. 2000.
O’Neill, W., and E. Harper. Location Translation within a Geographic Information System. Transportation Research Record 1593. Transportation Research Board, National Research Council, Washington, D.C., 1997, pp. 55–63.
O’Neill, W., and E. Harper. Implementation of Linear Referencing Systems in GIS. In Urban Planning and Development Applications of GIS. Ed. S. Easa and Y. Chan. American Society of Civil Engineers, Reston, Va., 2000.
Poling, A., J. Lee, P. Gregerson, and P. Handly. Comparison of Two Sign Inventory Data Collection Techniques for Geographic Information Systems. Transportation Research Record 1429. Transportation Research Board, National Research Council, Washington, D.C., 1994, pp. 36–39.
Quiroga, C.A. and D. Bullock. Travel Time Information Using Global Positioning Systems and Dynamic Segmentation Techniques. Transportation Research Record 1660. Transportation Research Board, National Research Council, Washington, D.C., 1996, pp. 48–57.
Ries, T., and J. DuChateau. A Workshop on Implementing Road Data Models: Coordinate-based and Cross Streets Linear Referencing. GIS-T Symposium. Arlington, Va., April 8, 2001.
'This is the main program for GPS Tool
'It takes a point file of GPS locations and a route coverage
' and selects and linear references to the nearest route from
' the specified route coverage
'Created by: Shauna Hallmark
'Last modified: February 2001
'*******Selects the desired View and the desired theme in that view
'*******with the route and GPS points
t = "ChooseViewTheme"
pro = av.GetProject
'*******Gets a list of views for the user to select from
docList = pro.GetDocs
vList = List.Make
lineList = List.Make
for each x in docList
if(x.Is(View)) then
vList.Add(x)
end
end
v = MsgBox.List(vList,"Select a View:",t)
if (v = nil) then
MsgBox.Warning("No View Chosen: Ending Process",t)
exit
end
'********* Gets a list of themes for the user to choose from for
'********* selecting the route and gps theme
themeList = v.GetThemes
if(themeList.Count = 0) then
MsgBox.Error("N themes for this view:" ++ v.GetName,t)
exit
end
lineTheme = MsgBox.List(themeList,"Select the theme with the Route Segments:",t)
if(lineTheme = nil) then
MsgBox.Warning("No Theme Selected",t)
exit
end
gpsTheme = MsgBox.List(themeList,"Select the theme with the GPS Segments:",t)
if(gpsTheme = nil) then
MsgBox.Warning("No Theme Selected",t)
exit
end
'***********Gets the associated Ftables
if(lineTheme.Is(FTheme)) then
lineFtab = lineTheme.GetFtab
else
lineFtab = nil
end
if(gpsTheme.Is(FTheme)) then
gpsFtab = gpsTheme.GetFtab
else
gpsFtab = nil
end
'************** Creates a database file with the following fields
lengthfileAddFieldsList=List.Make
pointIdF=Field.Make("Point_ID",#FIELD_DECIMAL,10,0)
lengthfileAddFieldsList.Add(pointIdF)
pointLatF=Field.Make("PointLat",#FIELD_DECIMAL,10,4)
lengthfileAddFieldsList.Add(pointLatF)
pointLongF=Field.Make("PointLon",#FIELD_Decimal,10,4)
lengthfileAddFieldsList.Add(pointLongF)
routeIdF=Field.Make("Route_ID",#FIELD_Decimal,10,0)
lengthfileAddFieldsList.Add(routeIdF)
segmentDistF=Field.Make("Seg_Length",#FIELD_Decimal,10,4)
lengthfileAddFieldsList.Add(segmentDistF)
routeDistF=Field.Make("m_Length",#FIELD_Decimal,10,4)
lengthfileAddFieldsList.Add(routeDistF)
originalDistF=Field.Make("Org_Length",#FIELD_Decimal,10,4)
lengthfileAddFieldsList.Add(originalDistF)
offsetF=Field.Make("Offset",#FIELD_Decimal,10,4)
lengthfileAddFieldsList.Add(offsetF)
directionF=Field.Make("Direction",#FIELD_Char,10,4)
lengthfileAddFieldsList.Add(directionF)
lFileName=("GPSEvent.dbf").AsFileName
outTab=VTab.MakeNew(lFileName,dBase)
outTab.SetEditable(true)
outTab.StartEditingWithRecovery
outTab.AddFields(lengthfileAddFieldsList)
outTab.StopEditingWithRecovery(true)
outTab.SetEditable(false)
'**********searches thru and finds each record for the GPS theme and the
'**********corresponding nearest route from the join
gpsFtab.join(gpsFTab.FindField("Shape"),lineFtab,lineFTab.FindField("Shape"))
gps1 = gpsFTab.ReturnValue(gpsFtab.FindField("Shape"),1)
for each w in gpsFtab
gpsPoint=gpsFTab.ReturnValue(gpsFTab.FindField("Shape"),w)
gpsName = gpsFTab.ReturnValueString(gpsFtab.FindField("Id"),w)
gpsPointX=gpsPoint.GetX
gpsPointY=gpsPoint.GetY
storeTheIDString=gpsFtab.ReturnValueString(gpsFtab.FindField("Mslink"),w)
gpsPointNearestLineID=storeTheIDString.AsNumber
' MsgBox.Info("Name is:" ++ gpsPointX.AsString + ", Y is: " ++ gpsPointY.AsString,w.AsString)
'MsgBox.Info("Route ID is:" ++ gpsPointNearestLineID.AsString,w.AsString)
'******* selects the nearest route identified for the particular GPS point
for each r in lineFtab
storeIDString=lineFtab.ReturnValueString(lineFtab.FindField("Mslink"),r)
'MsgBox.Info("Route ID is:" ++ storeIDString.AsString,w.AsString)
routeID=storeIDString.AsNumber
if (routeID=gpsPointNearestLineID) then
segmentLine=lineFTab.ReturnValue(lineFTab.FindField("Shape"),r)
segmentPolyLine=segmentLine.AsPolyLine
theLength=segmentPolyline.ReturnLength
viewUnits=v.GetUnits
mileLength=Units.Convert(theLength,viewUnits,#UNITS_LINEAR_MILES)
footSegments=mileLength*5280
footSegments=5280
countInterval= 100/10563
'**************MsgBox.Info("The length is "++mileLength.AsString +"foot segments "++footSegments.AsString + "count interval "++countInterval.AsString,"Box")
'***************this loop walks along the segment and compares distances, may need to alter for longer or shorter segments
count = 0
shortDist = 100000
for each i in 1..10563
pointWalkingOnLine = segmentPolyLine.Along(Count)
fromPoint = segmentLine.AsLine.ReturnStart
pointDistance = pointWalkingOnLine.Distance(gpsPoint)
viewUnits = v.GetUnits
'pointDistanceInMiles = Units.Convert(pointDistance,viewUnits,#UNITS_LINEAR_MILES)
if (pointDistance < shortDist) then
'MsgBox.Info("Short is " ++shortDist.AsString +" point dist: " ++pointDistance.AsString,"Box")
shortDist = pointDistance
closestPoint = pointWalkingOnLine
percentWalked=count
end
'MsgBox.Info("Short Dist " ++shortDist.AsString +" Percent " ++percentWalked.AsString,"Box")
count = count + countInterval
end
end
end
'******** Opens the newly created table and starts adding records
fromNode=segmentLine.AsLine.ReturnStart
toNode=segmentLine.AsLine.ReturnEnd
from=closestPoint.Distance(fromNode)
to=closestPoint.Distance(toNode)
fromDist = Units.Convert(from,viewUnits,#UNITS_LINEAR_MILES)
toDist= Units.Convert(to,viewUnits,#UNITS_LINEAR_MILES)
xNode=closestPoint.GetX
yNode=closestPoint.GetY
lrsLength=percentWalked*theLength/100
if(lrsLength<fromDist) then
test1=fromDist-lrsLength
else
test1=lrsLength-fromDist
end
if(lrsLength<toDist) then
test2=toDist-lrsLength
else
test2=lrsLength-toDist
end
if(test2<test1) then
finalLRSLength=mileLength-lrsLength
else
finalLRSLength=lrsLength
end
'MsgBox.Info("LRS:" ++lrsLength.AsString +" SegLength: "++mileLength.AsString +" From: " ++fromDist.AsString +" To: " ++toDist.AsString,"R")
outTab.SetEditable(true)
outTab.StartEditingWithRecovery
direction = "East"
theRecord=outTab.AddRecord
outTab.SetValueNumber(outTab.FindField("Point_ID"),theRecord,gpsName.AsNumber) 'GPS point ID
outTab.SetValueNumber(outTab.FindField("PointLat"),theRecord,xNode) 'Lat of the point on the route segment
outTab.SetValueNumber(outTab.FindField("PointLon"),theRecord,yNode) 'Lon of the point on the route segment
outTab.SetValueNumber(outTab.FindField("Route_ID"),theRecord,gpsPointNearestLineID) 'ID of the route segment
outTab.SetValueNumber(outTab.FindField("Seg_Length"),theRecord,theLength) 'length of the segment
outTab.SetValueNumber(outTab.FindField("Org_Length"),theRecord,lrsLength) 'length of the point to where the GPS point matches the line
outTab.SetValueNumber(outTab.FindField("m_Length"),theRecord,finalLRSLength) 'length of the point to where the GPS point matches the line measured from the from point
outTab.SetValueNumber(outTab.FindField("Offset"),theRecord,shortDist) 'offset distance from the GPS point to the centerline
outTab.SetValueString(outTab.FindField("Direction"),theRecord,direction) 'Offset direction
outTab.StopEditingWithRecovery(true)
outTab.SetEditable(false)
end
'return{v,gpsTheme,gpsFtab}
'******** Need to do error checking to make sure that if a point is too far from a line, it flags it or displays a warning message
| Table B.1. Distance along Union Road Segment where Street Light Was Located for Datum vs. LRM |
|||
Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 133 |
379.7 |
339.7 |
40.0 |
| 132 |
950.8 |
911.6 |
39.2 |
| 131 |
1,100.9 |
1,059.7 |
41.2 |
| 130 |
1,242.2 |
1,200.5 |
41.7 |
| 129 |
1,673.4 |
1,631.6 |
41.8 |
| 128 |
1,819.1 |
1,770.9 |
48.2 |
| 127 |
1,967.7 |
1,921.9 |
45.8 |
| 126 |
2,123.7 |
2,074.3 |
49.4 |
| 125 |
2,287.1 |
2,236.9 |
50.2 |
| 124 |
2,429.9 |
2,405.3 |
24.6 |
| 123 |
2,624.1 |
2,602.7 |
21.5 |
| 122 |
2,771.3 |
2,758.0 |
13.3 |
| 121 |
2,921.4 |
2,914.8 |
6.7 |
| 119 |
3,224.6 |
3,208.0 |
16.6 |
| 118 |
3,398.3 |
3,363.3 |
35.0 |
| 117 |
3,676.5 |
3,655.1 |
21.4 |
| 116 |
3,822.2 |
3,804.6 |
17.6 |
| 115 |
3,967.9 |
3,951.2 |
16.7 |
| 114 |
4,090.0 |
4,073.1 |
16.9 |
| 113 |
5,102.6 |
5,053.0 |
49.6 |
| 112 |
5,165.9 |
5,112.5 |
53.4 |
| 111 |
5,317.5 |
5,264.9 |
52.6 |
| 110 |
5,452.9 |
5,399.9 |
53.0 |
| 109 |
5,622.1 |
5,558.1 |
64.0 |
| 108 |
5,753.1 |
5,668.4 |
84.7 |
| 107 |
5,892.9 |
5,802.0 |
90.9 |
| 106 |
6,043.0 |
5,955.8 |
87.2 |
| 105 |
6,197.6 |
6,109.7 |
87.9 |
| 104 |
6,327.1 |
6,238.9 |
88.2 |
| 103 |
6,614.1 |
6,527.8 |
86.3 |
| 102 |
6,905.5 |
6,819.5 |
86.0 |
| 101 |
7,194.0 |
7,109.8 |
84.1 |
| Table B.2. Distance along Todd Drive Segment where Street Light Was Located for Datum vs. LRM |
|||
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 34 |
398.6 |
345.7 |
52.89 |
| 35 |
574.5 |
521.9 |
52.65 |
| 36 |
791.3 |
746.9 |
44.40 |
| 37 |
1,005.1 |
963.3 |
41.86 |
| 38 |
1,241.4 |
1,190.2 |
51.14 |
| 39 |
1,414.4 |
1,362.6 |
51.82 |
| 40 |
1,597.2 |
1,546.4 |
50.72 |
| 41 |
1,635.1 |
1,583.8 |
51.29 |
| 42 |
1,715.8 |
1,664.2 |
51.54 |
| 43 |
1,772.1 |
1,720.7 |
51.43 |
| 44 |
2,091.0 |
2,043.4 |
47.58 |
| 45 |
2,580.9 |
2,564.3 |
16.62 |
| 46 |
2,424.4 |
2,404.4 |
20.02 |
| 47 |
2,264.0 |
2,251.2 |
12.83 |
| 48 |
2,756.9 |
2,696.4 |
60.43 |
| 49 |
2,887.1 |
2,826.7 |
60.46 |
| 50 |
3,068.9 |
3,005.7 |
63.18 |
| 51 |
3,193.3 |
3,130.2 |
63.13 |
| 52 |
3,393.6 |
3,333.2 |
60.39 |
| 53 |
3,555.9 |
3,497.9 |
58.03 |
| 54 |
3,901.0 |
3,843.6 |
57.45 |
| 55 |
4,089.6 |
4,031.3 |
58.36 |
| 56 |
4,502.8 |
4,443.0 |
59.76 |
| 57 |
4,697.2 |
4,637.4 |
59.79 |
| Table B.3. Distance along Airport Road Segment where Street Light Was Located for Datum vs. LRM |
|||
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 90 |
3.9 |
84.4 |
-80.4 |
| 91 |
249.7 |
330.8 |
-81.1 |
| 92 |
511.2 |
591.8 |
-80.5 |
| 93 |
791.0 |
871.2 |
-80.1 |
| 94 |
998.9 |
1,079.4 |
-80.5 |
| 95 |
1,493.2 |
1,573.7 |
-80.5 |
| 96 |
2,567.9 |
2,649.1 |
-81.2 |
| 97 |
2,629.4 |
2,711.1 |
-81.7 |
| 98 |
3,034.7 |
3,117.0 |
-82.3 |
| 99 |
3,185.1 |
3,267.3 |
-82.2 |
| 100 |
4,639.0 |
4,721.0 |
-82.0 |
| 101 |
5,210.4 |
5,302.3 |
-91.8 |
| 102 |
5,376.5 |
5,463.0 |
-86.6 |
| 103 |
5,517.7 |
5,600.1 |
-82.4 |
| 104 |
5,656.3 |
5,737.2 |
-80.9 |
| 105 |
5,798.8 |
5,875.6 |
-76.8 |
| 106 |
5,937.4 |
6,011.3 |
-73.9 |
| 107 |
6,076.0 |
6,149.7 |
-73.7 |
| 108 |
6,246.0 |
6,317.1 |
-71.1 |
| 109 |
6,372.8 |
6,443.6 |
-70.8 |
| 110 |
6,503.5 |
6,572.8 |
-69.3 |
| 111 |
6,634.3 |
6,703.3 |
-69.0 |
| 112 |
6,762.4 |
6,832.4 |
-70.0 |
| 114 |
6,874.9 |
6,944.5 |
-69.6 |
| 115 |
6,891.9 |
6,961.6 |
-69.7 |
| 116 |
7,021.3 |
7,093.4 |
-72.1 |
| 117 |
7,150.7 |
7,223.9 |
-73.1 |
| 118 |
7,278.9 |
7,357.0 |
-78.1 |
| 119 |
7,447.5 |
7,527.0 |
-79.5 |
| 120 |
7,588.8 |
7,662.8 |
-74.0 |
| 121 |
7,728.7 |
7,798.5 |
-69.9 |
| 122 |
7,868.6 |
7,939.5 |
-71.0 |
| 123 |
8,008.5 |
8,079.2 |
-70.8 |
| 124 |
8,148.4 |
8,219.0 |
-70.6 |
| 125 |
8,334.0 |
8,404.8 |
-70.8 |
| 126 |
9,356.5 |
9,426.2 |
-69.7 |
| 127 |
9,662.5 |
9,732.0 |
-69.5 |
| 128 |
10,165.8 |
10,236.8 |
-70.9 |
| 129 |
10,474.4 |
10,545.2 |
-70.8 |
| 130 |
12,464.4 |
12,535.4 |
-70.9 |
| 131 |
12,877.6 |
12,947.9 |
-70.3 |
| 132 |
13,241.1 |
13,311.6 |
-70.5 |
| 133 |
13,424.2 |
13,494.8 |
-70.7 |
| 134 |
13,721.0 |
13,794.0 |
-73.1 |
| 135 |
13,284.2 |
13,357.8 |
-73.5 |
| 136 |
13,166.6 |
13,240.5 |
-73.9 |
| 137 |
9,458.5 |
9,530.3 |
-71.9 |
| 138 |
9,242.8 |
9,314.2 |
-71.4 |
| 139 |
7,348.2 |
7,425.5 |
-77.3 |
| 140 |
6,157.0 |
6,231.4 |
-74.4 |
| 141 |
6,040.7 |
6,116.8 |
-76.1 |
| 142 |
4,422.0 |
4,504.9 |
-82.9 |
| 143 |
3,893.7 |
3,977.7 |
-83.9 |
| 144 |
3,241.3 |
3,324.0 |
-82.7 |
| Table B.4. Distance along L Avenue Segment where Street Light Was Located for Datum vs. LRM |
|||
Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 291 |
182.5 |
219.9 |
-37.4 |
| 293 |
339.0 |
376.5 |
-37.5 |
| 294 |
633.2 |
671.0 |
-37.8 |
| 295 |
516.5 |
554.2 |
-37.7 |
| 296 |
961.0 |
996.6 |
-35.6 |
| 297 |
1,399.3 |
1,435.2 |
-35.9 |
| 298 |
1,403.1 |
1,440.2 |
-37.1 |
| 299 |
1,576.9 |
1,612.9 |
-36.0 |
| 300 |
1,766.9 |
1,804.3 |
-37.4 |
| 301 |
1,920.8 |
1,957.1 |
-36.3 |
| 302 |
2,135.6 |
2,173.4 |
-37.7 |
| 303 |
2,333.1 |
2,369.7 |
-36.6 |
| 304 |
2,525.5 |
2,563.5 |
-38.0 |
| 305 |
2,690.6 |
2,725.1 |
-34.4 |
| 306 |
2,760.2 |
2,795.9 |
-35.7 |
| 307 |
2,893.0 |
2,930.1 |
-37.1 |
| 308 |
3,066.9 |
3,101.6 |
-34.7 |
| 309 |
3,255.6 |
3,291.7 |
-36.1 |
| 310 |
3,620.6 |
3,658.3 |
-37.7 |
| 311 |
4,132.2 |
4,167.8 |
-35.6 |
| 312 |
4,366.9 |
4,403.9 |
-37.0 |
| 314 |
5,123.0 |
5,159.4 |
-36.4 |
| 315 |
5,349.0 |
5,385.6 |
-36.6 |
| 316 |
5,443.4 |
5,478.8 |
-35.4 |
| 317 |
5,577.5 |
5,613.0 |
-35.5 |
| 318 |
5,815.9 |
5,851.6 |
-35.7 |
| 319 |
5,721.5 |
5,757.1 |
-35.6 |
| 320 |
5,978.5 |
6,014.3 |
-35.8 |
| 321 |
6,153.6 |
6,189.5 |
-35.9 |
| Table B.5. Distance along K Avenue Segment where Street Light Was Located for Datum vs. LRM |
|||
| Point ID |
Datum Linear Offset (feet) |
LRM Linear Offset (feet) |
Error: Datum Minus LRM (feet) |
| 23 |
161.1 |
177.5 |
-16.6 |
| 24 |
455.3 |
471.2 |
-16.6 |
| 25 |
660.0 |
675.7 |
-16.6 |
| 26 |
759.8 |
777.4 |
-18.7 |
| 27 |
1,013.4 |
1,029.7 |
-17.7 |
| 28 |
1,130.9 |
1,149.0 |
-19.7 |
| 29 |
1,453.1 |
1,469.8 |
-18.7 |
| 30 |
1,436.5 |
1,453.2 |
-18.7 |
| 31 |
1,584.1 |
1,600.6 |
-18.7 |
| 32 |
1,513.4 |
1,530.0 |
-18.7 |
| 33 |
1,805.5 |
1,822.7 |
-19.7 |
| 34 |
1,871.0 |
1,887.0 |
-18.7 |
| 35 |
1,807.6 |
1,824.8 |
-19.7 |
| 36 |
1,925.0 |
1,942.0 |
-19.7 |
| 37 |
2,050.8 |
2,066.6 |
-18.7 |
| 38 |
2,242.0 |
2,259.7 |
-20.8 |
| 39 |
2,415.6 |
2,432.0 |
-19.7 |
| 40 |
2,561.1 |
2,577.3 |
-19.7 |
| 41 |
2,939.5 |
2,956.2 |
-20.8 |
| 42 |
3,796.0 |
3,812.5 |
-21.8 |
| 43 |
4,510.1 |
4,526.6 |
-22.9 |
| 44 |
4,835.4 |
4,850.5 |
-21.8 |
| 45 |
5,162.8 |
5,176.4 |
-20.8 |
| ID |
Lateral Offset to Datum (feet) |
Lateral Offset to LRM (feet) |
Error: Datum Minus LRM (feet) |
| 90 |
44.2 |
87.2 |
-43.0 |
| 91 |
41.6 |
83.0 |
-41.4 |
| 92 |
39.7 |
82.6 |
-43.0 |
| 93 |
36.4 |
79.1 |
-42.7 |
| 94 |
37.1 |
79.4 |
-42.4 |
| 95 |
33.1 |
73.5 |
-40.5 |
| 96 |
40.6 |
56.8 |
-16.2 |
| 97 |
40.0 |
57.4 |
-17.4 |
| 98 |
34.1 |
55.3 |
-21.1 |
| 99 |
33.1 |
55.8 |
-22.7 |
| 100 |
33.8 |
70.4 |
-36.7 |
| 101 |
36.9 |
77.7 |
-40.7 |
| 102 |
6.6 |
31.4 |
-24.8 |
| 103 |
1.3 |
22.4 |
-21.1 |
| 104 |
1.4 |
19.6 |
-18.2 |
| 105 |
0.5 |
14.0 |
-13.5 |
| 106 |
2.3 |
8.8 |
-6.5 |
| 107 |
4.6 |
7.5 |
-2.9 |
| 108 |
3.7 |
15.1 |
-11.4 |
| 109 |
3.2 |
12.6 |
-9.4 |
| 110 |
1.1 |
15.1 |
-14.0 |
| 111 |
0.6 |
16.1 |
-15.5 |
| 112 |
0.6 |
17.9 |
-17.3 |
| 114 |
40.7 |
59.4 |
-18.7 |
| 115 |
0.5 |
18.8 |
-18.3 |
| 116 |
0.6 |
16.2 |
-15.6 |
| 117 |
1.0 |
16.8 |
-15.8 |
| 118 |
6.7 |
10.4 |
-3.7 |
| 119 |
0.7 |
1.6 |
-0.9 |
| 120 |
0.5 |
38.6 |
-38.0 |
| 121 |
0.7 |
59.2 |
-58.5 |
| 122 |
0.8 |
61.7 |
-60.9 |
| 123 |
0.4 |
61.2 |
-60.8 |
| 124 |
0.5 |
60.7 |
-60.3 |
| 125 |
0.2 |
60.3 |
-60.1 |
| 126 |
54.5 |
0.5 |
54.0 |
| 127 |
50.4 |
0.5 |
49.9 |
| 128 |
46.5 |
1.9 |
44.6 |
| 129 |
49.5 |
0.6 |
48.9 |
| 130 |
40.4 |
5.5 |
34.9 |
| 131 |
46.2 |
8.8 |
37.3 |
| 132 |
46.6 |
16.8 |
29.8 |
| 133 |
66.7 |
41.0 |
25.7 |
| 134 |
58.0 |
75.6 |
-17.6 |
| 135 |
66.0 |
95.0 |
-29.0 |
| 136 |
77.4 |
108.7 |
-31.3 |
| 137 |
54.7 |
108.3 |
-53.5 |
| 138 |
52.7 |
109.2 |
-56.5 |
| 139 |
57.7 |
46.3 |
11.4 |
| 140 |
73.1 |
57.2 |
15.8 |
| 141 |
41.3 |
31.4 |
10.0 |
| 142 |
18.4 |
16.0 |
2.4 |
| 143 |
39.9 |
10.0 |
29.9 |
| 144 |
44.4 |
21.0 |
23.3 |
| ID |
Lateral Offset to Datum (feet) |
Lateral Offset to LRM (feet) |
Error: Datum Minus LRM (feet) |
| 378 |
16.8 |
0.8 |
17.6 |
| 379 |
17.8 |
1.8 |
16.0 |
| 380 |
18.2 |
7.0 |
11.2 |
| 381 |
16.4 |
5.2 |
11.2 |
| 382 |
18.0 |
0.8 |
17.2 |
| 383 |
17.8 |
1.4 |
19.2 |
| 384 |
26.5 |
46.0 |
-19.5 |
| 385 |
15.4 |
4.2 |
19.6 |
| 386 |
33.4 |
51.1 |
-17.6 |
| 387 |
33.3 |
14.9 |
18.4 |
| 388 |
32.2 |
13.8 |
18.4 |
| 389 |
28.2 |
11.3 |
16.9 |
| 390 |
42.4 |
60.8 |
-18.4 |
| 391 |
28.3 |
12.5 |
15.9 |
| 392 |
29.4 |
15.9 |
13.6 |
| 393 |
26.6 |
15.3 |
11.3 |
| 394 |
17.8 |
6.2 |
11.6 |
| 395 |
13.9 |
1.8 |
12.1 |
| 396 |
20.8 |
29.3 |
-8.5 |
| 399 |
17.5 |
29.3 |
-11.8 |
| 400 |
23.0 |
16.4 |
6.6 |
| 401 |
16.2 |
24.8 |
-8.6 |
| 402 |
18.5 |
8.9 |
9.6 |
ID |
Lateral Offset to Datum (feet) |
Lateral Offset to LRM (feet) |
Error: Datum Minus LRM (feet) |
| 101 |
24.2 |
10.0 |
14.2 |
| 102 |
25.7 |
8.2 |
17.6 |
| 103 |
25.7 |
5.6 |
20.1 |
| 104 |
23.4 |
42.4 |
19.0 |
| 105 |
29.2 |
10.7 |
18.5 |
| 106 |
24.9 |
24.3 |
0.6 |
| 107 |
24.9 |
25.4 |
0.5 |
| 108 |
27.7 |
26.7 |
1.0 |
| 109 |
25.5 |
25.4 |
0.1 |
| 110 |
24.0 |
25.1 |
1.2 |
| 111 |
24.1 |
20.2 |
3.9 |
| 112 |
34.4 |
38.3 |
3.8 |
| 113 |
26.8 |
22.3 |
4.5 |
| 114 |
21.9 |
31.6 |
9.7 |
| 115 |
21.0 |
8.8 |
12.2 |
| 116 |
32.8 |
42.7 |
9.9 |
| 117 |
31.9 |
27.8 |
4.0 |
| 118 |
23.9 |
21.4 |
2.6 |
| 119 |
23.4 |
15.6 |
7.8 |
| 120 |
30.3 |
33.3 |
3.1 |
| 121 |
33.8 |
40.9 |
7.1 |
| 122 |
27.6 |
9.0 |
36.5 |
| 123 |
20.3 |
58.0 |
37.7 |
| 124 |
26.0 |
11.2 |
37.2 |
| 125 |
29.4 |
8.2 |
37.6 |
| 126 |
21.0 |
57.7 |
36.7 |
| 127 |
24.8 |
11.5 |
36.3 |
| 128 |
26.1 |
12.2 |
38.3 |
| 129 |
26.6 |
11.3 |
37.9 |
| ID |
Lateral Offset to Datum (feet) |
Lateral Offset to LRM (feet) |
Error: Datum Minus LRM (feet) |
| 34 |
18.2 |
15.1 |
3.1 |
| 35 |
29.2 |
26.3 |
2.9 |
| 36 |
19.2 |
6.9 |
26.1 |
| 37 |
17.4 |
41.9 |
-24.6 |
| 38 |
20.9 |
24.9 |
-4.0 |
| 39 |
18.9 |
17.1 |
1.8 |
| 40 |
18.6 |
24.0 |
-5.5 |
| 41 |
19.1 |
13.3 |
5.8 |
| 42 |
21.7 |
15.0 |
6.7 |
| 43 |
19.8 |
12.2 |
7.6 |
| 44 |
24.2 |
20.7 |
3.5 |
| 45 |
24.6 |
30.0 |
-5.4 |
| 46 |
23.8 |
20.6 |
3.2 |
| 47 |
18.8 |
32.4 |
-13.6 |
| 48 |
17.3 |
26.3 |
-9.0 |
| 49 |
18.0 |
22.1 |
-4.1 |
| 50 |
18.6 |
27.7 |
-9.1 |
| 51 |
19.8 |
34.9 |
-15.1 |
| 52 |
18.0 |
26.8 |
-8.8 |
| 53 |
23.6 |
18.8 |
4.8 |
| 54 |
17.8 |
27.1 |
-9.2 |
| 55 |
19.3 |
24.2 |
-4.9 |
| 56 |
21.0 |
25.9 |
-4.9 |
| 57 |
29.7 |
23.9 |
5.8 |
| ID |
Lateral Offset to Datum (feet) |
Lateral Offset to Datum (feet) |
Error: Datum Minus LRM (feet) |
| 223 |
23.0 |
24.4 |
-1.5 |
| 224 |
17.0 |
35.9 |
-18.9 |
| 2225 |
17.5 |
29.9 |
-12.4 |
| 226 |
17.2 |
23.3 |
-6.1 |
| 227 |
16.9 |
22.6 |
-5.7 |
| 228 |
16.5 |
56.0 |
-39.4 |
| 229 |
16.1 |
13.8 |
2.3 |
| 230 |
18.3 |
50.3 |
-32.0 |
| 231 |
17.1 |
11.2 |
5.9 |
| 232 |
21.8 |
47.3 |
-25.5 |
| 233 |
17.1 |
0.6 |
16.6 |
| 234 |
17.9 |
6.0 |
11.9 |
| 235 |
21.1 |
35.1 |
-14.0 |
| 236 |
19.2 |
34.9 |
-15.8 |
| 237 |
26.5 |
9.4 |
17.0 |
| 238 |
22.4 |
5.4 |
17.0 |
| 239 |
22.2 |
40.2 |
-17.9 |
| 240 |
18.2 |
36.8 |
-18.6 |
| 241 |
18.5 |
37.6 |
-19.1 |
| 242 |
17.6 |
37.1 |
-19.4 |
| 243 |
20.6 |
7.1 |
13.5 |
| 244 |
18.2 |
34.3 |
-16.1 |
| 245 |
26.6 |
13.9 |
12.8 |