All Road Network of Linear Referenced Data (ARNOLD) Peer Exchange

Kansas City, Kansas
June 14-15, 2016

Host Agency
Kansas Department of Transportation

Participating Peer Agencies
California Department of Transportation
Florida Department of Transportation
Indiana Department of Transportation
Minnesota Department of Transportation
Pennsylvania Department of Transportation
Utah Department of Transportation

TABLE OF CONTENTS

• Acknowledgments
• Introduction
  • Purpose
  • Background
  • Format
  • Overview of Peer Examples
• Peer Exchange Discussion Highlights
  • A. Updating GIS Applications to Address ARNOLD Standards
  • B. Local Roads and Data Collection
  • C. Standardizing and Unifying Roadway Characteristics and Categorizations
  • D. NG911 Integration and Collaboration
  • E. Education and Training Needs - Present and Future
• Conclusions
• Appendix
  • Participants
  • Agenda
  • Roundtable Discussion Questions

ACKNOWLEDGMENTS

The U.S. Department of Transportation John A. Volpe National Transportation Systems Center (Volpe Center) in Cambridge, Massachusetts, prepared this report for the Federal Highway Administration’s (FHWA) Office of Planning. The Volpe Center project team wishes to thank the participants in the peer exchange, which are listed in Appendix A, for providing their experiences, insights, and editorial review. The time they kindly provided was vital to preparing the exchange and reviewing this final report.

INTRODUCTION

Purpose

This report provides highlights from a peer exchange held in Kansas City, Kansas, on June 14-15, 2016. The exchange was held as part of the Federal Highway Administration’s (FHWA) Geographic Information Systems (GIS) in Transportation program¹ and hosted by Kansas Department of Transportation (KDOT). It focused on a discussion of uses of geospatial/GIS tools and applications in relation to the All Road Network of Linear Referenced Data (ARNOLD).

Background

As GIS technology continued to advance and as adoption became more widespread, demand for standards and efficiency grew. In 2012, a report from the Government Accountability Office (GAO) critiqued how government offices were handling geospatial data.² One of the findings of the report was that there were several Departments of Transportation (DOTs) developing methods of data collection and storage, but that these agencies did not have uniform ways of doing so. The report also found that there were duplicative data collection efforts that could be made more efficient if there were a greater level of collaboration and information sharing between agencies.

Building on the GAO report’s findings and new direction from the passage of the Moving Ahead for Progress in the 21^st Century Act (MAP-21), FHWA announced a series of data standardization initiatives in 2012. Specifically, MAP-21 expanded the data reporting requirements for State DOTs by requiring the development of the Highway Performance Monitoring System (HPMS), a national-level highway information system that includes data on the extent, condition, performance, use, and operating characteristics of the Nation’s highways. The new requirements for HPMS, which took effect in 2014, required each State DOT to expand their linear referencing systems (LRS), a statewide geospatial representation of their road system that includes all public roads. This nationwide representation of the road network is known as the All Road Network of Linear Referenced Data (ARNOLD). Before ARNOLD was instituted, FHWA only required that HPMS submission include data on Federal-Aid Highways³ networks.

From its beginning, the goal of ARNOLD has been to develop one standardized, nationwide, and authoritative LRS-based road network. While every State had worked with LRS and GIS extensively in the field of transportation, before 2012 there was no standard for the LRS process, GIS data, or business rules to ensure regular maintenance. Instead, each State DOT maintained a local, internal set of LRS rules, typically only applied to their respective road network. Because the process of adopting a new LRS or expanding on a current one could be onerous, FHWA gave States one to two years before the HPMS expansion took effect. Recognizing that the update can also be resource-intensive, in 2015 FHWA launched a Pooled Fund Study for State DOTs that were challenged by the expanded data-collection effort.

Currently, States submit HPMS data—including the required data submitted for ARNOLD—annually. As State DOTs continue to develop their LRS, FHWA aims to create a more streamlined process for HPMS submissions. Instead of a one-time submission process, the agency believes a transactional system would be a more efficient process for submitting data. Within this type of system, a State DOT would be able to either continually provide updates or only provide year-on-year changes instead of uploading an entire system. Additionally, this type of system can provide a robust validation engine as well.

Format

FHWA’s Office of Planning (HOP) sponsored the peer exchange with support from FHWA’s Office of Highway Policy Information (OHPI). The Kansas Department of Transportation (KDOT) hosted the event in Kansas City, Kansas. Participants included staff from KDOT as well as the California Department of Transportation (Caltrans), Florida Department of Transportation (FDOT), Indiana Department of Transportation (INDOT), Minnesota Department of Transportation (MnDOT), Pennsylvania Department of Transportation (PennDOT), and the Utah Department of Transportation (UDOT). See Appendix A for a complete participant list.

FHWA opened the peer exchange by presenting an overview of the FHWA GIS in Transportation program, a summary of the All Roads Network of Linear Referenced Data (ARNOLD), and FHWA’s involvement with the program. The introductory session was followed by peer presentations including an overview of each State’s experiences with ARNOLD. Peers also participated in a series of roundtable discussions throughout the exchange that addressed pre-identified topics of interest to both FHWA and the peers. The exchange concluded with a discussion of next steps and final remarks from FHWA that summarized recurring themes. See Appendix A for the peer exchange agenda, including roundtable discussion topics.

Overview of Peer Examples

The examples presented in the peer exchange focused on the use of geospatial/GIS tools and applications to support a range of LRS management approaches, in particular migrating or converting to a new system, local roads, roadway characteristics and categorizations, and education and training. Given the complexity of public roads systems and limited dedicated resources, peers reported that they are still at different stages of fully adopting ARNOLD standards. However, peers anticipated that they could build upon existing initiatives and efforts to refine, tailor, or adapt current GIS tools for ARNOLD goals over the next few years. Table 1 below provides an overview of the examples highlighted during the peer exchange.

Table 1. Overview of Examples

Back to Top

PEER EXCHANGE DISCUSSION HIGHLIGHTS

Discussions held during the exchange centered around five topics:

1. Migrating or Converting to a New System or LRS Approach;
2. Local Roads;
3. Roadway Characteristics and Categorizations;
4. 911 Integration and Collaboration; and
5. Education and Training Needs in the present and future.

More detail on each of these topics is provided below.

A. Updating GIS Applications to Address ARNOLD Standards

Peers reported that their agencies use geospatial/GIS tools and applications to submit their HPMS data to FHWA. Over time, many State DOTs have had to update their current GIS application in order to more easily meet HPMS standards. In other cases, many State DOTs have completely revamped their GIS solution, adopting new tools and applications. Peers highlighted experiences in staffing requirements, acquiring software, levels of detail in different GIS applications, and working with different regions to collect data.

• Peer Example: As INDOT had already inventoried all public roads, the agency’s process for meeting the ARNOLD requirement was generally less challenging than other States. Using Exor, by 2006, INDOT had a working data model and Roadway Inventory that was fully functional. Thanks to this model, the State DOT was able to annually export its entire road network from a single source. The HPMS submissions were completed by INDOT using ArcGIS tools. However, INDOT still faced issues with standardized measurements. When asked how many road lane miles INDOT maintained, for example, up to three separate and significantly different values could be calculated. This difference appeared to be a result of using different standards for defining roadway types, using different inventory lists, and other discrepancies.

  In order to create standardization, keep up with technological trends, continue to meet FWHA requirements, and provide a single source for data maintenance, INDOT decided to migrate from Exor to Esri’s Roads and Highways solution. INDOT chose Esri as its vendor based on a non-biased scoring mechanism. Prior to the receipt of RFP responses, the committee weighted each requirement major subject area by its expected impact on Agency and Division goals. Similarly, the committee assigned weighting to certain requirements or groups of requirements. INDOT used a quantity purchase award, which added flexibility, allowed staff to request software as needed, and allowed for a multi-year agreement on the software, migration, and maintenance, all of which saved the agency on average about $70,000 annually over its previous solution (as reported by INDOT). The process of choosing a vendor and finalizing an agreement lasted 11 months.

  When migrating to its new system, INDOT chose a phased approach. While the target time of completion was 12 months, the inventory process lasted for 14 months. The INDOT staff dedicated to the migration included an estimated two database administrators, two management information systems staff, and various additional Esri staff. After inventory, INDOT set a target of 6 months to fully integrate the new data. Currently, the process is still ongoing. In order to stay on schedule or meet project deadlines, INDOT had to be flexible with respect to the data and overall design of the integration. Within INDOT’s new system, the transferred assets were situated in the same location on the map. After implementation, INDOT performed limited random sampling on its assets to test the accuracy of the transfers, which passed its internal threshold for success.

• Peer Example: Before the implementation of ARNOLD, PennDOT had already begun to update its LRS in order to inventory structurally-deficient bridges on local roads (where many of these bridges are located) and link them to the network. During the update, PennDOT kept the same GIS application, which is an in-house legacy mainframe system. PennDOT has taken a slightly different approach, however, than other peers with respect to how the network was updated. PennDOT decided to classify roads as Liquid Fuels Roads and Non-Liquid Fuels Roads, the former of which receive gas tax funding from the State. The State DOT inventoried and maintained these roads using its dotGrants application, which is a non-spatial Oracle database for submitting and managing grant applications and grants. Starting in 2012, PennDOT began linking Liquid Fuels Roads using Hexagon’s GeoMedia software and PennDOT’s Type 5 municipal maps as a reference.

  When PennDOT began the LRS update, there were 10 to 15 PennDOT staff at any given time within the GIS Division. In 2013, PennDOT received FHWA funding for 6 summer interns, which helped speed up the process. By 2014, all 444,000 segments of the Liquid Fuels Roads were linked to the spatial oracle database. With the team of summer interns and permanent staff, about 66,000 errors such as overshoots, undershoots, and incorrect digitization directions (see Figures 1 and 2) were identified throughout the State and eventually fixed through a quality analysis and quality control (QA/QC) process.

  

  Figure 1. PennDOT Snapping Integrity Between Feature

  

  Figure 2. PennDOT Digitization Direction Check

  Recently, PennDOT has coordinated with other planning partners to collect asset attribute information as part of an ArcGIS Mobile Local Road and Bridge data inventory project. The linking and QA/QC portion of the project will take place as part of PennDOT’s partnership with FHWA in the Pooled Fund Study.

• Peer Example: FDOT participated in the FHWA Pooled Fund Study to ensure it could better meet the ARNOLD requirement. Currently, FDOT’s LRS is maintained daily via coordination with FDOT District offices using custom software built on Esri technology and an Oracle database. Using the Pooled Fund Study funds, FDOT has been able to hire a full-time employee to focus solely on the ARNOLD initiative. While keeping their GIS application the same, FDOT has been working towards the ARNOLD requirement by initially using python scripts, then snapping Topologically Integrated Geographic Encoding and Referencing (TIGER) data layers to their LRS. Afterwards, overlapping TIGER segments are removed, a topology is built, and flags for overshoots and other errors are identified and at times, manually edited. To do this, FDOT continues to use Esri’s ArcGIS application. The results of the analysis are shown in Figure 3 below.

  

  Figure 3. FDOT Miami Dade ARNOLD Result

  FDOT does not use Roads and Highways, however, because they face no current limitations and any change to their current system might produce an interruption in day-to-day GIS activities. FDOT’s goal is to make ARNOLD compliance a permanent part of the State’s LRS and not a separate process, as it currently is. FDOT has completed all roads for one FDOT district and is currently working on obtaining all related attributes. FDOT’s plan is to proceed county by county and district by district in order to complete the entire State network.

• Peer Example: Before the HPMS expansion to include all public roads, KDOT did not have an all-inclusive network and had to significantly improve its GIS capabilities to meet the new requirement. Initially, the State DOT researched solutions and sought out advice from other groups through conferences and peer exchanges. The agency’s goal was to use an efficient application that was commercial off-the-shelf (COTS) with minimal customization, provided enterprise access, and could combine their GIS and Inventory Databases. To identify such a solution, KDOT conducted a feasibility study, issued an RFP, selected a vendor, and finally started project implementation, all of which was completed in 2015 and 2016. KDOT now uses Esri as its main COTS. Transcends, the chosen vendor for integration, provides certain customized products for KDOT that can be used over the Esri application. KDOT also worked with Cambridge Systematics to review the State’s safety data, hoping to expand the network and crash data system. The State’s continuing goal is to coordinate better with other organizations that have and use geospatial data.

• Peer Example: MnDOT recognized that its original data model, while simple, was resource-intensive and resulted in data delays. In an attempt to upgrade its system, the agency attempted many times to abandon its legacy mainframe, or local database, approach but was unsuccessful in doing so each time. MnDOT was able to rely on an existing Enterprise Esri agreement to help with the upgrade process. MnDOT’s challenge, however, included requiring Esri’s Roadway Characteristic Editor (RCE) web application to be installed at MnDOT and MnGEO, the Minnesota Geographic Information Office, which required additional training and resources. Additionally, the implementation of an LRS would cause delays at MnDOT. A description of the original MnDOT LRS approach can be seen in Figure 4 below.

  

  Figure 4. Original MnDOT LRS Approach

  MnDOT’s goal has since been to reduce the workload placed on outside organizations such as MPOs and counties while also improving the quality and efficiency of the data that is submitted. Ultimately, having a standard and authoritative source for the data submitted will create cost and time-savings for MnDOT. MnDOT has six full time staff, two temporary workers, and three students who also support data editing on a temporary basis. In addition to increasing staff, the MnDOT GIS division has improved its LRS approach by coordinating well with local jurisdictions. The agreement that MnDOT has reached with these jurisdictions is that the body that is responsible for the road is also in charge of the data or shapefile that is submitted. By allowing local groups to submit geodatabase (GDB) files or shapefiles, with either updates or a full upload of the road network they are in charge of, the local groups do not need to learn how to use RCE and can maintain their existing processes for data updates. MnGEO then takes the data and formats it for MnDOT, and uploads it to MN Geospatial Commons, a collaborative portal for users and publishers of geospatial resources in Minnesota. Figure 5 below summarizes MnDOT’s current LRS update and maintenance approach.

  

  Figure 5. Current MnDOT LRS Approach

B. Local Roads and Data Collection

Peers acknowledged that one of the most challenging aspects of the ARNOLD initiative was the inclusion of local roads within each State LRS. How resource intensive it has been to include local roads, however, has varied by State. Local roads tend to be used significantly less than other roads, and they generally have more complicated geometries. Also, since many local roads are difficult to access, collecting and maintaining data on these roads can be a challenge.

Noting these concerns, FHWA has sought to facilitate the measurement and maintenance of all public roads, including local roads. Overall, FHWA and States in the Pooled Fund Study have aimed to create a system or process that requires less effort to maintain over time. One possible solution to the local roads problem is obtaining road length with GIS software instead of driving length. Ultimately the goal is to explore different approaches to current transportation mapping practices in order to find the most efficient and sustainable solution for mapping and maintaining local roads data.

• Peer Example: Historically, MnDOT has collected data on all public roads, including local roads, since the 1970s with some minor gaps over time. Currently, MnDOT relies on cities and counties for new roads and updates. MnDOT sends out paper maps and asks local areas to mark the condition of each road according to a predetermined color labeling system. In an attempt to provide standardization and digitize the process, MnDOT also encourages local groups to submit file GDBs or shapefiles for their respective local roads. While local governments are not required to submit changes, many still choose to collaborate. Additionally, if a road is labeled incorrectly, a town or county can bring this discrepancy to the attention of MnDOT. Minnesota also has a State gas tax that goes towards roads, which works as an incentive for counties to submit road data because the amount of funds received depends on the road mileage and size. Counties will designate a certain amount of county roads that are part of a State Aid system. If there are any changes to the roads, the counties submit a request to the State to receive funds.

• Peer Example: UDOT is using ARNOLD as an opportunity to improve its custom LRS and to include local roads, although it has been working with limited funding. Using available resources, there is an annual update rate for local roads. UDOT has a hybrid approach where counties edit directly into the Roads Centerline application. Because these edits or data submissions are not required, counties submit them on their own.

  Counties and cities receive 911 Emergency funding, DOT funding, and State gas tax funding based on the measures they provide to the State DOT. UDOT is working with other State and local agencies to improve access for local groups when incorporating data into UDOT’s network, facilitating the overall process.

  UDOT is also not utilizing Esri’s Roads and Highways, which is commonly used by other States. The UDOT is using a centerline local model and expanding on it to meet their GIS needs. While the LRS model that UDOT has built is working, the State DOT recognizes that it will have to make investments into a more robust system in order to meet evolving data demands.

• Peer Example: When updating its current model, PennDOT was able to add a number of features to its database including turnpike ramps, service roads, access roads, interstate, US, and PA traffic routes, State route crossovers, and roads from other agencies. While PennDOT is accounting for local roads as well, these roads are not part of the Statewide network yet. Local roads are maintained separately through another LRS and are segmented by North/South or East/West.

  In PennDOT’s case, a DOT can meet ARNOLD requirements but still have room for improvements in efficiency for data collection and storage. While having the local roads and the remaining public roads in the same LRS would reduce cost, maintenance, and other resources, consolidating the two LRSs is too resource intensive. In the future, PennDOT aims to combine the two systems.

C. Standardizing and Unifying Roadway Characteristics and Categorizations

As peer agencies continue to explore how to effectively use GIS tools and applications to support the ARNOLD initiative, the design and mechanisms used to measure roadway characteristics and format them so they can be submitted to HPMS varied from State to State. When it comes to collecting the data, measuring different features, and labeling them, there was no clear consensus among the peers as to what the best approaches should be. With minimal technical guidance to make these choices, over time each State has had to come up with its own methodology to collect data and maintain them in its systems. In some cases, States relied on peers’ examples of best practices to determine a methodology. In other cases, States relied on vendors to come up with an appropriate approach for them.

Overall, there were a few common issues or examples related to capturing different types of roadway characteristics that arose throughout the peer exchange. Among them were using street or route IDs for location information, storing road information as single versus dual carriageways versus dual routes, and data submissions formatting.

• Peer Example: Over time, MnDOT has undergone a number of changes in the way each of their data points are labeled and stored. Some of the considerations that Minnesota had to take throughout this process included how to maintain data, how to obtain a single geometry or set of topographical rules such as using increasing and decreasing directions and establishing left or right portions of a road, how to correctly detail intersections where local and State roads met, and boundary details between tribal MOU reservations and communities.

  When updating its system, MnDOT created a new set of route IDs which include the Geographic Names Information System (GNIS) codes. The route IDs consist of 18 alphanumeric characters where each subset of characters represents a different piece of information. The ID includes, in this order, the route system number, GNIS, route number, route suffix, and directional indicator. Another roadway characteristic that MnDOT changed was how to measure road lengths. In the past, the State DOT used true miles as the means of measurement, which is the actual distance a vehicle travels when on a road. Currently, MnDOT uses Cartographic (Carto) length instead, which is defined as the two dimensional length of the road on a map; it ignores elevation changes in length due to hills and valleys. Additionally, MnDOT has decided to split routes with two ways as dual routes. Using Carto length, MnDOT measures the length of each direction separately.

  When MnDOT enters new assets that are located near local roads, while they may be associated with the local road, they are, in fact, tied to the nearest highway. The assets are tied to the route and measure of that route, closest to the asset. Originally, MnDOT also had a status update for roads that were active or inactive. This status, however, confused data editors, so MnDOT now has a route system that filters by types of roads. In another example of unique road categorizations, MnDOT has a multi-faceted approach when entering roundabouts into its database. If the same route exists on both sides of the roundabout, the route will carry through the roundabout unaffected. If the route changes, however, it does not enter the roundabout. For bicycles, MnDOT currently has data for bike lanes and rails but there is no corresponding LRS for these data.

  Figure 6 below illustrates how MnDOT currently characterizes a bi-directional, two-lane road and compares it to how it did so in its older system. MnDOT maintains a RouteID for inventory direction and non-inventory direction on all roads, divided and undivided. MnDOT also characterizes their roads by increasing mileage in the same direction for both the inventory route and the non-inventory route. Undivided roads will have a route in each direction with a right shoulder and no left shoulder—left shoulders only appear on routes which are divided. Wholly undivided roads will have a route pair (inventory and non-inventory) whose mileage is identical. If a route becomes divided for a portion, then the mileage will be different, even if the route comes back together at a latter point, the same piece of pavement will have different measures for the inventory and non-inventory routes. When reporting mileage totals, only inventory miles are used, creating a discrepancy if non-inventory mileage is not equal to inventory mileage.

  

  Figure 6. MnDOT Roadway Characteristics

  Advantages to this method are that right and left are always right and left. A user does not need to call the non-inventory right shoulder a left shoulder due to a need of a single route which already has an inventory direction right shoulder. Another advantage is that you are treating all undivided routes the same. In the typical road and highway model, if a route is wholly undivided, only a single route is created, but if a portion of a route, anywhere along its length, is divided, then the whole route is made up of a route pair. This process means that when trying to edit the data, you need to know the details of the whole route and not just the portion you are editing. Additionally, it also means that when you extract data to use in other systems, you can develop consistent methods and do not need to work out how to handle differences due to undivided portions of route pairs versus routes that are wholly undivided. Another advantage is that you do not need to handle fudging mileage on the non-inventory route to try to force it to match the inventory side.

  The disadvantages to the described method are that the best way to work with the data is through maps and spatial operations. A user cannot simply take the mileage on the non-inventory side and combine it with the inventory side at the same measure. Instead, he or she needs to carry out this task separately. The other disadvantage is that this method doubles the network editing effort for wholly undivided routes.

• Peer Example: One challenge for Caltrans has been the naming standards for route IDs. Caltrans had to establish a naming mechanism and reconcile the existing different definitions with the new names. According to FHWA, the route IDs can be up to 120 characters long, which did not limit Caltrans as its IDs already fell within that range. Caltrans acknowledged that there are many approaches for deciding on an appropriate ID. Opening up the ID to using street names, for example, can possibly be more efficient as long as spaces are accounted for (particularly leading spaces, which can become more pertinent when exporting data). To help in the creation of IDs, private software programs can also convert names into numeric values, possibly solving character restrictions or space issues when using street names for route IDs. It is not clear to Caltrans, however, if this mechanism of using an algorithm to create route IDs, using street names, or labeling segments in other ways will meet its needs best because they all seem to require the same amount of time and it is not clear what the long term benefits are (e.g. easier formatting).

  One of the new features of ARNOLD is the recommendation that linear precision and accuracy is within .001 miles. Caltrans currently measures distances in miles up to three decimal points, which translates to about five feet of accuracy and aligns with the data accuracy in ARNOLD. Another challenge for Caltrans when updating its system was classifying alleys. In Sacramento, where Caltrans held a pilot program for its LRS system, many alleys have been converted to public streets. In order to account for this, they created an algorithm for naming each alley based on a concatenation of nearby streets and other information.

D. NG911 Integration and Collaboration

The 911 system is a North American system used in the United States that links emergency callers to an appropriate public resource. There are two primary 911 systems—E911, and NG911. E911 is a mixture of technologies involving land-line phone numbers assigned to cell towers, where even though digital voice 911 communications are supported, IP is not supported to the 911 dispatch center. In E911, the system from cell tower to dispatch is an analog system. NG911, on the other hand, uses GIS based call routing and supports Internet Protocol including text messaging, VOIP, and multimedia.

Because 911 service providers are generally not part of a State DOT, they rely on their own GIS resources and data collecting services in order to locate 911 callers, route emergency vehicles, and provide other emergency services. 911 providers can at times have data related to public roads that local counties or State DOTs do not have; or, if they do have it, data likely does not align across systems.

As part of the ARNOLD initiative and other State and Federal guidelines, State DOTs and 911 agencies can work together to ensure that each agency has the most up-to-date and accurate information. In order to reach emergency callers, 911 providers must have accurate address and road names in order to appropriately navigate emergency responders to the location of an emergency. Likewise, in order to accurately create and maintain road networks, State DOTs need the same information.

• Peer Example: With State coordinating councils and subcommittees, KDOT produces a Statewide data model for their road network. KDOT’s goal is to use this data model and coordinate better with other organizations that have and use geospatial data, including the NG911 data stewards. One of the main benefits of such a partnership is filing information gaps. Any information that the DOT has and 911 is missing, the State DOT can populate or transmit for them using a combined database. The result of this collaboration is a geodatabase of aggregate county information. Upon collecting and aggregating all data into a common database, KDOT can then create an all-inclusive LRS management system. Because each group maintains different levels of detail on the road network, depending on the region and data granularity, the overall outcome is a more robust database as compared one where each group works independently.

  While collaborating on data collection and usage has yet to be proven successful at KDOT, the agency is still exploring ways to improve the process. Currently, KDOT is exploring ways to make the NG911 management system more efficient.

• Peer Example: MnDOT is a unique DOT with respect to how it is able to collect and manage 911 data. In Minnesota, there is a State law that requires local agencies to share data, including 911 data, freely with other local agencies, including the State DOT. The law has been critical for MnDOT when building its LRS because it has freed up their resources to focus on the data processing instead of the requesting phase. Additionally, by requiring the sharing of data, MnDOT has been able to more periodically obtain data, allowing it to update the overall LRS on a more consistent basis.
• Peer Example: Similar to other peers, PennDOT continues to face challenges when working with 911 data and local counties. Part of PennDOT’s role is to coordinate and reconcile data between the data obtained from counties and data obtained through the 911 network. In doing so, PennDOT requests data from local counties but there is no legal requirement for the counties to provide the data. There can also be issues when PennDOT does receive data. Additionally, while some counties provide their data openly, other counties are restrictive with the use of the data. These types of counties can require PennDOT to not publicly disclose the data, which heavily limits how the agency can use the data and incorporate them into their own system if they can even do so at all.

E. Education and Training Needs - Present and Future

As GIS technologies have evolved since the early 2000s, every State DOT has faced the challenge of keeping up with new technologies and practices. In many instances, State DOTs have had limited resources or encountered unique challenges, with few or no precedents on which to build. Whether it has been digitizing maps or migrating from legacy applications to newer applications such as ArcGIS, many States have had to take on a learn-as-you go approach to meet regulatory and technological demands. With respect to ARNOLD, FHWA’s goal has been to assist all States in meeting the new LRS standards. However, State DOTs are often resource-limited and may rely on small teams of GIS specialists to meet the LRS requirements. Training and education are therefore critical, to build the skillsets of existing teams and to ensure the long-term success of a program.

• Peer Example: Some of the challenges that Caltrans experienced when creating a new all roads LRS were rooted in knowledge sharing and/or training capabilities. Initially, there was a lack of understanding of what linear referencing entailed. In order to address this, starting in July 2012, Caltrans initiated an LRS Pilot that tested a subset of the State (Sacramento County). While the pilot was successful in increasing Caltrans’ LRS knowledge, it also revealed unique challenges that Caltrans would have to continue to explore. For instance, the State DOT concluded that the pilot should have included more complex State highway routes as this is a common feature of the California roads network.

  As Caltrans built on the pilot experience, another challenge was a lack of buy-in or engagement from stakeholders and planners. With minimal engagement, stakeholders expected the Caltrans GIS department to solve issues completely independently of stakeholder involvement. This resulted in unforeseen issues in the beginning process that resulted in delays later on. Additionally, there was a lack of GIS expertise in business units, creating difficulties when trying to correct errors or issues with the support of the GIS department.

  Learning from these experiences, Caltrans created a branch dedicated to its Linear Referencing System. The branch geocodes post-mile events and is currently developing the capability to do the same on local roads. Having established a pilot and overcome the initial training and knowledge limitation, the LRS branch maintains and calibrates the LRS database while also continuing to build on its experience in the field.

• Peer Example: In general, the GIS community in Kansas has had limited exposure to linear referencing. In an effort to increase exposure, KDOT recently lead a 45-minute presentation titled “Introduction to Linear Referencing in ArcGIS” at a Kansas GIS conference. For many conference attendees, there exists excitement about the capability to dynamically segment event data and reduce centerline segmentation. With these experiences, it is clear that more basic introductory training to Linear Referencing Systems targeted to beginner and up to advanced GIS users would benefit adoption and support of linear referencing capabilities to state, county, regional, and local GIS analysts and coordinators. This would especially be true after the LRS systems are implemented at the state level. It would not be so helpful, however, if local agencies took to developing their own LRS systems. When describing education and training process, KDOT equated to a TV show about cooking: “We show and demonstrate different ways to combine the ingredients of routes and events, then we need to pull a finished ‘Baked Alaska’ out of the oven to demonstrate the finished product.”

Back to Top

CONCLUSIONS

Over the course of the peer exchange, participants identified general lessons learned from their efforts to date:

• Continue training and education for ARNOLD and LRS Standards.
  When the ARNOLD initiative was first announced, peers found themselves at different capability levels in creating an LRS that can incorporate all public roads. In some cases, peers had already been collecting the necessary data to meet the HPMS ARNOLD expansion. In other cases, however, peers had to start from defining what an LRS is and how it can be developed. While the peers and FHWA agreed that creating a strict list of topology rules is not the ideal approach, it would help all peers if FHWA provided more technical guidance for LRS, including best or common practices with regards to mainframe and enterprise systems, route IDs, local government collaboration, and other similar issues. Peers agreed that there is a demand for establishing a workshop on GIS solutions to transportation needs, including ARNOLD.

• Develop case studies on how different types of States met the ARNOLD requirement.
  While some States were able to meet the ARNOLD requirement since it went into effect, other States have required more time and resources to do so, with some States still working towards the goal. All peers agreed that more detailed case studies of different types of States that have already met the new HPMS requirement will be very beneficial to those States that are still working towards meeting the requirement. Additionally, the case studies can provide a more detailed account of some of the best practices for many of the common issues that were identified throughout the peer exchange. Overall, there is peer interest to see what the common practices in Asset Management with GIS are.

• Support improved consistency in approaches to sharing data between agencies.
  In many cases, States have to rely on counties and local organizations to submit data for the State’s LRS. While some States have legally required data to be shared between agencies, in other States the sharing of data is optional. In the latter case, peers noted that building a good relationship with local organizations is crucial in order encourage data sharing and improve overall GIS collection and maintenance practices. Even though the accurate submission of public roads is required for certain forms of State funding, some counties do not update their road network submission where some have even gone over a decade without making any changes. Some of the peers noted how they have also tried to improve the data submission process to not only increase participation and accuracy, but also to improve the efficiency of how the data is processed by the DOT once they are submitted. Peer agencies’ approaches include loosening technical restrictions to data uploads by either only submitting a shapefile, creating easier to use portals, or allowing local agencies to edit directly into the roads network.

• Develop a Strategy to Allocate Increasingly Limited Funding.
  Peers noted that, in many cases, only a small portion of the DOT budget goes to GIS needs, causing States to take a very gradual approach when adopting new technologies or instituting new practices. It can also be very difficult for a State to meet a federal requirement if there is no fiscal aid that comes along with the requirement. For some peer agencies, investing in GIS is a low priority and the least attractive investment for a new technology. For some other peer agencies, however, adopting a new GIS technology and working with professional GIS companies is a top priority. In the latter cases, State DOTs have been able to leverage Federal requirements when applying for grants.

  Even when States have funding dedicated to GIS technologies, there are also challenges with the best way to allocate these funds. In addition to having to justify how funds are applied to non-technical staff superiors, there can also be unexpected delays due to system migration, cataloging, and other types of issues. As a State’s database becomes more robust, the funding requirements to continue to efficiently maintain that database can also grow. All peers agreed that it is crucial that funding requirements and limitations are anticipated as early on in the planning process as possible.

• Keep it simple, well-defined, and achievable.
  Some peers noted that in addition to meeting the ARNOLD requirement, State DOTs need to manage and prioritize their resources on simultaneous projects. In some cases, State DOTs would spend too much time writing statements of work (SOWs), delaying projects. Additionally, some projects were not coordinated well with each other, creating further delays. With improved project management, both time and resources could be saved. Within projects, it is also important to identify and define all relative business rules before the start of a project. A pilot project is also a great way to identify many of these issues in advance. Having the appropriate customer buy-in and understanding is essential to successful project implementation. Finally, planning enough time for data clean up, including extra time for possible delays, is crucial in order to stay within a determined schedule.

Back to Top

APPENDIX A: PEER EXCHANGE AGENDA AND PARTICIPANTS

FHWA Peer Exchange: All Road Network of Linear Referenced Data (ARNOLD)

Residence Inn Kansas City at The Legends
1875 Village West Parkway, Kansas City, KS 66111
June 14-15, 2016

Participants

Agenda

Roundtable Discussion Questions

Roundtable 1: Data Models
All Participants

• How did you get started with developing your data model?
• Did you start with the roads and highways model and built on it, or did you develop it another way?
• How are you collaborating with other agencies to develop the data models?
• How are you dealing with Federal Land Management Agencies?
• What linear referencing methods are you using?

Roundtable 2: Incorporating Other Data and Systems
All Participants

• How do you make sure your data and models interface with other systems (e.g., traffic counting, crash records, real time traveler information)?
• How does asset management play a role in your ARNOLD process?
• What vendors did you select, and what custom software have you employed to meet the requirements?

Roundtable 3: Lessons Learned
All Participants

• What decisions have influenced your projects? How?
• Do you think you planned well, or did you run into roadblocks?
• What would you do differently knowing what you know now?
• How did your business rules affect your projects?

Roundtable 4: Moving Forward with ARNOLD Activities
All Participants

• What will your next big hurdle be for GIS and ARNOLD mapping?
• FHWA and DOT vision for Arnold

Back to Top

FOOTNOTES

Back to Top