Nevada Department of Transportation’s Multi-Level Linear Referencing System and Event GeoLocator Application
September 25, 2009
Summary of the Federal Highway Administration’s Quarterly Webinar: Applications of Geospatial Technologies in Transportation
These notes provide a summary of the PowerPoint presentation discussed during the webinar and detail the question-and-answer session that followed the presentation. The presentation is available upon request from the webinar speakers, Lawrie Black (LBlack@dot.state.nv.us) and Grahame Ross (GRoss@dot.state.nv.us).
Senior GIS Analyst
Approximately 40 participants attended the webinar.
Introduction to Presentation
Mark Sarmiento of the Federal Highway Administration's (FHWA) Office of Interstate and Border Planning thanked participants for joining the webinar. This webinar was the fourth in a quarterly series of webinars that have been sponsored by the FHWA Office of Interstate and Border Planning. The series deals with the application of geospatial information systems (GIS) and other geospatial technologies to transportation. This webinar focused on the development of the Nevada Department of Transportation's (NDOT) GeoTrans multi-level linear referencing system (MLRS) and Event GeoLocator (EGL) application.
GeoTrans MLRS Introduction
Since 2003, the NDOT Safety Engineering Division's Safety Management System has incorporated crash and accident data compiled by most of Nevada's police departments. The SMS now includes the locations of approximately 65,000 crashes dating from 1994 to 2008.
A key component of the SMS is the GeoTrans MLRS data model. The model absorbs street centerline files and converts geometric and tabular data into datum information. The datum information preserves both the linear references of crash locations and their geometry over time, allowing for temporal event location stability. GeoTrans allows location of events (crashes) in the same relative location, even if the underlying road geometry has changed.
GeoTrans Business Drivers
There were several business drivers for selecting the GeoTrans MLRS, including improving safety and improving the Safety Engineering Division's ability to proactively respond to data requests. For example, using crash data from GeoTrans, the Division's engineers can more easily analyze crashes along the entire road network to identify and rank locations of high risk for crashes. In the past, engineers might have responded to analysis inquiries by focusing only on the roadways needing review.
GeoTrans Datum Concept
The datum concept is the GeoTrans system's 'anchor' as it allows information from various sources to be edited, updated, or replaced. The datum (e.g., road mileage) remains fixed in the same relative location but can be referenced by multiple linear referencing methods (LRMs), including through the state and county road networks. Datum are never added or retired, but geometries can be recalibrated and the network will be updated accordingly.
Cross-reference tables contain unique identifying information for each datum and LRM. The tables allow datums to be translated into the LRM and also allow translation of geometry into LRM. Thus, the GeoTrans MLRS is based on a flexible system that allows information to be geo-coded in multiple ways. Several tools, including Intergraph's GeoMedia Professional, GeoMedia Fusion, GeoMedia Transportation Manager, and GeoMedia Transaction Manager, are used to capture the temporal history of information.
GeoTrans Work Flows and Production Schedule
There are several workflows to update and replace data. Also, a Route Network Technical Group (RNTG) was established to discuss and mitigate issues between divisions relating to the representations of both networks, such as naming conventions and ownerships.
Currently, the production schedule calls for a statewide data update every two years. However, due to staffing constraints and NDOT's current focus on updating county-level data, the two-year updating cycle has not yet been completed. Updates are scheduled depending on the extent of the county's road miles and maturity of its GIS. For example, counties with many road miles and mature GIS, such as Clark and Washoe Counties, are updated on a quarterly or biannual basis. Counties with fewer road miles, such as Carson City or Douglas, are scheduled for yearly updates.
The production dataset includes LRMs (county and state cumulative datasets and milepost index) and current intersection markers and features. For crash locations, NDOT can locate crashes many ways (e.g., by intersection and offset, mileposts, and, less frequently, by address). Engineers use located crash data aggregated to intersection objects to find high-crash locations.
Use of MLRS has led to a number of benefits, including:
- Collection of better quality crash data and improved dissemination to state agencies and safety analysts.
- Reduction of data entry errors and improvement of data entry speed.
- Ability to provide standard reports to outside groups and better tools for ad hoc analysis.
- Ability to more easily meet federal reporting requirements and decrease the time it takes to generate the Highway Safety Improvement Program report.
In the future, NDOT would like to expand the use of its MLRS road networks for other state and local agencies. Ideally, with more participation, the networks could be maintained and validated by local agencies through a web-based interface.
Back to top
The purpose of the EGL is to maintain a current and accurate database of all crashes that occur on Nevada's public roads in order to help better analyze and display crash data.
EGL draws from the Nevada Statewide Crash Database (NCATS) and disaggregates law enforcement descriptions of accident locations. Location descriptions are first classified, then parsed (e.g., street names) and re-built according to standardized conventions, and are then matched and located according to NDOT's linear referencing methods. EGL also takes advantage of Google's street name database.
Prior to EGL, crash locations were manually geolocated. Law enforcement agencies reported crashes into a centralized, electronic database, which the Nevada Department of Public Safety maintained. NDOT's Safety Engineering Division reviewed the database and then manually entered crashes into a GIS using the narratives included in law enforcement's reports.
EGL removes the need for manual geolocation of crash events. Currently, 297,000 crashes are included in NCATS and 271,000 of these crash events have been accurately geolocated by EGL. A small percentage of crashes are considered "not locatable" due to initial poor report description. These crashes require manual placement on a map.
Some of the benefits of EGL include its ability to:
- Locate a higher percentage of crashes (currently at 91% accuracy) than was previously attained by manual geolocation.
- Locate crashes in batch or singular mode.
- Use standard database technology.
- Include a web-based client that provides query and location process management.
- Match and locate crashes according to specific NDOT naming and address conventions.
EGL consists of three components:
The classifier tool interrogates the crash data to determine the most likely reference method used to locate the crash. Currently supported methods include milepost offset, intersection offset, ramp crash, and address. Others can be easily added.
- Parse and Scrub
The parse tool corrects errors and removes inconsistencies (e.g., spelling errors). The tool then 'scrubs' the data to remove unwanted information and replaces nonstandard terms with standard values.
- Matching and Geolocation
The matching tool matches pairs of crash route names to pairs of map route names. The geolocation tool then takes the matched crash data and accurately computes the event's linear reference coordinates along the roadway. This tool takes into consideration many anomalies that can exist in the road network including duplicate intersections, name changes, feet/miles errors, compass vs. cardinal direction errors, and others.
EGL Next Steps
An improved version of EGL will be coming online in early October. The updated version will allow NDOT better management of already located crashes (ALCs) so that ALCs are not batch-processed with new data.
Back to top
Questions and Answer Session
Do you support multiple geometries for each roadway feature, like for multiple scales or to reflect changes over time?
Yes. For example, the county might have one representation of a roadway feature. We will tie this to the northbound cardinal direction side or we would tie both north and south counties to the one representation that NDOT has.
Are you storing the datum in Oracle Spatial or ArcSDE?
We are storing the datum in Oracle.
Where is other NDOT data, like the Highway Performance Management System (HPMS) and work program? Are they also in the LRM system?
We are currently working on this to better integrate the system to enable geospatially based HPMS submittals. However, not all NDOT data is currently in LRM format.
With your increased accuracy, have you been able to fix key certain intersections/roads?
This would have to go through the Safety Engineering's problem area mitigation process. However, using EGL, NDOT can more easily locate intersections where crashes frequently occur and more quickly focus in on them using EGL's output as input for GIS analysis. Many points on the map are actually 'stacked' and show multiple crashes at one geographical point.
How do you integrate the crash data with highway inventory, pavement condition, traffic monitoring, and other data necessary for a complete safety analysis? Is there a GIS-based conflation process to do that work?
In Nevada, we need to have an office devoted to transportation data management. This office does not yet exist in the state. Currently, NDOT's divisions are fairly independent and work with different data sets and GIS vendors. GeoMedia has effective tools to integrate shapefiles and other types of data. Using GeoMedia, we can do analysis and maintain different datasets from different divisions. NDOT is now starting an important Department-wide asset management project. Within the next year, we are planning to build a safety data warehouse to store GIS and Oracle datasets. EGL can actually be modified to geolocate different types of events and not just crash data. NDOT Safety also operates a web-based crash mapping and analysis site for non-GIS experts called Web-CARE (based on the University of Alabama's CARE database management application). NDOT is willing to share these applications with transportation agencies and beta testers are welcome. Those interested can contact us at email@example.com.
Back to top
To conclude the webinar, Mr. Sarmiento presented some other information and resources related to applications of GIS in transportation:
- The GIS Tools for Strategic Conservation Planning course took place in Shepardstown, WV, on October 27-30, 2009.
- The 2009 GIS in Transit Conference will occurred November 16-18 in St. Petersburg, Florida. More information about the conference is available at www.urisa.org/education-events/gis-in-transit-conference/
- FHWA has developed a new quarterly GIS in Transportation newsletter to share information about significant geospatial transportation news, events, and applications. Newsletters are available at https://www.gis.fhwa.dot.gov/newsletters.aspx
- FHWA's GIS in Transportation website highlights innovative uses of GIS for transportation and offers related information, opportunities, and resources for sharing uses and applications of GIS. The website is available at https://www.gis.fhwa.dot.gov
- The next webinar in the FHWA-sponsored GIS in Transportation webinar series will occur in approximately three months. Details for the future event and other upcoming webinars will be publicized on the GIS-T yahoo group distribution list, in emails to state DOT GIS managers, and on FHWA's GIS in Transportation website.
Back to top