GIS

From EITLC Wiki

Contents 1 Rating of this issue is closed 2 Implementing a GIS solution at Ohio EPA 2.1 1.1. Purpose 2.2 1.2. Scope 3 EXECUTIVE SUMMARY 4 RECOMMENDATION Rating of this issue is closed Thank you for providing your ratings on this issue as a potential focus for an EITLC Priority Action Team. Results of voting and top issues will be announced shortly.

Implementing a GIS solution at Ohio EPA

1.1. Purpose

This document is the result of a GIS Services Evaluation by the State of Ohio, Department of Administrative Services Office of Information Technology GIS Support Center (GISSC) for the Ohio Environmental Protection Agency. The GISSC appreciates the time OEPA staff has spent with us to help us understand the critical GIS issues faced by OEPA. The Services Evaluation document captures the vision we have jointly created outlining how the GISSC can assist OEPA in confronting their critical issues vis-a-vis GIS implementation.

1.2. Scope

This document includes the executive summary of the Ohio EPA GIS Service Evaluation and Recommendation. More information can be obtained by writing to the Office of Information Technology Services, Ohio EPA.

EXECUTIVE SUMMARY

OEPA engaged the GISSC to develop an evaluation of current GIS activities and provide recommendations and solutions for spatial data management within the existing framework maintained by the GISSC. The project goal was to define and prioritize the optimal service capabilities of the GISSC to support the internal and external GIS requirements of the OEPA. The deliverables from this project provide the necessary information to budget and plan the migration of GIS services from OEPA to the GIServOhio Spatial Data Platform hosted by the GISSC.

In order for OPEA’s GIS Services migration to be fully successful it must be effectively aligned with the business needs, efficiently implemented with best practices and methodologies, and innovative in applying best of breed technology customized to OPEA’s business environment. The Services Evaluation specifically addresses the first criteria, which is ensuring that the OEPA plan is effectively targeted toward business justified strategic processes. The three OEPA Divisions evaluated were:

• Division of Drinking and Ground Waters (DDAWG)
• Division of Emergency and Remedial Response (DERR)
• Division of Surface Water (DSW)

Ohio EPA’s mission is to protect the environment and public health by ensuring compliance with environmental laws and demonstrating leadership in environmental stewardship. To accomplish that goal, it is important that OEPA consistently regulate Ohio’s environmental laws. To align with the overall organization mission, the OEPA project must support business processes that enable cost-effective service delivery while maintaining program efficiencies and system performance. Both individually and as a whole the OEPA migration will assist the department in obtaining improved cost effective GIS business processes.

The GISSC evaluation team met with representatives from each of the identified divisions as well as IT and database administration staff in focus sessions to obtain the information necessary to establish a high level evaluation for an OEPA and establish the feasibility for applying OEPA technology to OPEA’s information technology requirements. OEPA staff provided what is believed to be a current and valid representation of OPEA’s business requirements for geospatial information technology, and as such, the focus sessions served as the basis for the Services Evaluation project.

Through these business user focus sessions the business processes, spatial data needs and feasibility for each of the three OEPA Divisions was refined. Based on the needs expressed in this phase, the National Hydrography Data (NHD) set was selected as the first OEPA population project to demonstrate the GIServOhio capabilities to OEPA staff. The DERR application, having the most interaction with internal database systems was selected to serve as the prototype application to demonstrate the feasibility and performance capability of the OEPA project.

RECOMMENDATION

At the Ohio EPA, Central office GIS Coordinators provide GIS data and technical support for GIS in districts and GIS support for Ohio EPA Division Programs. User levels vary from browser-based data viewing to complicated surface water modeling. Coordinators supply data, technical support and cartographic products to the public upon request.

GIS activity within OEPA is primarily analytical in nature making extensive use of location information collected and maintained within business tables residing within Oracle, SQLServer and Access databases. The business data is routinely extracted and processed to generate spatial features for display and analysis in various internal and external GIS applications. GIS Coordinators within each division are responsible for the generation of the feature data sets and the population of the centralized spatial data repository. The repository is accessible by central office personnel through direct connection to the database and to District office staff through terminal services to a centralized GIS application server for maintenance and analysis. Bandwidth limitations to the District offices prevent district staff from interacting directly with the centralized data repository for local project work. As a result duplicate copies of the centralized data repository are routinely distributed to district offices in a loosely regulated process that varies by the business requirements of each division. Each division’s district offices work semi-autonomously, interacting as necessary with local agencies to obtain current spatial data to support specific project level needs.

OEPA has adopted the use of ESRI Spatial Data Engine, and an Oracle RDBMS. OEPA maintains an Internet presence making use of Arc Internet Map Server and Google mash up capabilities. Demand for custom mapping while sporadic requires a significant amount of staff time to prepare and execute.

Common areas of concern:

• Cost of maintaining the data, software and equipment
• Cost of obtaining, loading and maintaining spatial data from other agencies
• Rapid rate of change in software capabilities and program mining requirements
• Lack of resources to implement an enterprise/distributive data management for GIS
• Existing performance issues with centralized data storage,
  • Bottle necks
  • Inadequate Bandwidth

The GISSC maintains a hardware, software and service delivery platform called GIServOhio capable of supporting the spatial data needs of the OEPA. GIServ is a service-oriented platform delivering spatial data applications and services to end-users client applications.

The GIServOhio platform consists of a 3 tiered architecture of Web, Application, and Database servers and storage devices providing development, test and production environments. The recommended configuration for the OEPA SDN maintains existing development capabilities within OEPA to provide GIS Coordinators with complete control over the data development, map service design and map project creation and modification functions to support District Terminal Services clients. In addition a virtual application development environment within GIServ could be made available to OEPA Division GIS Coordinators for GIS application development activities within the OIT supported software development environment.

The recommended approach for OEPA is the design and construction of an OEPA Spatial Data Node (SDN) residing within GIServ as presented in this section. The approach is based on the methodology that is utilized globally in the design and construction of the GIServOhio platform within OIT.

The recommended design will leverage the significant capabilities of the existing Oracle- based solution for maintaining OEPA business data while offloading spatial data administration, storage and distribution activities to a hosted service delivery environment. The envisioned SDN will provide all OEPA GIS staff with access to centrally maintained Enterprise Spatial data, maintain existing terminal services map project editing capabilities and linkages where appropriate, and provide external users with the opportunity to connect to OEPA services for display and query. The proposed architecture and process will retain edit and layer development capabilities of the Division GIS Coordinators and to an extent preserve the autonomy of the individual divisions with regard to software versions and project development.
A OEPA Geodata Service will provide OEPA users the ability to interact with the Enterprise OEPA geodatabase through local area network (LAN) or the Internet connections to establish and maintain local replicas as a file geodatabase. An OEPA Map Service will provide all users with access to centrally maintained spatial data assets, providing the user with the ability to extract data and execute queries in the geodatabase. These capabilities will meet the immediate needs of OEPA by providing access to spatial data using hosted map services while maintaining existing connectivity to business tables and persistent tabular joins with the redirection of data source pointers defined in existing user developed ArcGIS map documents (MXD).

Although the suggested Terminal Services editing environment remains intact, the Geodata Service will provide OEPA with options to explore the viability of remote editing and geodatabase replication in the future. Whether replication is used as a one-way data download source or a two-way editing solution, district offices will maintain optimal performance by users working from locally stored personal, file-based or ArcSDE geodatabases. While not critical to the immediate needs expressed by the divisions, the capacity to implement this feature incrementally to address remote access and performance issues with bandwidth limitations is a definite benefit of the Geodata Service solution.

The remaining recommended process steps for OEPA SDN development:

• Develop a detailed OEPA SDN Architecture that covers Data, Application, Technology and Support Architectures.
• Proceed with an OEPA SDN data selection to determine what data will be included in specific phases of the SDN.
• Once the Architecture has been defined, develop the OEPA SDN Implementation Plan which will identify in detail what the first 5 phases of SDN development will include.
• Proceed with the Detailed Design and Implementation of the SDN.

The project phases identified over a 8-10 month period will include:

• Implementation
• Time Frame
• Phase Evaluation Supported Data Description

1. (1 –2 months) Proof of Concept
2. (1 –2 months) Operational Data Store
3. (2-3 months) Supporting Data Store
4. (3-4 months) Service Development
5. (2-3 months) Editable Data Store
6. (TBD) Tool/Application Development

As the iterative process continues, additional data elements will be selected from the existing input systems, in addition to the new source data added. The order of the population projects above was determined from the analysis of the Evaluations reviewed during the current phase. Implementation of individual phases can run concurrently as resources and conditions warrant.