# Presentation: 391200

## by Dianne Denson

Alaska Department of 
Environmental Conservation

***by Dianne Denson***
***Alaska Department of ***
***Environmental Conservation***

***Evolution of a Process --***
***Alaska’s STORET Data Entry Saga***

**Notes:**
Good morning.  My name is Dianne Denson and I am with the Alaska Dept. of Environmental Conservation  DEC for short.
I have been there just over a year and little did I know what I was getting in to!  

I was hired to implement STORET version 2 AND to implement the processes for moving Alaska’s water quality data into STORET.  And, as we say in the title of this presentation, this is our story ....

But, before I continue with our STORET saga, I would like to tell you a little bit about Alaska.

## About Alaska

**47,000 mi of shoreline**
**365,000 mi of rivers/streams**
**3 million lakes/ponds**
**55 million acres inland waters**
**170 million acres of wetland**
**1/3 of nation’s freshwater resources**
**1/2 of Alaska is wetland**

**Notes:**
Alaska contains approximately 47,000 miles of shoreline, twice the length of all other states combined.  Alaska has over 365,000 miles of rivers and streams, over 3 million lakes, reservoirs and ponds, and contains 55 million acres of inland waters, or approximately one-third of the nation’s freshwater resources.  There are approximately 170 million acres of wetlands in Alaska, which means that almost half of Alaska’s 365.5 million acres is considered wetland.  Alaska has more total wetland acreage than the total wetland acreage of the other 49 states combined. 

The area outlined by the red square shows what monitoring data Alaska DEC has in national STORET.

## Slide 3

**Notes:**
The federal government administers about two-thirds of the land in Alaska and employs twelve to fifteen federal agencies to carry out environmental monitoring and assessment activities.  There are 229 federally recognized tribes in Alaska.  

## Monitoring in Alaska

**Notes:**
DEC monitors water quality through the Alaska Clean Water Actions (319) grant process and through selected term contractors.  We also have been collecting data through EMAP, Environmental Monitoring and Assessment Program, for about 3 years.  DEC works with many non-profit groups throughout Alaska, providing financial and technical assistance for the monitoring, assessment and restoration of waterbodies.  
Each grantee is required to submit their monitoring and assessment data electronically to DEC so that these data can be uploaded eventually into national STORET.   The KEY WORD here is “EVENTUALLY” 
This is where the difficulty begins ..... historically the requirement to provide the data in a ‘STORET COMPATIBLE FORMAT’ has not been enforced, so we are faced with ....

## The Data “Challenge”

**INCONSISTENT   DATA FORMATS**
**Excel files**
**Text files**
**Printed reports**
**Floppy disks & CDs**

**Notes:**
Through various means, DEC has been collecting water quality data for OVER 30 years.  

The challenge has been, AND STILL IS, that the data is gathered, recorded and consequently delivered to DEC in many different formats – from text files on a floppy diskette or CD to paper reports.  This is true for DEC as well as for other State and Federal agencies.

## The Data “Challenge” (cont.)

**DIFFERENT TYPES of ORGANIZATIONS**
**Citizen volunteer **
**Government Agencies**
***State, Federal, Local***
**Contract Vendors**

**Notes:**
As well, the data comes from different types of organizations
Citizen volunteer groups
Government agencies such as city and borough governments, tribal governments and diverse federal and state agencies
Native organizations 
Contract vendors 
And, on a very limited basis, DEC also conducts internal agency specific monitoring activities
Each organization acts independently and there is little to no integration with the data collection efforts.  
And, because each organization’s funding sources may differ, many of the these groups generally have limited technical skills as well as dated computer equipment and software.  This provides an additional challenge with differing versions, lack of security, etc.
So, ....

## The Big Question

**How do we move data from these diverse sources and organizations into *****STORET*****  with as *****little PAIN***** as possible???**

**1999**

- Pain Gauge

**2000**

**2003**

**2002**

**2001**

**2004**

**Notes:**
In 1999, DEC made the decision to use STORET.  Since that time, the process for getting data INTO STORET has been fuzzy at best.  

## Re-think the Approach

**2000**

**1999**

**2003**

**2002**

**2001**

**2004**

- Pain Gauge

**Notes:**
Initially we started off gung- ho and were going to deploy STORET to everybody’s desktop.  We provided STORET training to the various monitoring organizations and thought we were off an running.  
However, after seeing STORET with all its complexity, the monitoring groups flatly refused to use the STORET Data Entry.  So, we decided to regroup and take another look at alternatives.

## Complete Needs Assessment

**   **_**Options / Recommendations**_
**Deploy Personal STORET to each organization**
**Deploy STORET Client -- Organizations would use STORET Client over State network**
**Provide SIM compatible Excel templates for organizations to enter their data**
***Deploy MS Access desktop application for data entry and STORET data export***

**2001**

**2000**

**2003**

**2004**

**2000**

**2002**

- Pain Gauge

**Notes:**
In 2001 DEC commissioned a Needs Assessment to determine the best means of implementing STORET in Alaska.
From the Needs Assessment, it was determined that there were 4 different approaches to implementing the STORET solution.   With each of these options, DEC did plan to have a central server-version of STORET for the State of Alaska....
Options --- Deploy an MS Access desktop application for groups to enter and store their data and subsequently, to send their data in a ‘STORET compatible format’ to DEC.  These data files would then be uploaded into Alaska STORET via SIM.
Each of these options has its advantages and disadvantages

## Personal / Client-Server STORET

**Advantages**
**Little up-front cost to DEC**
**Application is already developed and maintained by EPA**
**Disadvantages**
**Data entry is excessively cumbersome**
**Lack of technical expertise for Oracle installation (Personal or Client)**
**Poor performance over State network**

**Notes:**
The first two options, to deploy Personal STORET or the STORET Client, had similar options and disadvantages.
.........
In addition, with the STORET Client option, there was a potential for poor performance over the State network.

## Excel Templates for STORET

**Advantages**
**Simple to use**
**Most organizations already have Excel**
**Data provider can manage own data, ie. data entry, reporting, graphing, etc.**
**Disadvantages**
**No data validation**
**Disparate versions of Excel**

**Notes:**
The 3rd option was .......

This option was briefly considered in the Needs Assessment, but was rejected.

## MSAccess Desktop Application

**Advantages**
**Simpler to use than STORET**
**Most organizations already have Access**
**Monitor groups can manage own data, ie. data entry, reporting, graphing, etc.**
**Disadvantages**
**Requires development and maintenance by DEC**
***	******	******	******	******OR***
**Requires purchase of vendor application**
**Up front and ongoing cost to DEC and/or monitor organization**

**?**

***( MUST have ability to create SIM/STORET export files )***

**Notes:**
The final option was to provide an MS Access application for entering, storing, and exporting the water quality data. The objective was to provide an easier and less complex means of data entry for the monitoring groups.  The caveat with this option, is that the application needed to have the capability of creating export files that could be loaded into STORET via SIM.  
Advantages ....  At the time of the Needs Assessment, as far as DEC knew, there WAS NO Access application that could fill this functionality.  
Given the alternatives and the obstacles with each of the options, this is the option that DEC decided to implement.
So, the next step, of course, was to develop one .  Given that the monitoring data that was being gathered was not ‘complex’, how difficult could that be???  
Well, that is the crux of the story..... More on that later

## Proposed STORET Data Flow

**Monitors use common desktop tool to enter and store monitoring data**
**Desktop tool creates SIM/STORET compatible files for Projects, Stations and Results**
**Monitor organization sends export file (electronically) to DEC STORET Coordinator**
**DEC STORET Coordinator loads data file via SIM into Local STORET, then into Alaska STORET (server)**

**?**

***Oracle Server***

**STORET Data Coordinator**
**(Personal SIM & STORET****)**

**Notes:**
This slide shows a pictorial version of how we envision the STORET data flow process working.....

Monitors will use a common desktop tool to enter and store monitoring data ....

## Our Goal

**Provide a means for monitoring groups to**
** **
**Enter and store their data that is**
***SIMPLE***
***EASY-TO-USE***
***STANDARDIZED***** (a single method)**
**Send their data  *****electronically*****  to DEC in a SIM/STORET compatible format**

**Notes:**
So what did we do next??

## To Make a Long Story Short

**To Make a Long Story Short**

**Created SIM-DE (SIM Data Entry)**
**Provided training on SIM-DE **
**Monitoring organizations vote SIM-DE too difficult to use  ******
**Investigated collaboration with National Park Service**
**STORET Coordinator changes jobs  ******
**New version of STORET is introduced (v2.0)       (SIM-DE exports now are out of date)**
**Learning curve for new STORET Coordinator**
**SIM-DE updated but still incomplete ******
**Discovered DASLER-X application  ******

**2000**

**2003**

**2002**

**2001**

**1999**

**2004**

- Pain Gauge

**Notes:**
To make a long story short .... In 2002-3 we contracted to have an existing application modified to incorporate the required functionality for STORET data entry and SIM compatible export.  We provided training on the “completed” application but alas....those attending the training thought that SIM-DE was STILL too difficult to use and had incomplete functionality.  Meanwhile, the person in charge of STORET at DEC changed jobs and left the STORET Coordinator position vacant.  Nothing happened for several months.  When I was hired to fill the position, there was a learning curve and some lag time before we could re-group and decide how to move forward.  We decided to continue to work on SIM-DE and contracted for more work to be done.  The contracted work was still unable to complete the requirements and so SIM-DE is in limbo.

Summer of 2004, we learned of an application called DASLER-X...already developed, already had export capability for STORET Projects, Stations and Results – was in Beta release.

We volunteered to  test, and have been testing ever since.

## So What is the Plan?No ONE Way

**So What is the Plan?****No ONE Way**

**SIM-DE development on hold**
**Use DASLER-X MSAccess application**
**Convert / migrate data from MSAccess, Excel, paper**
**Hand-enter into STORET initial setup data for organizations**
**Provide Excel SIM import templates on DEC website**

**2004 -2005**

**2000**

**2003**

**2002**

**2001**

**1999**

- Pain Gauge

## THE END