Biological Field Data Collection Pilot
Report to ODOT GIS Steering Committee
Oregon Department of Transportation
Geographic Information Services Unit
The GIS Steering Committee approved The Biological Field data Collection Pilot
Project in December, 2004 and project specific activities were complete by
December, 2005. A final report to the GIS Steering Committee assessing both
successes and lessons learned was specified in the proposal and is contain
herein. Also included, for your reference, is a copy of the approved project
At the present time information gathered during and lessons learned from this
project are being applied to GPS Standards development as well as the
development of the Environmental Data Management System (EDMS). One of
the projects applications (Mitigation Site Monitoring) has recently been identified
as the primary data collection tool for use in a large site monitoring activity.
Experience from these continuing activities will be integrated back into the tools
via both GIS Unit staff effort and Consultant based activities.
Milt Hill, GISP
ODOT GIS Unit
Project Code Project Name Complexity
GIS-37 Biological Field Data Collection Pilot
Summarized Purpose & Objectives Sponsor/Title
Complimentary to GPS Standards currently in development, the Frannie Brindle
Biological Field Data Collection Pilot will implement GPS, field data Biology Team
collection and GIS based data check in/out technologies in a ‘real world’ Lead
ODOT setting. The objectives are twofold; one, to provide a field data Milt Hill
collection methodology to ODOT Biologists enabling them to build Environmental GIS
institutional knowledge and also, as specified in GIS 31, allow ODOT Project Manager
staff to assess current technology in the marketplace and become
familiar with potential solutions via ‘hands on’ trials.
A GIS/GPS field data collection system will be utilized containing the
following components from the following sources:
Trimble GeoXT GPS Receiver Contractor
Trimble TerraSync software Contractor
ESRI ArcPad software Contractor
ESRI ArcGIS version 9.0 software ODOT GIS Unit
Using biological themes developed for both the SR-SAM and
Environmental Baseline Reports contracted activities ODOT Biologists
and Consultant will:
- Conduct User Needs Analysis
- Prototype and test mobile application
- Document application and process
Completion Criteria Importance
This project is intended to be a pilot. A pilot can be defined as “a program
exemplifying a contemplated project” or “research conducted in advance Mission Critical
of the actual study to assess the logistics of the study. Keeping this in
mind the completion criteria for this project shall include:
- A final report to the GIS Steering Committee assessing both
successes and lessons learned
- Recommendations for inclusion in GIS 31 as well as GPS and field
data collection standardization projects
Business Benefits (Please provide justification of the indicated Importance ranking)
ODOT Biologists are continually assessing biological resources and the impacts of ODOT
activities and consequently collect large amounts of field data. Currently no system exists to
digitally store and recall field collected information for reference or analysis. Implementing a
system to organize biological information will enable our biologists to gather data more
efficiently and contribute to ODOT’s “institutional memory” with respect to natural resources. It
is expected that such a system will reduce duplicative data collection efforts and enable
biological data to be collected consistently across the state.
Estimated Project Funding Needed
$20,000 (identified within existing SR-SAM budget)
Assumptions/Risk (To be completed by Project Team)
- GIS Unit, Geo/Environmental Section and Contractor staff will successfully collaborate
- There will be sufficient communication with associated activities
- Appropriate biological data may not be chosen
- Since this is simply a pilot study, the lessons learned may not be applied to further
Dependencies – relationship to other projects (To be completed by Project Team)
- GIS 31, The Enviroview Project is the source project of which this pilot is a part of
- There are ongoing efforts to standardize both GPS use and field data collection
Effort in Person Months (To be completed by Project Team)
Projected FTE Effort Months
Project Manager .75
Analyst 0 m/dd/yy
Developer 0 Date Needed 2/1/2005
Data Base Administrator .25 Total Duration of Project 6 months
Tech. Mgmt. 0
Mason, Bruce & Girard, Inc.
707 S.W. Washington Street, Suite 1300
Portland, OR 97205-3530
DATE: December 30, 2005
TO: Milton Hill
FROM: Bob Carson, Yu Xia, Nate Whirty
SUBJECT: SRSAM Application Development Summary Report
Mason, Bruce & Girard was asked to provide this summary report to outline lessons
learned throughout the handheld application development phase of the SRSAM project.
This document is subdivided into five sections: 1) issues that extended throughout the
application development process, 2) issues pertaining to the hardware and software, 3)
issues unique to the development of the Mitigation Site Assessment Application, 4)
issues unique to the development of the Environmental Scoping Application, and 5) ideas
for future project direction.
Application Development Process
1. User Needs Assessment Meeting – Our first step was to schedule and host a meeting
with potential stakeholders in the application. We held separate user needs
assessments meetings for each application. The objectives of the meetings were: 1)
outline the specific needs each application would address, 2) identify specific
reference data needed for each application, and 3) define teams including ODOT and
MB&G personnel who would be responsible for developing each application.
We found that an essential first step was to define a clear idea of the overall
function of each application. Meeting as a group was extremely useful and
probably increased the efficiency of prototype application development since
most stakeholders had a say in the early development of application goals. All of
the involved parties started from a common point in the application development
In order to define a clear goal, we needed a wide range of meeting participants
including the ODOT GIS/GPS personnel, the actual end users of the application
(ODOT biologists), those who were involved in the decision-making process of
purchasing and implementing GIS and GPS, and us (the technical application
At the user needs assessment meetings, we realized that we needed to assess the
end users’ understanding and familiarity with the requisite technology and
procedures early in the development process. The applications had to be user
friendly or they would fail to meet expectations.
2. Generate Conceptual Design – MB&G then generated a conceptual design for each
application focused on the desired functionalities. The basic design elements for each
application were: 1) allow a user to collect the categories of data that were identified
by the MB&G/ODOT application development teams, 2) include the desired
reference data, 3) build the applications using a field rugged, user-friendly, and
updateable hardware and software technical platform, and 4) use a simple and flexible
data download and storage process adaptable to ODOT data standardization
We realized we needed to balance the desired functionality with the technical
capabilities of the end-user. To make the applications successful, they needed to
actually make the work of the field biologist more efficient without requiring a
steep learning curve. We decided to include user assistance functions in each
application to increase their user-friendliness.
The application development process highlighted a need within ODOT to
standardize data collection methods. In the future, the applications can help by
forcing biologists to choose from a limited number of methods built into the
application design, but lack of standardization did slow application design efforts.
It was critical to have ODOT people involved in the process who were
experienced with and understood the technology, so that our design truly reflected
the needs of both the individual user (the biologist) as well as the GIS personnel
who would upload and download the data following ODOT protocols.
We found that acquiring and/or creating all the necessary reference data was
sometimes problematic (Table 1). Some data were not available in GIS format. In
other cases a data set existed but the available version was outdated or
proprietary. Therefore, to keep the applications current, funds must be made
available within ODOT to generate or purchase the needed reference data and to
maintain an updated version.
As we designed the applications, we realized that a quality assurance/quality
control process for data storage and, possibly, for post-field updating of the
reference data layers needed to be developed.
3. Field Trials – Throughout the development of both applications we scheduled
multiple field trials with ODOT biologists and ODOT GIS personnel. The objectives
of these trials were: 1) to ensure that the applications were adhering to the original
design concepts as much as practicable, and 2) to test the functionality of the
applications under realistic conditions.
We used field trials to gather information from the end user about application
user-friendliness as well as additional data collection needs or shortfalls. It was
important to have a trial early in the application development since the feedback
helped us design an application best able to meet the needs of the user.
During field trials biologists who had little or no experience with handheld data
collection hardware and software had an opportunity to learn about GPS and GIS
technology. For inexperienced users, we found it helpful to give a brief
PowerPoint presentation of basic GPS concepts and an overview of the
application functionality and features immediately before going out for the field
trial. We learned that users might become strong supporters of the project when
given an effective field demonstration.
The limits of the software and hardware were occasionally apparent in the field
trails. Our experiences with these trials helped us integrate the technology with
the field data collection process.
4. Post-processing the collected data - We designed a minimal system for data storage.
Spatial data and associated form data collected in the field can simply be downloaded
by GIS personnel once the unit returns from the field.
We realized there was no defined data processing procedure within ODOT. This
will be an essential step to building an agency-wide GIS, but one that was beyond
the scope of our application development project.
Hardware and Software
Once we developed our conceptual designs we built prototypes of the applications using
the same hardware/software platform combination for both. We chose the Trimble
GeoXT hand held computer hardware due to its rugged, field-friendly design and the
ESRI ArcPad software because of its GIS/GPS capability and its customizable data entry
interface. Both proved adequate; however, we discovered some limitations of each.
We noticed during early field trials the GPS software on the GeoXT sometimes
had difficulty obtaining sufficient satellite links for sub-meter GPS accuracy. The
unit was least effective under predictable conditions (i.e. when surrounded by tall
buildings, or under heavy tree cover). Although we thought ODOT would not
typically be working at sites with these conditions, we decided to build in a GPS-
independent method of collecting spatial data. The freehand draw function allows
the user to collect data by recording a feature on screen while using the imagery
layer as a reference.
We experienced a considerable drawback of the GeoXT when we accidentally
performed a “hard” shut-off of the unit during a field trial, which resulted in the
temporary loss of all application and data files. To address this unfortunate
characteristic of the hardware, we devised a procedure for storing the application
and associated data in a shut-off safe location on the hardware. We also addressed
this limitation in the User’s Guides and plan to train field personnel appropriately.
Some participants in the field trials had difficulty seeing the view screen under
field conditions. This is a problem with most hand-held computers currently
available. We found no immediate solution beyond advising the user to try to
shade the unit as much as practical. We also recommend covering the screen with
a protective layer of plastic to protect it during field use.
We found that we, as well as other users, greatly benefited from practice with the
unit interface prior to collecting field data. The user interacts with the Microsoft
Windows CE operating system on the GeoXT by tapping characters on a pop-up
keyboard, or pressing buttons with a pen-like stylus. This interface was
cumbersome at first for some new users, but became much more efficient with
ArcPad software uses VB Script programming language, which is derived from
Visual Basic. VB Script did limit some of our application customization and was
somewhat less efficient for us to use than the more powerful Visual Basic
programming language. However, VB Script did prove to be adequate for
building custom applications.
We discovered that the speed of the application was greatly affected by the size of
the GIS datasets loaded on the handheld unit. To address this we recommend
clipping the data layers to only include the area relevant to the project area being
Mitigation Site Assessment Application
We designed the Mitigation Site Assessment Application to 1) facilitate accurate but
flexible data collection using one of several current methods and 2) introduce a spatial
data collection capability to mitigation site monitoring.
Preferred data collection methods (i.e. vegetation quadrat or point intercept) vary
among ODOT biologists. Early in the development process we decided to address
the lack of agency standardization by building limited choices into the
application. It is possible that the application itself will lead to some
standardization if it is used widely; however, we identified this as a major issue to
be resolved by ODOT since the data collected using different methods may not be
comparable on a statewide basis.
This application was not very user-friendly during the early stages of
development. It presented us with a challenge to include not only a variety of data
categories but also a variety of methods for data collection (see point above). In
the early prototype, the new user could easily “get lost” within the application. To
make the application more user-friendly we decided to build an extensive user’s
assistance tool. This tool leads the new user step by step through the data
Environmental Scoping Application
ODOT Regional Environmental Coordinators (RECs) generally complete environmental
scoping surveys by hand on paper forms. The biologists then re-enter the collected data
on electronic forms back in the office. We designed the Environmental Scoping
Application with two main objectives in mind: 1) make this process more efficient and
less prone to error by cutting out the paper form step and, 2) increase the quality of data
collected by adding an accurate spatial component.
As we developed this application with ODOT RECs, we realized that although the
current paper form is standardized, the methods of collecting data and actual data
categories vary by individual and region. As we experienced with the Mitigation
Site Assessment Application, the process of application design forced ODOT to
begin examining data standardization practices. As a temporary fix, we built the
application with multiple (but limited) options for data collection. As ODOT
develops data collection standards, we can further modify the application to meet
During our first field trial, ODOT expressed an interest in incorporating a more
detailed scoping notes output summary. In response, we designed a general
scoping notes form (with ODOT’s input) where the user can indicate a variety of
project environmental needs. This addition greatly enhanced the usability of the
application and highlighted the importance of field trials and user input to the
The large number of base data layers available was sometimes detrimental. Point
symbols and polygons of overlapping layers occasionally obscured each other
when multiple data layers were selected for display. To address this we designed
transparent polygons and more obvious point symbols. We also designed a tool
that allowed the user to easily turn on and off different layers.
As we acquired reference data layers, we realized the GIS support required for
this application would be significant. From an application maintenance
standpoint, the large number of reference layers will require regular and
consistent updating. Some layers are proprietary while others have yet to be
developed in GIS format, so some data acquisition still needs to occur.
The application includes several reference data layers. During our discussions
with ODOT, we realized the application could be used to update the quality and
accuracy of these reference layers. RECs would be able to record new features or
correct errors in the reference data while in the field with little extra effort. We
quickly realized the process would not be as simple as the concept due to the
nature of the base layers (ownership, coverage, attribute design). In addition,
ODOT would need to develop a quality control protocol before base data could be
updated. We decided to enable a REC to record and save features while
identifying the most appropriate base layer within the attributes of the feature.
Once a protocol has been implemented by ODOT, GIS personnel can update the
base layers with the new/edited features.
Future Program Direction
Once trained, ODOT biologists will be able to immediately use our two applications to
efficiently collect high-quality GIS data for mitigation site monitoring and environmental
project scoping. It is clear; however, that a good deal of future work and input will be
required before ODOT can take full advantage of the power and capabilities offered by
the two applications. Below we list our ideas for further development of these
Train ODOT biologists on application use. Training would include classroom
demonstration and field testing of each application.
Train ODOT GIS personnel on application pre- and post-field processes.
ODOT GIS infrastructure:
Design standardized procedures for pre-field application set up including
protocols and checklists for GIS personnel
Design standardized post-field data handling procedures for each application.
Design protocols for writing metadata for new data layers as well as altered and
updated reference data.
Help ODOT develop a QA/QC procedure to manage reference data updates.
Application testing and development:
Refine the applications by collecting data at mitigation and environmental scoping
sites and addressing issues as they arise.
Develop standardized biological data collection procedures which will be adopted
by ODOT and update the handheld applications as needed.
Develop a version of the environmental scoping application customized for sites
east of the Cascades.
Table 1. Reference data layers and associated issues.
Scoping Application Description/Issues
SMA Created for application
Staging & Stockpiling Created for application
Other Points Created for application
Other Lines Created for application
Other Polygons Created for application
SRSAM Streams ODOT data created by MB&G
SRSAM Wetlands ODOT data created by MB&G
DEQ HazMat Sites Maintained by DEQ; downloaded text database containing X
and Y coordinates, generated the layer in ArcMap; will need
to be updated periodically (once a year)
HSIS Right to Know Maintained by State Fire Marshal; contacted office to request
Sites CD, then made layer in ArcMap using X and Y coordinates;
will need to be updated periodically (once a year)
NRHP (point) Downloaded from NRHP website; will need to be updated
periodically (once a year)
NRHP (polygon) Downloaded from NRHP website; will need to be updated
periodically (once a year)
ORNHIC Acquired from ODOT; needs to be updated periodically (1 to
2 times a year), proprietary
4(f) Properties Able to find adequate data for Portland Metro area only
(acquired from Metro); will need to be addressed
State Lands Created from Public Ownership layer on Oregon GIS
Clearinghouse website; serviceable at the moment but unsure
of its completeness
Federal Lands Downloaded from The National Atlas
FEMA Q3 Floodplain Proprietary, ordered from GeoComm (www.geocomm.com);
will not need to be updated regularly
Sections In-house; public sector
Quads In-house; public sector
Bridges Owned and provided by ODOT
Mile Points Owned and provided by ODOT
Aerial Imagery Owned and provided by ODOT