Trails Geospatial Solution Architecture 10/26/2009

Department of the Interior

DOI Trails Geospatial Solution Architecture Plan

Version 1

October 2009

2

This Page is Intentionally Left Blank

3

________________________________________________ ___________ Principal Deputy Assistant Secretary, Date Bureau of Indian Affairs

________________________________________________ ___________ Director, Bureau of Land Management Date ________________________________________________ ___________ Commissioner, Bureau of Reclamation Date ________________________________________________ ___________ Director, Minerals Management Service Date ________________________________________________ ___________ Director, National Park Service Date ________________________________________________ ___________ Director, Office of Surface Mining Date ________________________________________________ ___________ Director, U.S. Fish and Wildlife Service Date ________________________________________________ ___________ Director, U.S. Geological Survey Date ________________________________________________ ___________ Executive Sponsor, (TBD- Karen Siderelis) Date ________________________________________________ ___________ Chief Information Officer (CIO), Office of the CIO, Date

4

Table of Contents – 1.0 Introduction

1.1 Vision, Goals, and Objectives 1.2 What are Trail Data? 1.3 Solution Architecture (SA) 1.4 Trails Geospatial Solution Architecture (TGSA) Roadmap

2.0 Research and Findings

2.1 Office Surveys 2.2 Current DOI Enterprise Efforts 2.3 Issues and Risks

2.4 Return on Investment 2.5 Future Operations

3.0 Recommended Architecture – Concept of Operations

3.1 Data Stewardship – Roles and Responsibilities 3.2 Data Standards

3.2.1 Logical Database Design 3.2.2 Physical Database Design

3.3 Data Processes and Workflows 3.4 Trails Geospatial Solution Architecture Roadmap

4.0 Summary Appendix A – Acronyms and Abbreviations Appendix B – Definitions Appendix C – References Appendix D – DOI Solution Architecture Principles Appendix E – Research Documents List of Tables: Table 1. - Alternatives compared to selected issues and risks identified from the perspective of developing a national seamless Trails Geospatial Dataset (TGD) based on their relative overall value (V) and expense (E) to the organization (L=low, M=medium, H=high). List of Figures: Figure 1 - Components of the DOI Solution Architecture. Figure 2 – Components of the DOI Solution Architecture. Figure 3 – Roadmap for the DOI Trails Geospatial Solution Architecture (TGSA). Figure 4 – Concept of operations (CONOPS) for Trails Geospatial Solution Architecture (TGSA) illustrating examples of dataset manager, stewardship and end user roles in the data workflow among Partner, Field, Bureau, and Enterprise offices participating in the Trails Geospatial Dataset (TGD). Figure 5 – Illustration of the workflows among processes and use cases supporting the DOI Trails Geospatial Database. Change management can be addressed at any point in the workflow. Figure 6 – Timeline showing current conditions of trails distributed across the landscape integrated with the roadmap and phases for the Trails Geospatial Solution Architecture (TGSA). The goal of this plan is to create, maintain, and serve a well-coordinated authoritative seamless geospatial enterprise trails dataset.

5

1.0 Introduction The management of trails is a fundamental business requirement for most Department of the Interior (DOI) Bureaus. DOI trails occur in many forms distributed across the landscape among multiple owners, managers, and sites with no common enterprise architecture to support efficient agency-wide management of these resources. The goal of this plan is to create an authoritative seamless geospatial enterprise trails dataset within DOI that is not fragmented and supports seamless data developed upon solution architecture principles [1] Appendix D. The result is a standardized geospatial dataset upon which management information can be linked and/or integrated into the DOI supported technologies. The Federal Segment Architecture Methodology (FSAM) [2] utilizes defined data, technology, service, and performance reference models to support government business. By integrating FSAM models this plan will develop geospatial enterprise architecture solutions for trails. Guided by the FSAM the DOI recently developed the DOI Geospatial Modernization Blueprint (GMBP). The GMBP recommended trails as a test case for an orphaned dataset (required by many organizations, but not having a definitive owner) [3]. Also under the FSAM, information services for a specific business function (e.g., trails mapping) are identified, planned, and implemented as a solution architecture (SA) defined by DOI as “the end-to-end [information technology] IT solution to a particular business problem. It covers both functional aspects as well as operational aspects. This is the basic foundation for solve[ing] DOI business challenges [1].” The transition strategy in the GMBP identifies the need for a SA for trails that will “establish prototype requirements, an enterprise business process, and a cost analysis… to determine the viability of investing in an enterprise solution [3]” that can be used as a model for future efforts. This SA will be implemented as part of the managed portfolio of DOI-wide geospatial enterprise geographic information system (EGIS) and services defined herein as the DOI Trails Geospatial Solution Architecture (TGSA). Transparency, reporting, and compatibility requirements will be evaluated as the TGSA matures. The SA approach in this plan provides a unique and powerful opportunity to test and apply the FSAM and GMBP methodologies [3] in the development of a DOI-wide architecture focused on management of trails geospatial data. Effective management of DOI trails data will demonstrate the coordination, collection, integration, maintenance, and service of an enterprise data asset. Currently trails data is highly fragmented and needs more effective management. Trails data are maintained at many sites across the DOI, including field offices, Bureau offices, regional offices, program offices, etc. These offices, referred to herein as Field offices, have the front-line responsibilities to steward (e.g., collect, update, maintain, archive, etc.) trails data. Often, there is no coordination among the various Field offices, but in other cases, coordination is provided by a central office representing the Bureau (referred to herein as Bureau offices). This plan includes a comprehensive, phased solution (Section 1.4) for standardizing geospatial data layers that support the business requirements of all Bureau and Field offices including services that can link to tabular attribute databases. The goal of this plan is to create, maintain, and serve a well-coordinated authoritative seamless geospatial enterprise trails dataset, herein called the Trails Geospatial Dataset (TGD), that supports evolving DOI program requirements and is built upon SA principles [1] (Section 1.3 and Appendix D). The benefits of creating the TGD and the linking of management information will allow managers to anwser questions such as: What are the construction costs? Who is responsible for maintaining this trail? How many miles of handicap accessible trails are there? What is the maintenance cost per mile of trail? Many more benefits will be realized as the TGD and the TGSA mature over the lifecycle of this effort. The DOI Enterprise Geographic Information Management (EGIM) Team [4] investigated several approaches to enhance DOI data management practices and to provide trails data services for

6

agency programs and partners. During 2007, interviews of a select subset of stakeholders (Section 2.1) provided an initial cross section of data creators and consumers within DOI and the United States Forest Service (USFS). The USFS is a leader in the development and management of trail data and needs to be involved in this effort even though the initial scope of this TGSA plan is DOI. Supplemental information was provided by EGIM subject matter experts to evaluate alternative strategies and reach a consensus on the SA approach recommended in this report. This plan primarily focuses on DOI requirements; a complete national trails dataset is not possible without also addressing other Federal, State, local, nongovernmental, and private organizations that manage trails. Wherever possible, these requirements are included. If DOI can demonstrate a successful solution for managing its own trails data, subsequent efforts can expand the focus to include other organizations in the future. 1.1 Vision, Goals, and Objectives The DOI TGSA aligns well with the vision of the GMBP and its key findings to “Optimize and Standardize Geospatial Data and Services [3].” This plan outlines an integrated architecture and the day-to-day business processes for the management, consumption, and reuse of DOI trails data. The scope of the first phase of this plan is: 1) to develop the stewardship, standards, and processes to create and maintain trails centerlines or corridors, herein referred to as trails centerlines, with simplified attribute information (the DOI TGD), 2) to plan and implement a TGSA that tests the identified standards and processes, and 3) to utilize the results and lessons learned to implement DOI-wide trails data governance, stewardship, and services. This first step toward enabling an enterprise data asset across multiple DOI lines of business will support future integration of geospatial services in programs such as resource management, recreation, construction, budget, maintenance, lands and boundaries, etc. The TGSA for DOI trails will help meet management needs for the ever-expanding network of trails assets and resources. The GMBP documented the “difficulty in establishing a complete and accurate DOI trails dataset [3].” Research, by the EGIM, conducted in 2007 indicated that an authoritative seamless geospatial enterprise trails dataset will provide an opportunity to improve the lifecycle management practices of cataloging, discovery, and availability [3] of these data. This TGSA plan recommends three objectives:

1) Data Stewardship: Determine, document, and implement data stewardship governance and related communication plan(s) with Field, Bureau, and DOI data stewards and stakeholders. The existing community of interest will be organized into formal committees and councils that will act as the advisory and reviewing body for trails data standards and data processes and workflow as they evolve. Data stewards are accountable for trails data. 2) Data Standards: Develop methods and practices to analyze, refine, and implement geospatial data standards and data management practices based on DOI trails stewardship community use cases and information garnered from the 2007 research. Data standards will enable the cross walking of existing trails data. It is well recognized that standardized data will benefit many, but little or no standardization exists at this time. 3) Data Processes and Workflow: Establish data requirements, processes, workflow, and services to provide Field staff the ability to manage the geospatial features, attributes, and metadata. These will set the operational parameters (where, when, what, how, delivery, reuse, etc.) needed to establish effective services to the stewards and consumers of trails data. Dataset managers are responsible for executing trails data processes and workflows. This plan will implement DOI-level enterprise stewardship, Data Lifecycle Management, and Product Generation Services [3] for the DOI TGD. These services may be combined or implemented separately as requirements and resources dictate. The target candidate for publishing the trails

7

Figure 1 – Trails data organized into two basic categories – geospatial features and business data attributes.

dataset is The National Map (TNM), managed as part of the DOI geospatial portfolio. TNM offers web-based display and download of products and services. By leveraging existing programs such as TNM, DOI will reduce the barriers to using these data, increase business demand, and reduce delivery costs [3].

These objectives provide context for a geospatial enterprise architecture that will begin defining the more general process of “how geospatial data and technology will be used to enhance the business activities of DOI and its Bureaus to achieve their mission and goals [3].” The vision, goals, and objectives outlined above will initiate the TGSA, but steward/stakeholder feedback will guide the final outcome. 1.2 What are Trail Data? A trail is defined by the Federal Geographic Data Committee (FGDC) Federal Trail Data Standards (FTDS) [5] as: "A linear route managed for human-powered, stock, or off-highway vehicle forms of transportation or for historic or heritage values [6].” Trails are an important part of the recreational, cultural, environmental, and historical experience in the Nation. Thousands of miles of trails span the US forming a significant transportation and recreation infrastructure. The National Trails System Act of 1968 [6] created the National Scenic Trail (NST) and National Recreation Trail (NRT) designations to promote, establish, and maintain the use of trails in the American outdoor experience. The National Historic Trail (NHT) designation was added in 1978. Under the terms of the act, administration of NST and NHT falls to either DOI or the United States Department of Agriculture (USDA). NRT management remains with the local agency or organization. In contrast, thousands of miles of local trails have no national-level designation. For the TGSA, trail data are defined as business information attributes used by DOI offices and programs to document, map, and maintain trails under their management. These data can be organized into two basic categories (Figure 1):

1. Geospatial Features - the foundational data model of geometric elements (e.g., trail centerline or corridor) and geospatial attributes (e.g., length, unique identifier, or key relational elements).

2. Business Data Attributes – other descriptors or program items (e.g., name, designation, facilities, owner, tread type, conditions, closures, etc.) linked to the geospatial features but stored in separate tables or databases, similar to the FTDS.

1.3 Solution Architecture (SA)

8

Figure 2 – Components of the DOI Solution Architecture.

The DOI mission is accomplished by defining and addressing business requirements. Data provides the foundation upon which the business makes decisions affecting the mission of the organization. The TGSA is one of many comprehensive SA’s currently in work within DOI. This plan outlines a solution for managing a DOI Trails Geospatial Dataset (TGD) as the first step of a comprehensive roadmap [1] guided by the DOI Solution Architecture principles. The DOI SA has five primary components that address business, data, applications, technology, and security (Figure 2). The SA ties these together to “structure every application so that it is cost effective, usable, and maintainable [1].” The overall goal is “…to achieve standardization, interoperability, and sharing across all the business… [1].” This plan focuses primarily on the data architecture and will evolve into the other SA components as it matures. The 2007 research combined with the identified DOI business and workflow requirements provides an interesting picture of the diverse business of trails. The TGSA will leverage and expanded upon previous work to create a solution architecture for DOI Trails. This plan will add to the understanding of what it takes to develop a geospatial architecture to support DOI business. The roadmap for trails includes both a DOI authoritative seamless geospatial enterprise dataset or Authoritative Data Source (ADS) [3] and a rollout strategy. Future endeavors may extend this solution beyond DOI. 1.4 Trails Geospatial Solution Architecture (TGSA) Roadmap

9

The roadmap for the TGSA follows the DOI Target Solution and Application Architecture [1] designed by the Chief Technology Officer Council (CTOC) with a rollout strategy to “start small, empower the users, demonstrate value, incorporate lessons learned, [and] roll out to a larger audience [1].” Figure 3 illustrates the phased approach required to implement the DOI TGSA. This plan focuses on the objects and requirements needed to complete Phase 1 culminating with an operational TGSA system that can be scaled up to meet individual Bureau requirements in Phase 2 and expand upon in subsequent phases. Each of these phases contributes to the overall goal of the TGSA – to create an ADS for trails. The TGSA roadmap is elaborated in Section 3.4.

Figure 3 – Roadmap for the DOI Trails Geospatial Solution Architecture (TGSA).

10

2.0 Research and Findings The Trails Geospatial Solution Architecture (TGSA) was developed by the EGIM Team [4] consistent with the Geospatial Modernization Blueprint (GMBP) [3]. The Trails Geospatial Dataset (TGD) was selected as a test case in the GMBP to “establish prototype requirements, an enterprise business process and a cost analysis… to determine the viability on investing in an enterprise solution [3].” In gathering requirements for the TGSA, several offices were surveyed in 2007 (Appendix E) as a sample of the current state of trails data within the Bureaus and from selected offices outside of DOI. During the survey, a number of issues were identified and discussed. Many of these results have been integrated into the TGSA Concept of Operations presented in Section 3. In addition, the EGIM Team [4] developed a Return on Investment (ROI) to evaluate the economy of the trails investment from a DOI management perspective. Finally, along with the research and findings presented here, a brief review of two funded DOI enterprise information efforts, the National Integrated Lands System (NILS) GeoCommunicator [7] and the National Hydrography Dataset (NHD) [8] / Watershed Boundary Dataset (WBD) [9] is provided. These enterprise efforts, along with The National Map mentioned earlier, will provide valuable information on current practices to consider in planning the TGSA. 2.1 Office Surveys For this research ten Field offices provided input. The survey results revealed a wide diversity of data operations ranging from mature, well-defined information systems to systems in the planning stages with little or no existing data or capability. However, no single survey encompassed all the requirements of the TGSA. The respondents included:

• Bureau of Land Management (BLM) Montana • National Park Service (NPS) National Trails System Office • Federal Interagency Council on Trails • NPS Appalachian Trail NST • NPS Lewis and Clark NHT • NPS Captain John Smith Chesapeake NHT • NPS Potomac Heritage NST • NPS Redwood National & State Parks • US Fish and Wildlife Service (USFWS) National Wildlife Refuge System Roads and Trails

Program • USFS Infrastructure Applications Program

The surveys provided insight to the current existing status for each of these Field offices. Each overview below discusses a snapshot of the office responsibilities, an element unique to the office, and the geospatial capabilities.

BLM Montana: This office requires trail data, but with limited budgets, the data are not currently being maintained due to higher priorities. While the current system does not contain trail data, this system could manage these data. BLM offices in other areas have centralized repositories that provide data access to Field offices. Unique to this site is the need to track special trail types. Geospatial capabilities are limited, but substantial opportunities exist.

11

NPS National Trails System Office: This office is the principle coordination office in the NPS for the National Trails System. The National Trails System Office produces and maintains some datasets and is a consumer of trail data. Key business functions include communications, reporting, interagency coordination, and coordinating the NRT designation process. The National Trails System Office plays a key role in coordinating the FTDS -- and the FGDC review of them. Unique to this office is reliance on the field offices to provide trail data. The National Trails System Office partners with the NPS Geographic Information System (GIS) Program for geospatial support and is sponsoring an EGIS for national trails. Federal Interagency Council on Trails: This is a roundtable of all Federal agencies involved with national trails. The Federal Interagency Council on Trails helped established the Interagency Trail Data Standards (now Federal Trail Data Standards) team in 1999 [10] to coordinate agreement on the definitions of trail information used by trail administrators, managers, and the public. The Council continues to oversee and steer the FGDC Federal Trail Data Standards (FTDS). It recommended in 2008 that the NPS and USFS jointly act as the maintenance authority for the FTDS [5]. The FTDS is largely complete after several rounds of review and refinement. This effort is unique in working with overlapping business requirements that need compatibility with detailed management needs of field offices as well as the summary requirements of bureaus and other agencies. The Council’s geospatial capabilities are nonexistant, but its members’ knowledge can be leveraged for DOI standards development and dissemination. NPS Appalachian Trail NST: The Appalachian Trail NST office oversees the trail lands owned by the Federal government. The office maintains a well defined, comprehensive set of information for all business requirements via strong partnerships that support data maintenance, data sharing agreements, and cost sharing. Unique to this office is the maturity of its capabilities for developing, storing, and maintaining these data. Although limited to desktop applications, the geospatial capabilities in this office are fully integrated within the business requirements. NPS Lewis and Clark NHT: The Lewis and Clark NHT office is relatively new and is still developing business requirements. Some data have been collected and stored in a variety of formats. The route of the trail is being reconstructed from a variety of sources. The Lewis and Clark NHT length is over 3,800 miles and runs through 13 States. Related information is complex, and a very large number of stakeholders are involved. Due to the current developmental phase and the complexity of this effort, the office is looking to acquire and operate a solution. Unique to this office is the complexity of the development process and the desire to lay an effective foundation to build upon. The geospatial capabilities in this office are limited at this time, but the potential for a fully integrated dataset exists.

12

Captain John Smith Chesapeake NHT: This NST office is also new but completed a feasibility study and started a comprehensive management plan. The location of the NHT is predominately on water and has been reconstructed from historical documents of John Smith’s explorations of the Chesapeake Bay. The trail totals over 2,000 miles with large public lands involved. The office operates in cooperation with other Federal, State, and local partners to address many complex requirements. Unique to this office is the nature of the resource and diversity of partners involved. The development process is complex and requires an effective foundation to build upon. The geospatial capabilities in this office are limited at this time, but the potential for a fully integrated dataset exists. NPS Potomac Heritage NST: This office coordinates a partnership developing a network of locally managed trails in a corridor between the mouth of the Potomac River and the Allegheny Highlands. Portions of this network are recognized as NST assets, but the partnership works with other national trails including the Appalachian Trail NST office discussed above. Unique to this office is the complexity of the overlapping trails network. The geospatial capabilities in this office are limited at this time. NPS Redwood National & State Parks: This office maintains roads and trails data for the Park, outside researchers, and regulatory agencies in a small-scale EGIS. Available data span multiple resource themes including diverse trail types in support of numerous management requirements. This office is unique in its maturity with developing, storing, and maintaining resource data across multiple local sites. The geospatial capabilities at Redwood National & State Parks are enterprise in scope and fully integrated with their business requirements. US Fish and Wildlife Service (USFWS) National Wildlife Refuge System Roads and Trails Program: The USFWS maintains data for segments of over 50 NHTs, NSTs, and NRTs representing over 2,500 miles of land and water trails. The lead office is part of the National Wildlife Refuge system and contracted with the Federal Highway Administration to create a national trails dataset. In 2007, an inventory was completed to assess the overall condition of these data in the USFWS property management system using FTDS attributes and to develop a maintenance plan and budget. USFWS is unique in its efforts to integrate data into both a Bureau office system and the property management system. When surveyed, the geospatial capabilities in this office were limited, but opportunities for full integration exist. USFS Infrastructure Applications Program: The USFS manages data for over 138,000 miles of trails including NHTs, NSTs, and NRTs. The data are stored in the inventory and monitoring management system that contains a wide range of USFS data as part of a complex business application. Unique to this office is the comprehensive and mature manner of storing and maintaining these data for internal business use. The geospatial capabilities in this office are fully integrated within the business requirements. Opportunities exist for providing comprehensive recreation data to the public.

13

2.2 Current DOI Enterprise Efforts Two current DOI enterprise information programs, the National Integrated Lands System (NILS) GeoCommunicator [7] and the National Hydrography Dataset (NHD) / Watershed Boundary Dataset (WBD), provide valuable information on current practices that can help guide the TGSA plan. These two programs use different approaches, and the EGIM will utilize applicable components and practices in the TGSA.

NILS: This is a joint project between the BLM and the USFS in partnership with States, counties, and private industry to provide business solutions for the management of cadastral records and land parcel information in a geospatial environment. NILS provides a process to collect, maintain, and store parcel-based land and survey information that meets the common, shared business requirements of the two partners [7]. This is supported by three quality assurance methods integrated throughout the process [13]. NILS uses a centralized data and application management strategy. User applications run in a client-server environment where the geospatial applications are co-located with the geographic data on the server. NILS shares some data management characteristics in common with the needs for trails. These include the use of data standards, data quality, a Data Advisory Council, and stewardship. Although most trails data are not based on legal surveys, several NILS operations and requirements may be applicable to the TGSA, warranting further research and consideration. NHD/WBD: The NHD is the result of cooperative programs between the US Environmental Protection Agency (EPA) and the U.S. Geological Survey (USGS). It combines the USGS Digital Line Graph Hydrography data and the EPA Reach File data [14]. This comprehensive national seamless geospatial dataset contains information about surface water features including lakes, streams, rivers, springs, etc. The surface water features are combined to form uniquely identified hydrologic sequences in a network that enables hydrologic modeling, analysis, and display. NHD “was designed to be a reliable source of data that would grow through system-wide revisions and the contributions of its users [15].” NHD has a formal Data Advisory Council and a well integrated stewardship community. The WBD defines a nested system of watershed drainage boundaries “determined solely upon science-based hydrologic principles… [16].” This is a cooperative effort between USDA Natural Resources Conservation Service (NRCS) and USGS. The WBD geospatial dataset is unique in utilizing a certification step to ensure the data meet agreed-upon published guidelines [17]. The WBD also has an active stewardship community that is participating both in the WBD and the integration of the WBD into the NHD as well as stewardship of NHD. The highly federated NHD/WBD programs emphasize the dataset model coupled with common collection and editing rules to assure data quality and integrity. Collaborative stewardship supports the data model, yet allows the stewards to extend the dataset model to meet their local requirements. Each of these enterprise efforts have stewardship advisory committees and extensive stewardship interaction that the trails dataset governance recommendations could benefit from. The roles and responsibilities of the data steward are well defined for each

14

enterprise effort and are soon to be approved by the sponsoring organizations. Many of these business rules, principles, design, and stewardship elements will be applicable to trails.

These two DOI enterprise information programs have matured with many years of evolving management practices. Whereas the approaches and mandates are different from trails, the TGSA plan can learn much from these projects and how they address common requirements and issues. 2.3 Issues and Risks The TGSA must address numerous issues and risks. DOI, the Bureaus, and Field offices have differing priorities, budgets, and available resources. As was seen in Section 2.1, local requirements and unique elements vary widely. Several of the issues that stood out are listed below and will be addressed as part of the TGSA plan. While these issues and risks cannot be easily integrated into the three objectives listed in Section 1.1, they do point to the need for a TGSA implementation plan. These issues and risks include:

No Common Data Model • Problem: Data are not maintained using a consistent foundational data model upon

which other standards, such as the FTDS can link. • Recommendation: Develop a data exchange standard and single data model that can

be extended for other business requirements. Standards Integration – Independent Development

• Problem: Existing standards have been developed independently to meet local needs. • Recommendation: Develop standards for the DOI TGSA based on legacy data models

and current requirements that are extendable and flexible for local office use. Standards Integration – FTDS Integration

• Problem: The FTDS [5] content standard is not yet final and many field offices are not familiar with, nor have evaluated how to integrate this content standard.

• Recommendation: Educate, evaluate, and as appropriate integrate the FTDS content standards into the TGSA and existing systems to support business needs.

Access to Data • Problem: Data are difficult to find. In many cases the data are not available to all

stakeholders except through direct contacts. • Recommendation: Provide a single source for DOI trails data that will be a recognized

DOI Authoritative Data Source (ADS) [18]. Data Exchange Formats

• Problem: Once located, the data are in a variety of formats requiring significant effort to aggregate into a unified product that can be used by multiple programs.

• Recommendation: Standardize the data to meet consumer business requirements. Currency of Data

• Problem: Field offices may have current data, but other offices needing the data do not. Business decisions are often made on out-dated data.

• Recommendation: Develop systematic protocols and workflows to keep the data current and available to multiple consumers.

Tool Development • Problem: Converting to and maintaining common data models takes time and effort. • Recommendation: Implement data exchange standards and develop tools to convert,

and maintain agreed upon data models developed to meet business requirements. Funding/Budget

• Problem: Funding for data collection, management, sharing, etc. is embedded in DOI program and office budgets with no direction to support a cross-cutting national dataset.

15

• Recommendation: Funding for this effort needs to be supported at the DOI level and build upon the efforts in the field instead of reallocating limited funds and staff, or asking field offices to contribute limited funding to this DOI enterprise effort.

Best Management Practices • Problem: Few enterprise datasets exist to model best management practices. • Recommendation: Review current program practices, develop pros and cons, identify

common elements, leverage or develop these to support the TGSA. Governance

• Problem: There is no single organization with overall responsibility to administer and manage trails data. The Office of Management and Budget (OMB) Circular No. A-16 [19] includes trails in the definition of transportation assigned to the US Department of Transportation (DOT), but trails are generally outside the scope of DOT activities.

• Recommendation: Develop governance via the EGIM and the DOI data stewards and stakeholders to “provide a geospatially informed business-driven management environment for … geospatial assets [3]” as defined in the DOI GMBP. These efforts should be coordinated with USFS Activities for future integration.

Stewardship • Problem: There is no formal method to assign stewards for managing the trails dataset. • Recommendation: Develop stewardship roles, advisory committees, leverage

integration with the existing stewardship community, identify roles and responsibilities, geographic extents, and workflows needed to implement DOI-wide trails data management.

This is not a comprehensive list of issues but is significant enough to show the need for a more comprehensive TGSA implementation plan that defines a prioritized, well-coordinated, and simplified DOI Trails Geospatial Dataset (TGD). An additional issue to be addressed is when and how service level agreements are implemented to support this effort. The TGSA plan will identify and document additional issues/risks and present recommendations and tactics to address the problems and risks. 2.4 Return on Investment In 2007, the EGIM Team conducted a return on investment (ROI) workshop using guidelines provided by Geospatial Information and Technology Association (GITA) [11] with the intent of determining the ROI for a DOI enterprise geospatial dataset. The process found that an enterprise geospatial data asset is a complicated investment with significant start-up costs, and the benefits/return may not be recognized for many years. Effectively managing the technical aspects of this plan and balancing these against the costs and benefits has been and will continue to be problematic for managers. To strategically analyze the geospatial business of trails, three alternatives were studied:

1) Continue business as usual 2) Coordinate a simplified national seamless DOI Trails Geospatial Dataset (TGD) limited to

geospatial and linking information only 3) Coordinate full TGD including all management information

Table 1 provides a comparison of the relative overall value and expenses of these alternatives to a selected set of issues and risk identified above from the perspective of developing a national seamless TGD.Alternative one continues low overall value and higher expenses to the organization. Alternative three would result in the highest value and expenses to the organization. Alternative two allows is a balance of high value and moderate expenses.

16

Table 1. - Alternatives compared to selected issues and risks identified from the perspective of developing a national seamless Trails Geospatial Dataset (TGD) based on their relative overall value (V) and expense (E) to the organization (L=low, M=medium, H=high).

Alternative Considered

Issues and Risks Data Model

Standards Integration

Access Currency Tool Development

Funding /Budget

Governance / Stewardship

V E V E V E V E V E V E V E 1) Continue Business as Usual

L

H

L

H

L

H

H

H

L

H

L

H

L

L

2) Coordinate a simplfied national seamless DOI TGD

H

M

H

M

H

M

H

M

H

M

H

M

H

M

3) Coordinate full TGD including all management information

H

H

H

H

H

M

H

M

H

M

H

H

H

M

The ROI study clearly indicated that alternative two, to coordinate a national seamless DOI TGD, would be highest return. A simplified DOI TGD contains geospatial features with a limited set of attributes that can be linked with business information (Section 1.2). The Net Present Value (value of a multiyear investment expressed in today’s dollars) was calculated for 3 years with a benefit-cost ratio of 3 to 1, and ROI of 30%. [12] Even with varying assumptions, the business case for this endeavor is very strong and provides significant strategic value to DOI. Alternative two also provides a practical test case and minimizes risks. Identified benefits include:

• Improves data accessibility by serving the data both internally and externally to the public and third-party providers

• Leads to more consistent decisions within an office; consistency of decisions improves our level of service to consumers and reduces potential legal liability

• Promotes faster emergency response, which could save lives The ROI evaluation and the benefits listed indicate that there is a future economic advantage to pursuing an investment in a solution for DOI trails.

17

2.5 Future Operations Based on the research and findings, the EGIM outlined a future operation or concept of operations (CONOPS) on how data will be standardized, managed, and distributed. Figure 4 illustrates the conceptual design of the CONOPS which is presented and discussed with more detail in Section 3.

Figure 4 – Concept of operations (CONOPS) for Trails Geospatial Solution Architecture (TGSA) illustrating examples of dataset manager, stewardship, and end user roles in the data workflow among Partner, Field, Bureau, and Enterprise offices participating in the Trails Geospatial Dataset (TGD). This reflects the highly distributed nature of trails data where the solution is to continue to support and integrate these efforts across DOI.

18

3.0 Recommended Architecture – Concept of Operations A basic concept of operations (CONOPS) for how trails data will be standardized, managed, distributed, and accessed emerged from the initial surveys and input from DOI subject matter experts. Figure 4 illustrates the CONOPS data processes and workflows described herein. The final operational model will be a hybrid between a flat organization where each Field office contributes directly to the TGD and hierarchy where data are aggregated at different organizational levels. This model allows for local requirements and data stewardship by and within Field and Bureau offices which have the front-line responsibilities to collect, update, and maintain these data. Bureau offices may aggregate data for Bureau-related requirements and subsequently, transfer the dataset to the DOI TGD steward along with data transferred directly from Field offices. Data standards and processes will empower all participants to interact and cooperatively manage the TGD. These will be developed and maintained by the governance and stewardship developed in Phase 1 of this plan. The CONOPS focuses on stewardship and data management as they relate to business and geospatial requirements. In addition, the CONOPS integrates the goals and objectives into phases (Figure 3) outlined herein and will be fully documented in the TGSA plan as five steps:

Phase 1 – Plan and Deploy Proof of Concept - Expand upon the previous surveys in a comprehensive project management process [20] to gather comprehensive requirements, define governance, stewardship, standards, and processes/workflows, plan and implement enterprise stewardship and publication services. Phase 2 – First Adopter - Implement the governance, stewardship, standards, and processes/workflows objectives. Phase 3 – Expansion – Develop a TGD DOI-wide in conjunction with enterprise stewardship and product delivery. Phase 4 – Evaluation & Integration – Expand to include other Federal Partners. Phase 5 – Evaluation & Integration – Expand to State, Local and Private Trails.

The goal of the TGSA plan is to create a DOI authoritative seamless geospatial data asset managed as an enterprise portfolio within DOI that is no longer fragmented and supports seamless data developed upon solution architecture principles [1]. This plan establishes a procedure to use in the creation of a DOI authoritative data asset. The TGD design will meet the three objectives specified in Section 1.1 and elaborated more in this section:

1) Data Stewardship 2) Data Standards 3) Data Processes and Workflow

These objectives define “how geospatial data and technology will be used to enhance the business activities of DOI and its Bureaus to achieve their mission and goals [3].” The CONOPS encompasses all aspects of the TGSA and integrates the complex array of requirements, objectives, and architectural components into a documented operational picture. This section describes several of the components in their operational context.

19

3.1 Data Stewardship - Roles and Responsibilities Successful enterprise data management requires coordination and accountability for a wide variety of personnel that have specific roles and responsibilities. A role is the set of work activities/functions assigned to, required by, or expected of a person or group. Responsibility means being answerable for completion of activities/functions within one’s direct control (e.g., actual work/task performed or accomplished). Accountability encompasses being liable for project/program success/failure, decisions, spending, etc. (e.g., the aggregate work of others). In this section, the roles and responsibilities of data managers, data stewards, and end users or consumers are briefly defined as used within the TGSA. More information about roles and responsibilities for data production, maintenance, and use can be found in OMB Circular A-16 [19], the DOI Data Quality Management Guide [21], DOI Data Standardization Procedures [22], the Geospatial Line of Business (GeoLoB) OMB Circular A-16 Supplemental Guidance [23], and the DOI Designation, Management, and Enforcement of Authoritative Data Sources (ADS) Policy [18].

Dataset managers [23] (or data mangers) are associated with the Field, Bureau and DOI TGDs. At each hierarchal level, dataset managers have responsibility to coordinate with subject matter experts, aggregate trails data, assure trails data quality and integrity, and maintain their version of the TGD. They participate in synchronizing data by initiating procedures to maintain updates with the Field offices. Dataset managers coordinate all TGD and schema changes with the data stewards and communities of interest. Dataset managers administer the data services that deliver the TGD to end users and assure that the provided services meet the consumers' service requirements. Data stewards [23] consist of Field or Bureau office personnel accountable for compiling and maintaining the data. They are responsible for the production, maintenance, and usage of the dataset within their office. Activities include managing data programs/projects and staff, ensuring data conforms to standards, meeting content and quality requirements, providing data quality metrics, implementing best management practices, making recommendations, and coordination of end users and dataset managers. Responsibilities include oversight of populating data, exporting data, and synchronizing data.

Partner data stewards work in collaboration with internal consumers, dataset managers, and data stewards. These stewards can be with other Agencies, State/Counties, volunteers, non-profit organizations, etc. They may have a role in the operations and maintenance of these data by assisting in populating and serving data. Access and roles for partner stewards will be determined by Bureau and Field policies.

Data end users [23] / Consumers can be internal to DOI, in other Agencies (EPA, USFS, etc.), partners, and the public. For the TGSA plan, two data end users have been identified.

Internal end user / consumers are those within DOI. Government users may have elevated access to the data, services, and business information as compared to external users. They utilize the data services, provide feedback on business service requirements, and collaborate with data stewards and dataset managers. Public end user / consumers utilize publicly available data services that are available to and consumed in the public domain.

Design and development of this data governance and stewardship framework and the Phase 1 TGSA (Figure 3) will clarify the business requirements, sustainable management processes, and final implementation of the TGSA. The identification and organization of a governance model coupled with stewards to perform these roles and responsibilities is part of the TGSA. Subsequently, the TGSA will be implemented nationally as a series of projects to complete each phase outlined in the roadmap (Figure 3). 3.2 Data Standards

20

The Trails Geospatial Dataset (TGD) will be based on a data exchange standard and geospatial database model developed on existing standards and EGIS models. Existing trails data attribute standards include the Federal Trails Data Standard (FTDS) [5] currently being refined for the Federal Geographic Data Committee (FGDC). FTDS is a data content standard for trails business requirements. The FTDS objectives are [5]:

1) Describe a consistent and universal way to express the content of a trail dataset or data element.

2) Codify commonly used discrete units of trails information, referred to as trail elements or attributes, and thereby provide standardized terminology and definitions to alleviate inconsistencies in the use of trail elements and to simplify the documentation process.

3) Provide a method for documenting the content of trail information in order to facilitate trail data exchange and offer a migration path from legacy formats to standards-compliant ones.

4) Provide a statement of best practices for trail data content and data transfer. 5) Recognize that different users (recreation, facilities, etc.) may require additional

standardization (e.g., extension of the core attributes). The FTDS [5] is a data content standard of trails management attributes but does not define a foundational data exchange standard or an enterprise geospatial data model to support the TGSA. An exchange standard and an enterprise model are necessary to trade data among offices and to deliver the DOI TGD that can be linked to other attributes or extended to other business requirements. Designing a geospatial data model must include both logical and physical database designs. The logical design is concerned with what is in the database [24], whereas the physical design models how the database is structured and linked together [25]. 3.2.1 Logical Database Design The data exchange standard defines the minimum elements of the logical database design. The descriptions below list the geospatial data elements identified to date. The TGSA will include these elements, as well as others collaboratively defined with Field and Bureau offices during the plan.

Spatial Source – The best available source will be utilized with the target source scale of 1:24,000 for continental US, Puerto Rico, and Hawaii and at least 1:63,360 for Alaska. Feature level metadata will be used to track spatial source(s). In the future, availability of high resolution Global Positioning System (GPS) and survey quality data may increase the source scale. Geometry – Trails geometry consists of two-dimensional (2-D) geographic features stored as lines and/or polygons. Geometry will be collected and maintained utilizing best geospatial practices. The data model will accommodate overlapping trails where different trails share a common physical centerline. Although current availability is limited, the plan will evaluate use of three-dimensional (3-D) geometry from GPS or derived from the National Elevation Dataset (NED). Accuracy (Horizontal & Vertical) - Horizontal accuracy reporting will be assessed as part of the process of assembling the DOI TGD. Accuracy for legacy data may be reported according to the accuracy standard in place at the time of data collection [5]. Spatial Reference - The coordinate system will use a standard for datum (e.g., NAD83) and projection/coordinates (e.g., decimal degree) for DOI TGD. A complete projection description in FGDC format is required including horizontal coordinate system, datum, and units of measure. Vertical coordinate system information will be included with three dimensional data. Feature Type – The basic feature types will be a trail centerline (line) or corridor (polygon) with the capability to support network topology and linear referencing if needed. This is a type of spatial relationship that allows linear data elements called segments to be joined together for network modeling and routing applications used extensively in transportation applications. Linear Measure – This function provides measurements along the length of a line feature for routing and locating theme-related items, e.g., structures, shelters, side trails, markers, etc.

21

Measures are derived from the geometry and allow other information to be georeferenced via the line. Linear measures will be evaluated in development of the trails data architecture. Attribution – Attributes are descriptive or qualifying data elements associated with the trail. The simplified DOI TGD will include geospatial attributes and linking tabular fields only. However, business requirements, entity-relationship diagrams, and linking keys will be evaluated in coordination with data elements required by Field and Bureau offices. External attributes (e.g., FTDS [5], Facilities, Law Enforcement, etc.) will link via database keys, similar to the NHD [15] and WBD [17] systems.

Metadata – Metadata is defined as descriptive information about a dataset or item (e.g., data about data). The attributes above define feature level metadata elements to describe each trail segment or section. The FGDC Content Standard for Geospatial Metadata [26] is mandatory for all geospatial datasets. This list represents an example of a minimum set of geometry attributes for exchanging trails data. However, a complete logical data model “is an abstract representation of the categories of data and their relationships [21]” and will be drafted, reviewed, and published in the Phase 1 TGSA. The logical elements will cross walk into a physical enterprise geospatial design to implement the TGD. Transparency, reporting, and compatibility requirements, such as the Geospatial One-Stop (GOS) [27] and data.gov [28], will be evaluated as the TGSA matures. 3.2.2 Physical Database Design A physical database design requires translation of the logical data model into a schema that can be implemented in a Relational Database Management System (RDBMS) where the data are stored in linked tables. RDBMS implementation includes selection of indexes, partitioning, clustering, etc. to maximize the performance of the database across the spectrum of business applications. The Trails Geospatial Dataset (TGD) will be designed as an enterprise geodatabase, but Field or Bureau stewards may opt for more simple data models based on the exchange standard and manage local datasets to meet the immediate business requirements of that office. Trails data may be managed in the scope of a single site or aggregated hierarchically to meet multiple needs (Figure 4). Other offices may require larger scale geometry, attribute detail, or linked information to support local management needs. These varied requirements can be supported in the TGSA and eventually migrated to a common logical and physical design over time. The TGSA implementation will focus on a simplified DOI TGD and lay the ground work for a more elaborate integrated system in the future. The TGD will support the business needs of DOI. The long-term objective is to create a sustainable implementation plan that supports the business needs for all trails across the nation. This will require the use of service level agreements to ensure the data and services are available within reasonable expectations. Data updates will be exchanged/synchronized across distributed or hierarchically stewarded datasets via well-defined data management workflows. In addition to supporting enterprise data stewardship, the physical design is critical to the quality of trails business services that require enterprise database availability, currency, and completeness.

Availability – Although trails data may be considered by some a DOI mission critical information resource [19], they support a required business process with required levels of service. Availability is the percentage of time a system is operational and includes parameters such as mean time between failure, mean time to repair, average response time, maximum response time, etc. When developing the TGSA plan, availability requirements will be established for the development and production versions of the TGD, as well as Field and Bureau office TGDs.

Currency – As data change in the Field offices, updates need to be transmitted to the DOI TGD. The TGD will implement transactional data aggregation with the initial target to roll up

22

Figure 5 – Illustration of the workflows among processes and use cases supporting the DOI Trails Geospatial Database.

updates monthly. As the system matures, the update cycles will increase (e.g., weekly, daily, dynamic). The TGSA plan will test these functions and identify any needed infrastructure improvements.

Completeness – Initially, the design of DOI TGD will include geometry, minimal geospatial attributes, and linking elements. In Phase 1 of the roadmap (Figure 3), the TGSA will be limited to a defined subset of DOI offices and not represent a comprehensive dataset. Completeness for DOI will be accomplished over time (Phase 3). The TGSA plan will identify key areas where infrastructure or resources are not adequate to support a complete DOI TGD. Lessons learned from this effort will provide recommendations for plans and update strategies to support the national dataset and example processes for other enterprise datasets.

Once the logical and physical database designs are completed, including the review and publication of both designs, the database will be created and tested. Use cases will provide testing criteria during database development to refine the workflow and process requirements for the TGSA plan. 3.3 Data Processes and Workflows Robust and well-tested data processes and workflows are critical to effectively manage a complex enterprise geospatial dataset with distributed stewardship for long term success. Use cases necessary to test a seamless enterprise geospatial layer must successfully populate, export, aggregate, synchronize, and serve the data (Figure 5). Change management for the processes, workflows, and database schema is also critical for the dataset continuity of operations. Several examples of process/workflow functions needed to define robust use cases are described below. During Phase 1, the use cases will be developed in detail and executed to test the TGD implementation.

Populate Data is a process that allows Field office data stewards to collect and load new or updated data. This may involve a number of defined procedures, such as GPS or field survey, photogrammetric mapping, or digitizing from paper maps. New data may be collected, but most work will be updates of existing data. Each Field office will maintain its own data to meet local business requirements and can collect and populate trails data using their existing data model or may opt to adapt to the new data exchange standard. The data exchange standard will define the core data content aggregated by Bureau and DOI TGDs. Data population processes will assure minimum data quality and conformance to the standard. The TGSA plan will identify, test, and implement best practices for systematic population of trails data. Export Data is a process/use case that allows Field office data stewards to transfer local TGD data to the Bureau or DOI TGD. The general process for transferring data from one dataset to another is called Extract, Transform, and Load (ETL). The steward will select the data to be transferred and export into the data exchange standard for ingestion into the enterprise TGD (Extract and Transform). The enterprise TGD manager will then aggregate (Load) and QA/QC the data into the enterprise TGD (see below). The procedure will be driven by a transformation template or tool provided by the Bureau or DOI. The Export Data use case will transfer a

23

complete or updated TGD subset based on changes, geographic extent, feature type, or other selection criteria. Export Data will follow the Populate Data process.

Aggregate Data is the process/use case that allows the dataset manager for the Bureau or DOI TGD to combine or aggregate the data transmitted from Field offices into an enterprise dataset or enterprise TGD. Aggregate Data includes the following activities:

Archive – Prior to aggregation the existing enterprise TGD will be backed up for roll back requirements and archived for records retention. Validate & QA/QC – Will check for errors or discrepancies including spatial and attribute errors. This may include routine data adjustments or return to the steward for rework. Accept – Trails dataset submitted by the Field office accepted into the enterprise TGD. Simplify & Generalize - Lowering resolution/smaller scale representations only if required. Load and Verify – Field data are integrated into the enterprise TGD and systematically checked for agreement with the submitted dataset and the enterprise dataset. Update Metadata – information about updates added to the metadata as the enterprise TGD aggregation steps occur.

Synchronize Data process/use case formally publishes the aggregated Field office TGD updates in the DOI TGD. After the Field office data are aggregated into the DOI TGD, the DOI data steward will publish synchronization updates. Synchronized updates will allow related databases to refresh their content. This is a very important procedure among distributed databases that allows the trails community to consume the entire TGD in addition to data managed locally. At a national scale, all locations will share a common TGD. Synchronize Data may be executed on a frequency determined by the Field and Bureaus dataset managers. As the enterprise data quality/quantity and workflows mature, synchronize update events will become more frequent or automated. The Synchronize Data will be an automated database process and aggregation/synchronization/update will happen as change occurs and is documented. Serve Data process/use case allows dataset managers at the DOI TGD to publish content of the TGD to consumers. This will include standards-based services (e.g., map services, feature services) that allow consumers to utilize trails information in a Service Oriented Architecture [1] environment. Services must be discrete functional units that can be discovered, accessed, and used in a highly distributed network environment that supports a variety of clients and applications. Bureau and Field offices may also serve data and at this time, some services already exist. These can be published as a service catalog. The scale and scope of the enterprise services and applications will be determined in subsequent phases of the TGSA.

Change Management process addresses the need of stewards and dataset managers to request and potentially gain approval for modifications of documented processes, workflows, data standards, or database schema. The change management process prevents uncontrolled changes to the TGSA and TGD and protects partner investments. As data and business requirements evolve over time, the TGSA will need to adapt to meet changing mission needs. Changes to the operational system will be submitted to the designated change manager, and depending on the scope, may be referred to a change board for research and recommendations before a final decision by the change manager. The result(s) of the change request will be documented and shared with the requestor(s), the TGSA community, and the DOI TGD Manager to effect any approved changes. Careful change management aligns with the governance and stewardship (Section 3.1) to ensure continuity of operations for all

24

participating organizations and sustainable data services to meet current, legacy, and future data requirements. Best practices for change management are defined by the IT Integration Library (ITIL) [29].

These processes/use cases are the core support elements for the TGSA workflows. Figure 5 illustrates the workflow among the process/use cases. During the plan implementation, the processes and workflow will evolve as the stewardship, standards, and data models mature.

3.4 Trails Geospatial Solution Architecture Roadmap Many solution architectures are currently moving forward within DOI. The TGSA Roadmap (Figure 3) follows the DOI Target Solution and Application Architecture [1] designed by the CTOC (Figure 2). This document only outlines work through Phase 1 of the TGSA. Combined training and publication of the results are required for all phases and steps listed below. The Roadmap phases include:

Phase 1 –the TGSA will demonstrate proof of concept, develop and test required standards/design/workflows, and address risks in three general steps:

1. Planning & Strategy [20] - Expand upon the previous surveys with additional Field offices from each DOI Bureau and available data from TNM. Deliverables will include:

a. a full inventory of DOI trails data assets, b. input from additional Field offices, c. tactics for resolving identified issues (Section 2.3), d. identify data stewards and communicate roles and responsibilities (Section 3.1),

and e. establish stewardship governance structure including data stewardship advisory

committees and integration of the trails community of interest. 2. Analysis & Design and Development [20] - Develop standards and data model to meet

business requirements and address the issues listed in Section 3.2. Deliverables will include:

a. data exchange standard, b. published logical and physical data models (Section 3.2), and c. documentation for processes and use cases (Section 3.4).

3. Deployment and Operations & Maintenance [20] - Implement a Trails Geospatial Dataset (TGD) for a coordinated, simplified, and seamless national EGIS for trails. Deliverables will include:

a. documentation of the DOI TGD in accordance with the DOI ADS [18], b. the enterprise geodatabase plan and associated data services, c. recommendations and plan for publication services via The National Map (TNM), d. identify performance metrics and informally track during Phase 1, and e. recommendations for the TGSA Phase 2 including formal performance metrics.

Phase 2 – the first adopter phase will achieve trails capability in one DOI Bureau (first adopter candidate is NPS). Based on Phase 1 products, lessons learned, and available resources Phase 2 will plan and implement a new project to extend the TGD to one or more DOI Bureau implementations. Phase 3 – expansion phase will achieve trails capability to all DOI Bureaus. Repeating Phase 2 for each of the other Bureaus will allow DOI to approach a steady state of the architecture [1]. Work completed on Phase 1 and 2 will guide project planning and implementation.

25

Phase 4 – evaluation and integration of other Federal partners, esp. USFS. Recommendations for how to proceed on Phase 3 will be provided by the work completed on Phase 1, 2, and 3. Phase 5 – evaluation and possible integration of State, local, and private data resulting in a seamless national database for trails.

The first step for the TGSA implementation is the TGSA or Phase 1 listed above. The TGSA will provide “the opportunity to learn the ‘what and how’ of implementing [geospatial] services at the DOI [1].” TGSA will also document the time and effort spent on the implementation, the value of the TGD, and concrete examples of reusable services for projects and program applications. 4.0 Summary The DOI Geospatial Modernization Blueprint (GMBP) [3] recommends an authoritative seamless geospatial enterprise Trails Geospatial Dataset (TGD) as a test case for documenting requirements, business processes, and costs for investing in a DOI-wide geospatial dataset. Consequently, the EGIM Team developed this Trails Geospatial Solution Architecture (TGSA) plan based on DOI Target Solution and Application Architecture recommendations [1]. The roadmap for full implementation of the TGSA includes 5 phases (Figure 3) that encompass the three objectives: Data Stewardship, Data Standards, and Data Processes and Workflows. These phases include:

Phase 1 – Proof of Concept - Expand upon the previous surveys to gather more comprehensive requirements, define governance, stewardship, standards, and processes/workflows, plan and implement enterprise stewardship and publication services. Phase 2 – First Adopter - Implement the governance, stewardship, standards, and processes/workflows objectives. Phase 3 – Expansion – Develop a TGD DOI-wide in conjunction with enterprise stewardship and product delivery. Phase 4 – Evaluation & Integration – Expand to include other Federal Partners. Phase 5 – Evaluation & Integration – Expand to State, Local and Private Trails.

26

Figure 6 – Timeline showing current conditions of trails distributed across the landscape integrated with the roadmap and phases for the Trails Geospatial Solution Architecture (TGSA). The goal of this plan is to create, maintain, and serve a well-coordinated authoritative seamless geospatial enterprise trails dataset.

Phase 1 consists of a TGSA developed in three steps: 1) expand upon previously gathered requirements, 2) develop standards and database models, and 3) deliver a TGD for DOI. Results and lessons learned from Phase 1 will define and guide decisions for future Phases 2, 3, 4, & 5 (Figure 3 & Figure 6).

The EGIM Team [4] collected input from selected Field offices and subject matter experts (Section 2.1), developed a Return on Investment (ROI) to evaluate the investment (Section 2.4), and reviewed two DOI enterprise systems: NILS [7] and NHD [8] / WBD [9] (Section 2.2), for this effort a federated approach similar to NHD/WBD may be the most effective.The research found numerous issues that the TGSA must address (Section 2.3), but also enabled development of data requirements and a basic concept of operations (CONOPS) for the TGD (Section 2.5). The CONOPS outlines the stewardship needed for successful management of an enterprise dataset (Section 3.1) and the alignment with OMB Circular A-16 [19] and Supplemental Guidance [23]. The required data are defined in two categories: Geospatial elements (geometric features) and Attributes (tabular business data). An initial task for the TGD is definition of data exchange standards upon which the logical data and physical data models are based (Section 3.2). Data management processes, workflows, and use cases are presented in Section 3.3. The CONOPS will be developed and implemented in this TGSA plan. Although, this plan only represents Phase 1 of the TGSA Roadmap (Section 3.4, Figure 3, and Figure 6), subsequent phases are identified to complete this powerful test of the GMBP methodologies [3]. This plan establishes the common goals of developing an authoritative seamless geospatial enterprise trails dataset, the Trails Geospatial Dataset (TGD), as part of a DOI Trails Geospatial Solution Architecture (TGSA) managed within the DOI geospatial portfolio. The TGSA will be the Authoritative Data Sourse for trails in DOI.

27

Appendix A – Acronyms and Abbreviations

ADS Authoritative Data Source BLM Bureau of Land Management CIO Chief Information Officer CONOPS Concept of operations CTOC Chief Technology Officer Council DOI Department of the Interior DOT Department of Transportation EGIM Enterprise Geographic Information Management EGIS Enterprise Geographic Information System EPA Environmental Projection Agency ETL Extract, Transform, and Load FGDC Federal Geographic Data Committee FSAM Federal Segment Architecture Methodology FTDS Federal Trail Data Standards - formerly ITDS GeoLoB Geospatial Line of Business GIS Geographic Information System GITA Geospatial Information and Technology Association GMBP Geospatial Modernization Blueprint GOS Geospatial One-Stop GPS Global Positioning System IT Information Technology ITDS Interagency Trail Data Standards - now FTDS ITIL Information Technology Infrastructure Library NED National Elevation Dataset NHD National Hydrography Dataset NHT National Historic Trail NILS National Integrated Lands System Geocommunicator NPS National Park Service NRCS Natural Resource Conservation Service NRT National Recreation Trail NST National Scenic Trail OMB Office of Management and Budget RDBMS Relational Data Base Management System ROI Return on Investment SA Solution Architecture TGD Trails Geospatial Dataset TGSA Trails Geospatial Solution Architecture TNM The National Map USDA United States Department of Agriculture USFS United States Forest Service USFWS United States Fish and Wildlife Service USGS United States Geological Survey WBD Watershed Boundary Dataset

28

Appendix B – Definitions Attribute: A characteristic of a map feature providing additional information, typically stored in a table that is linked to the map feature by an assigned identifier. For example attributes of a trail, represented by a line, might include trail surface (e.g. – dirt, gravel, asphalt, etc.), trail name, trail number, etc. Bureau office: For this document, the term Bureau is an office at a DOI Bureau (NPS, BLM, BOR, FWS, etc.) or within a logical subdivision, with responsibility for aggregation and administration of trails data from the Field offices. Enterprise Architecture: A process and framework that leads to the development, implementation, maintenance, and use of a “blueprint” that explains and guides how an organization’s business practices, information technology, and information management elements work together to accomplish the mission. AND a comprehensive framework used to manage and align an organization’s business processes, information technology software and hardware, local and wide area networks, people, operations and projects within the organization’s overall strategy [1]. Geospatial: For this document, the combination of digital geographic data created using software and hardware to support the business requirements of trails. Field office: For this document, the term Field office is used to represent an office, location, department, etc. that have responsibility to perform trails activities. The Field has front-line responsibility to collect, update, and maintain these data. It is responsible for the completeness, accuracy, and currency of the data that is published to the TGD. Foundational Data Model: A data model containing geospatial information or features including geospatial centerline, length, unique identifier and key relational elements. Information Technology Infrastructure Library (ITIL): A set of concepts and policies for managing information technology, infrastructure, development and operations. Return on Investment: A performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. To calculate ROI, the benefit (return) of an investment is divided by the cost of the investment; the result is expressed as a percentage or ratio. Solution Architecture: Defines the end-to-end information technology solution to a particular business problem. It covers both functional aspects as well as operational aspects. This is the basic foundation tying the rest of the architectures together to provide the right solutions for solve[ing] DOI business challenges. AND Patterns and practices used to create a product or service that will allow a particular business task to be accomplished [1]. The National Map (TNM): This is a collaborative effort among DOI USGS and other Federal, State, and local partners to improve and deliver topographic information for the Nation. TNM includes orthoimagery (aerial photographs), elevation, geographic names, hydrograpy, boundaries, transportation, structures, and land cover. This is foundational to implementation of the DOI Geospatial Modernization Blueprint and meeting the DOI mission to America. TNM offers web-based display and download of products and services. By leveraging existing programs such as TNM, DOI will reduce the barriers to using these data, increase business demand, and reduce delivery costs [3]. Trails Dataset: Are information generated by offices to support business requirements for tracking and maintaining trails under their management. Trails Geospatial Dataset (TGD): At the top of the hierarchy is the DOI TGD. For this document, the Trails Geospatial Dataset (TGD) includes the simplified attribute information for trail centerlines or corridors, herein referred to as trail centerlines, and other information generated by Field and Bureau offices.

29

Bureau TGDs may also exist to support Bureau business requirements by extending the data model to meet their business needs. Field TGDs will support Field office business requirements by extending the data model to meet their business needs.

Trails Geospatial Solution Architecture (TGSA): For this document, the Trails Geospatial Solution Architecture is the Solution Architecture for trails within DOI. This includes the TGD and all related services.

30

Appendix C - References

1. US Department of the Interior, 2006, Target Solution and Application Architecture – Service Oriented Integration Center of Excellence, Chief Technology Office Counsel (CTOC).

2. Executive Office of the President of the United States, CIO Council, 2008, Federal Segment

Architecture Methodology, Available at: http://www.fsam.gov/about-federal-segment-architecture-methodology.php

3. US Department of the Interior, 2007, Geospatial Modernization Blueprint: Recommendations and

Architectures, Public Version, p. 99. 4. US Department of the Interior, 2008, Enterprise Geographic Information Management, Fact Sheet.

Available at http://www.nps.gov/gis/egim/documents/2008_1223_EGIM_Factsheet.pdf 5. FGDC, 2008, Federal Trail Data Standards (Public Review Draft), Standards Development Group,

p. 126. Available at http://www.fgdc.gov/standards/projects/FGDC-standards-projects/trail-data-standard/

6. United States Code, 2009, The National Trails System Act, P.L. 80-543, as amended through P.L.

90-543, as amended through P.L.111-11, March 30, 2009, Volume 16, Sections 1241-1251. Available at http://www.nps.gov/nts/legislation.html

7. Bureau of Land Management, 2007, National Integrated Land System (NILS) Automated

Authoritative Data Source Pilot Report (Draft); See also: Bureau of Land Management, 2007, National Integrated Land System Overview. Available at: http://www.blm.gov/wo/st/en/prog/more/nils/general_info/nils_overview.html

8. US Geological Survey, 1999, The National Hydrography Dataset, Fact Sheet 106-99 (April 1999)

Available at: http://egsc.usgs.gov/isb/pubs/factsheets/fs10699.html 9. Natural Resources Conservation Service, 2000, Overview and History of Hydrologic Units and the

Watershed Boundary Dataset (WBD). Available at: http://www.ncgc.nrcs.usda.gov/products/datasets/watershed/history.html

10. Executive Order 13195, 2001, Trails for America in the 21st Century, p. 3. Available at:

http://www.fs.fed.us/cdt/management/trails_for_america_executive_order_13195_jan_2001.pdf 11. Geospatial Information and Technology Association, 2007, Building a Business Case for

Geospatial Information Technology: A Practitioners Guide to Financial and Strategic Analysis, support for this work provided by the American Water Works Association Research Foundation, the FGDC, and GITA. Available at: http://gita.org/gita-in-action/roi_workbook.asp

12. US Department of the Interior, 2007, Business Case: Department of the Interior Trails Locations

Return on Investment, Prepared for the Enterprise Geographic Information Management Team. 13. Bureau of Land Management, 2000, National Integrated Land System Overview - Concept of

Operations and User Requirements, Available at: http://www.blm.gov/wo/st/en/prog/more/nils/business_requirements/concept_of_operations.html

31

14. US Geological Survey, 2002, National Hydrography Dataset, Frequently Asked Questions 9/24/2002. Available at http://nhd.usgs.gov/nhd_faq.html#q118

15. US Geological Survey, 2007, The National Hydrography Dataset, Stewardship Process. Available

at: http://webhosts.cr.usgs.gov/steward/st2process.html 16. Natural Resources Conservation Service, 2000, Information about Hydrologic Units and the

Watershed Boundary Dataset (WBD). Available at: http://www.ncgc.nrcs.usda.gov/products/datasets/watershed/datainfo.html

17. US Geological Suravey, 2009, Federal Standards for Delineation of Hydrologic Unit Boundaries,

Chapter 3 of Section A, Federal Standards Book 11, Collection and Delineation of Spatial Data, Techniques and Methods 11-A3, p. 65 Available at: ftp://ftp-fc.sc.egov.usda.gov/NCGC/products/watershed/hu-standards.pdf

18. US Department of the Interior, 2008, OCIO Directive 1008-020, Designation, Management, and

Enforcement of Authoritative Data Sources (ADS), p. 9. 19. Executive Office of the President of the United States, Office of Management and Budget, 2002,

OMB Circular A-16, Revised, August 19, 2002. Available at http://www.whitehouse.gov/omb/circulars/a016/a016_rev.html

20. Project Management Institute, 2004, A Guide to the Project Management Body of Knowledge,

Third Edition (PMBOK Guide), Project Management Institute Global Standard, 390 pages. 21. Department of the Interior, 2008, Data Quality Management Guide – Office of the Chief

Information Officer, p. 70. 22. Department of the Interior, 2006, OCIO Directive 2006-011, Data Standardization Procedures, 2 p.

Available at: http://www.doi.gov/ocio/architecture/documents/2006-011%20Data%20Standardization%20Procedures.pdf

23. Executive Office of the President of the United States, Office of Management and Budget, 2008,

OMB Circular A-16 Supplemental Guidance, p. 96. 24. Teorey, T.J.; Lightstone, S.S; and Nadeau, T., 2006, Database Modeling and Design – Logical

Design 4th Edition, Morgan Kaufmann Title, 296 pages. 25. Lightstone, S.S; Teorey, T.J.; and Nadeau, T., 2007, Physical Database Design – The Database

Professional’s Guide to Exploiting Indexes, Views, Storage, and More. Morgan Kaufmann Title, 448 pages.

26. Federal Geographic Data Committee, 1998, Content Standard for Digital Geospatial Metadata,

Metadata Ad Hoc Working Group, p. 90. Available at: http://www.fgdc.gov/standards/projects/FGDC-standards-projects/metadata/base-metadata/v2_0698.pdf

27. Federal Geographic Data Committee, 2006, Geospatial One-Stop—Encouraging Partnerships to

Enhance Access to Geospatial Information, Factsheet p. 2. Available at http://www.fgdc.gov/library/factsheets/documents/gos.pdf (Main Web site at http://gos2.geodata.gov/wps/portal/gos)

32

28. Executive Office of the President of the United States, 2009, DATA.GOV. Available at:

http://www.data.gov/

29. Behr, K.; Kim, G.; and Spafford, G., 2005, The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps, IT Process Institute.

33

Appendix D – DOI Solution Architecture Principles DOI Solution Architecture Principles: [1]

• Flexibility – The DOI will implement service-based application software that is independent of hardware platforms, that is loosely coupled to infrastructure services, that places reasonable demands on networks used for communication, and that places minimal demands on users of the application.

• Efficiency – The DOI will create designs that reduce cost and implementation time, minimize human intervention to present continuous and reliable operation, and reduce users-training requirements. The architecture promotes user interfaces that optimize the nature, efficiency, and effectiveness of the human operator.

• Usability – The DOI will implement easy-to-use solutions, accessible by people with disabilities, which solve DOI business needs and provide needed information to the public.

• Balance – The DOI will implement IT systems that provide availability and accessibility with the appropriate level of security. Security shall be designed into all architectural elements, balancing accessibility and ease of use with data protection commensurate to the determined risks.

• Reuse – The Interior Solution Architecture, by creating standard application structure and leveraging service-oriented architecture, provides the foundation for the reuse of assets, including the solution architecture; business, data, application, and run-time patterns; and business and infrastructure services. Reuse of assets is key in reducing cost by eliminating redundant systems and promoting best practices across the department.

34

Appendix E – Research Documents Note: The acronyms used below may be used differently from the rest of the document due to the survey being created prior to the final report.

Trails Survey:

List of Questions for Trails Case Study Name: ______________________________________ Organization: ________________________________ Date: ________________ Basic Questions

• What is/are trail data set that your organization create, maintain and use? • What is the lifecycle of trail data creation, maintenance, and use? • What business functions in your organization associated with trail data? • What is/are the current issues in trail data creation, maintenance, or use? (technical and non-

technical) • Who has a stake in trails data:

o Who are producers o Who are consumers (internal and external)

• What is the expectation of your trail data user? o What if you cannot fulfill the expectation?

• How often do you receive requests for trails data (machine readable)? Extended Questions User Needs What business functions does the information support?

• Critical infrastructure • Budgeting • Law Enforcement and Safety • Maintenance • Legal/cadastral (easements, rights of way…)

Who are the consumers (users)? Can the business functions be associated with them? • Federal • State • Local • Public

Where are the consumers in relationship to the producing (authoritative) organization?

• Internal to the organization • External to the organization

What information (geospatial and business) do the consumers need for the business functions? E.g. in the trail data modeling: trail on public/private, track ownership, get permission from the land owner Is there a concept of operations for how the Trails data are used?

• Any supporting documentation The Trails Information Product (Assume the draft FGDC data model is being recommended as the standard for DOI) Is the organization familiar with the ITDS (Interagency Trails Data Standard?) Has the model been evaluated for suitability for the required business functions?

35

Have the information sources for each data element been identified? Once the business functions and information needs are defined, how is the information acquired? Purchased? Contracted? Produced in-house? What information is/could be derived from other sources (state/local gov’t, other DOI, other federal agencies)? Information Production and Maintenance (Please use examples if they help to describe your answer) Is the organization an authoritative data source for a collection of trails data? Does every organization have their own system for maintaining their Trails data? Do organizations share information or collaborate in any way? If so, how? How would the rate of change of Trails data be characterized? How are changes managed?

• Geography updates (new trails, closed or abandoned trails, realignment, etc?) • Status- open, closed, • Ownership and jurisdictions • Budget and planning- maintenance, etc. • Does the Trails system consume external information or duplicate it into the data model? If so,

how? If data are duplicated, how are changes/updates handled?

What is the staffing level for Trails data maintenance at the organization? How much effort (work months, or FTE or $) is expended on Trails information maintenance each year (per producing organization)? Is the level of effort adequate? How often is the data updated? (As changes occur, weekly, monthly, etc) Are data maintenance procedures and workflows documented? Are data currency and accuracy requirements documented? What production/update methods are used (outsourcing, survey, GPS track, photogrammetry, etc) What is the preferred/desired production/update method? Information Consumers Category 1: Consumers that use the Trails information Product for decision support- maintenance and planning

• What applications do these consumers use? • Does the organization provide the applications along with the Trails information product

Category 2: Consumers that use the Trails information Product for value-added products (environmental analysis, use studies, risk assessment, law enforcement, fire, search and rescue, etc.)

• What applications do these consumers use? • Does the organization provide the applications along with the Trails information product

Category 3: Consumers that use a published product (map) Recreation, trail maintenance…

• What applications do these consumers use? Publishing and Dissemination How does the organization publish their Trails data? Is the published data segregated from the production data in any way or is everything done from the same database? Is the Trails data sent to any other DOI organizations?

36

Is the Trails data sent to a common national trails data store (data warehouse) What access methods are provided (web maps, pdf, web services, ftp?) To what extent is the existence and availability of the trails data made available (organization, bureau, Department, other federal, public) IT Get description of the maintenance system architecture:

• Client/server? • N-tier • Centralized or distributed? • Number of editor/maintenance users? • Number of consumers (web and data sets) • Continuity of operations? • Availability? • Data backup/recovery • Network connectivity and bandwidth • Data warehouse or other external repository • What technology is used • What IT standards? • What geospatial standards? • Security?

Any other current issues in trail data creation, maintenance, or use?