The Highway Performance Monitoring System (HPMS), defined in 23 CFR 460, was established in 1978 to require the states to provide specified system-wide and sample data on roadways of all types in tabular format. More recently, HPMS requirements were extended to include mandatory submission of an All Road Network of Linear Referenced Data (ARNOLD), FHWA’s internal name for the All Roads Network Of Linear referenced Data extracted from HPMS. This new requirement extends LRS to local roads and streets, which may or may not be under the jurisdiction of the DOTs. Doing so is in support of implementing the Transportation for the Nation (TFTN) Strategic Plan, which calls for an expanded HPMS dataset to become the basis for all transportation-related geo-referenced analyses, such as those related to certified road mileage, system maintenance, capital improvements, safety, and bridge inspections. For example, the Guidance on State Safety Data Systems call for geolocation of crash, roadway, and traffic on an all public roads highway basemap to support States analysis and evaluation capabilities. Although HPMS reporting requirements are well defined and national in scope, the data systems developed by the states to collect, store, and manage roadway data may be unique to each state. Legacy mainframe-based data management systems were generally established on an existing LRS that often-lacked geometry and relied on text-based descriptions of road segments. In this model, road locations were identified by their distance from a point of origin and could include referential complexities, such as station equations. Roadway elements and characteristics are described by data records tied to a linear location defined in the LRS. Some states had, or evolved to have, multiple function-specific location referencing methods (LRMs) within their DOT, adding further to the implementation differences between states. Point of origin, LRS structure, path to follow, roadway naming, and other components of state-specific practices were developed over many years and remain widely varied. Despite the uniformity of terms and underlying concepts, the implementation details and the systems that support them are not standardized among the states. These factors have combined to hinder FHWA’s ability to develop a single nationwide, geospatial, digital database. Widespread use of desktop GIS for statewide mapping, geospatial data management, and analysis began in the 1990s. DOTs were early adopters of the technology, often in a decentralized manner. Throughout the period of initial GIS deployment, which continues today, the work is still done, in isolation, one state at a time. Except in those few states where public road mileage is used to allocate tax revenues or the DOT had broad jurisdictional responsibilities, the inclusion of local roads is a relatively recent occurrence. Many states are now attempting to involve local governments in the ARNOLD data production and maintenance process rather than trying to independently produce a statewide spatial database themselves. Such state-local interaction is often a new experience for the participants, and introdu

There are now many advantages to adopting an enterprise perspective to the roadway inventory for those states that have not yet done so. DOTs are taking a more integrated approach to transportation system management. Adopting such an approach requires business rules that address data quantity, quality, and the need to integrate data across and between multiple levels of government. This is a massive undertaking, even for those DOTs that already have an integrated highway inventory. Many DOTs are struggling to deploy enterprise LRS that will relate work processes, transportation system data editing, and publication (data reporting, distribution, and sharing). At its core, the problem they face is a lack of understanding of entrenched business processes on the part of those implementing and using enterprise LRS management systems. It is common that the DOT workgroups responsible for map editing do not generally include staff familiar with the business data that will be placed on the maps by others. Many people doing the work today do not have the institutional knowledge regarding how and why the systems were developed, and implicit business rules were not formally documented. Adding to the problem is the absence of knowledge across functional business groups regarding each other’s business data, as well as, the fundamentals of GIS. As a result, most DOTs have evolved as a collection of “stovepipes”—independent groups that focus on a single aspect of the state’s transportation system (e.g., pavement management, bridges, traffic operations, planning, project development, etc.). While making the transition to an enterprise LRS that provides the roadway facilities upon which these functional units are expected to base their own data, DOTs are dealing with legacy systems and work processes that were developed within this stovepipe environment. Most of these functional units have long-established data systems and work processes that evolved over time and often lack a documented set of rules. This is further complicated by incorporating new (to the functional units), geospatially-based workflows. As a result, DOTs across the country are struggling with such questions as: • What are the data business rules and who is responsible for them? If they presently exist, are they well documented and understood by staff? • Who owns or acts as a steward for what data? • What cartographic abstractions and standards are needed by each user group? • Do existing business rules need to evolve to reflect current and future needs/technology? • All States uses an LRS. What LRM(s) do they use? Is it ingrained in their culture • How can the DOT maintain a statewide map of local roads to meet the ARNOLD mandate when the agency may or may not directly work with local roads or agencies? • Should the DOT’s LRS be extended to non-DOT facilities, or do they need a different approach? • How does the DOT address the evolving nature of the transportation system (changes over time, eliminated roads or future roads to be built, realignments, etc.)? • How does the LRS support non-DOT functions, like NexGen911, local road traffic, local road traveler information (511), and other essential functions. This pooled-fund project will assist DOTs, MPOs, and local governments create enterprise GIS data management systems based on data governance best practices that support collaboration through shared business rules and standards that support the principle of “measure once, use many times,” with the goal of a single roadway dataset that meets the needs of multiple groups. The first phase of the project will develop guidance known as MUGIS-T, a manual that will guide the Nations DOT's to one geospatial transportation standard. Once the guidance is finalized, the Pooled Fund Study will provide assistance to the participating Sates to implement the guidance.

1) Perform self-assessment of existing data governance policies to determine if they support data quality and sharing. 2) Identify common needs for state and local government transportation agencies responsible for roadway data collection, maintenance, and publication. 3) Define the role of LRS in roadway data collection, maintenance, and publication operations. 4) Establish core requirements for LRS, some of which can build on the work already completed for ARNOLD compliance. 5) Identify the business rules that meet the core requirements for LRS and roadway data collection, maintenance, and publication. 6) Establish guidelines for transportation mapping practices that meet the needs defined above. 7) Assist States in implementing the developed guidelines.

We expect to receive approval for SPR A and B match waivers. More information is available in the Proposal Document posted in the Document Section.