Ali Diba, Joe Chapa, Michael Inada, Nancy Lin, Marie Pietrucha, Tim Scharff

An Interface for Retrieval and Analysis of Hydrologic and Water Quality Data

This paper describes the development of an ArcView based user interface to retrieve and analyze the data stored in the Hydrometeorological and Water Quality Databases for South Florida Water Management District. These databases reside on District's Oracle rdbms servers and are used by district staff and engineers from SUN workstation clients. The papers describes the design and the implementation process with emphasis on connectivity between ArcView and Oracle.


Background

South Florida Water Management District is located in West Palm Beach, Florida. The District's area of responsibility extends approximately over 16 counties from Orlando to Key West, serving a population of over 5.4 million people. The geographic region spans an area about one-third the size of the state of Florida and encompasses vast area of agricultural lands, water conservation areas, many water bodies, and areas of enormous growth and development.

The Mission of the District is mandated through legislation and is to monitor and protect the natural resources in South Florida. The District responsibilities include managing flood control, providing water supply, preventing salt water intrusion, encouraging responsible agricultural and urban development, and preserving fish and wildlife habitat. Additionally, the District is responsible for protecting the Everglades and acts as local sponsor for federally funded and authorized projects. The District currently employs more than 1,600 employees to accomplish this mission.

District's mission is accomplished through the combined efforts of planning and research, operations and maintenance, community and government relations, land management, regulation, and construction. These groups collect and maintain substantial amount of data that is ultimately used in support of carrying out the Agency's Mission. For example, decision support and environmental modeling activities rely on availability of water quality and quantity data for the regions in question.

District has selected ArcInfo Geographic Information System and the Oracle relational database management system in 1989 as the software tools for display, analysis, and maintenance of the data collected by different groups. District's system is comprised of a networked, distributed GIS with more than 58 floating ArcInfo and ArcView licenses.

Based on the findings of an internal study conducted in 1993-1994 regarding GIS Graphical User Interface (GUI) for Oracle Databases, similarities between various District efforts were identified, and the goal of a unified interface for all District projects was agreed upon. The unified interface design included access to corporate databases, models and applications, and project areas. The corporate database component of the interface included the development of an interface to Hydrometeorologic, Water Quality, Permit, and Operations database. This paper describes the development of the Hydrometeorologic and the Water Quality databases which were included in the initial development phase.

System Requirements

The GUI requirements included development of a hierarchical cascading menu design for conducting the following steps:

Step 1 was a typical GIS operation for selecting a rectangular region (or polygon) based on one or more themes. In some instances, there may not be any specific coverage associated with the area but one may need to be developed dynamically. In case of water projects, the bounding rectangle that has all of the sampling points was to be developed dynamically based on the coordinate of the sampling stations.

Step 2 required development of specific GUI forms containing text fields, scrolled regions, and choice buttons to display the list of parameters that can be selected by the user.

Step 3 required processing a Structured Query Language (SQL) statement to retrieve the coordinates of the stations that matched the criteria. The retrieval was done against the summary tables in the database which contained statistical data such as period of record for any given station. The coordinate data was then used to dynamically construct a theme for display and selection purposes.

Step 4 was a typical GIS operation that included selection of one or more points from the displayed coverage using the cursor or from the associated point attribute table.

Step 5 required processing of an SQL statement to retrieve the actual time series data for the parameters that were selected in step 2. It is important to note the same SQL statement has to be processed for each selected station. For example, the pH had to be returned for 300 stations that were selected in Step 4.

Step 6 required formatting and display of the resulting data in a time series graphics package or for import into other systems such as Microsoft Excel and Hydrologic Engineering Center (HEC) DSS program.

Embedded in the above steps was the necessary requirement for maintaining multiple connections to several oracle databases while processing the data. Given the requirements above, a choice had to be made between ArcInfo or ArcView software to develop the user interface.

ArcInfo vs. ArcView

The original specification of the project called for development of the system using ArcInfo software. This was due to maturity of ArcInfo and the District's comfort level in building a core system which had future growth requirements using ArcInfo. A benchmark study was however conducted to identify the concerns that had to be addressed in order to implement the system in ArcView. The benchmark uncovered a number of issues which are specified bellow:

A prototype was developed to evaluate the design of the system based on ArcView. The above limitations were successfully addressed in the prototype which lead to the decision to switch the development platform to ArcView from ArcInfo.

System Design

The prototype identified the need for development of a number of tools to address the limitations of ArcView. In addition, it identified the need for a mechanism by which these tools can be controlled from within ArcView. The level of control and the feedback included starting a tool from ArcView, receiving and displaying messages from the tool inside ArcView, and obtaining and processing a message from the tool upon completion. The mechanism selected to implement these steps was the ArcView Remote Procedure Call (RPC) Server functionality.

By turning ArcView into an RPC Server, each tool could be invoked from within ArcView and could become an RPC Client in order to communicate back to ArcView. RPC turned out to be an excellent mechanism for controlling the tools that were needed to address the ArcView limitations.

The tools needed for addressing the ArcView limitations included a Hydrometeorologic and a Water Quality GUI RPC client, an Oracle Interface (OI) tool for efficiently processing queries, and a Formatter tools for processing the output data resulting from the query. The GUI RPC clients were implemented using native OpenLook widgets on SunOS. These tools allowed for display and selection of the query parameters by the user. The options selected by the user were then written into a data file for lookup by the OI tool.

OI was developed to provide cursor processing of an SQL select statement based on a parametric substitution of the user selected options. OI provided progress status (i.e., number of records retrieved) back to ArcView using the RPC mechanism. OI generated a standard output which could further be formatted using the Formatter tool.

The Formatter included support for generating output files for TSPLOT and XMGR-ACE/gr time series plotting packages, HEC DSS, and comma separated values. The Formatter was developed using a plug and play architecture to allow for adding support for future formats.

The time series plotting was done using several customized versions of public domain time series plotting software, i.e., TSPLOT and XMGR-ACE/gr. The key to enabling the linkage to these packages was the ability of the Formatter to format the retrieved data accordingly.

Figure 1 shows the data flow between the different components of the systems. This figure does not included the GUI servers as they are considered to be part of the ArcView interface.

data

Conclusions

Identification and evaluation of existing data is often the first and the most important task in conducting a water resources related project. By automating the search using a Geographical Information System based user interface one can eliminate the cost and effort involved in manually searching databases for the desired information. The approach described in this paper can be used to provide immediate feedback in terms of the state of a water resources system to the decision makers providing and sustaining the increasingly fragile water supply sources. From the software development point of view, this approach anchors on extendibility of ArcView to support capabilities that are otherwise not supported in the generic package.

Author Information

Ali Diba, PE
President
Diba Consulting Software Engineers
26980 Crown Valley Parkway
Mission Viejo, CA 92691
714.347.7585
714.347.7565
atd@dcse.com

Joe Chapa
South Florida Water Management District
3301 Gun Club Road
West Palm Beach, FL 33406
407.687.6391
407.687.6442
joe.chapa@sfwmd.gov

Michael Inada, PE
GIS Consultant
Diba Consulting Software Engineers
26980 Crown Valley Parkway
Mission Viejo, CA 92691
714.347.7581
714.347.7565
mci@dcse.com

Nancy Lin
South Florida Water Management District
3301 Gun Club Road
West Palm Beach, FL 33406
407.687.6391
407.687.6442
nancy.lin@sfwmd.gov

Tim Scharff
South Florida Water Management District
3301 Gun Club Road
West Palm Beach, FL 33406
407.687.6391
407.687.6442
tim.scharff@sfwmd.gov