Creating a
Geodatabase for Arcpad and Microclimate Data
By: Joseph Mandelko
For
this field activity the goal was to be familiarized with the idea of
constructing a geodatabase before going into the field so that data collection
would be simple and straightforward. This is particularly important for GIS
because once the data is collected in the field, if done properly, it can be
queried in the software and the attributes of the collected points enable the
user to get the most out of the data as possible. In order to make data
analysis easy the idea was to create a geodatabase with domains and ranges to
limit errors in data collection and leave space open for what data was needed
to be collected. For example there were domains made for wind speed,
temperature, relative humidity, and several other microclimate indicators.
Ranges were used to avoid data error, for example the temperature for the 23rd
of February on the University of Wisconsin Eau Claire campus would not be below
0 degrees or above 60 degrees. A range allows the user to avoid errors that
could result in impossible temperatures being added to the point attributes.
The
trial microclimate test was to be conducted out front of the Philips Science
hall on the University of Wisconsin Eau Claire Campus Mall. The test was
conducted at 5:00 p.m. and the conditions were stormy. There was dense and low
lying cloud cover though essentially no wind. Temperatures were generally 39
degrees Fahrenheit. In order to collect data the geodatabase that had been
constructed with the appropriate domains and ranges had been downloaded onto a
Juno GPS device. Once in the field it was easy add a point to the file using
the GPS, when a point was added the GPS prompted the entry of data for all of
the unfilled spots in the attribute table. This ensured that the data was
collected in the same fashion with every point using the domains and the ranges
ensured there was no data entered that was impossible.
Once
data was collected it was clear to see the results that an ill formed
geodatabase could cause. In this case there were hardly any patterns seen in
the data as the area of interest was a relatively small area. However there
were constants, the weather readings taken by the Kestrel hand-held weather
system were reliable and the fact that there was no wind was constant and the
temperature never varied by more than a degree. There were, however,
limitations to the data that was collected. There were some readings provided
by the Kestrel that there were not domains for and similarly there were some
created domains that had no readings from the Kestrel to fill. If the domains
were left empty it could result in a null or even a zero value being put into
the attribute table and depending on the use for the data this could cause a
significant gap that could slow or ruin data analysis. As with any field study
it is likely there are going to be mistakes. In this case the data collected
did not offer a large amount of range and so really no discernible difference
is detectable. Essentially the data that was collected from the single Juno is
of no use for analysis and reporting. In order to get any telling data it would
be best to do the test again in a slightly larger area and with many more
points and more people collecting data.
This
method of collecting more data points would not be without its difficulty though.
If more data is being collected by more people on more devices there is a
larger chance for errors to occur. For instance, all of the ranges and domains
in the data would have to be exactly the same in order for the data to be
combined into one larger attribute field. There is also the issue of
terminology. If wind direction were taken by some as “W” and by others as “West”,
the data would be the same in meaning but the software would be unable to add
the two fields together.
This
field test indicates just how difficult it can be to organize field studies.
Most all of the errors can occur before even entering the field. If the file
geodatabase were created incorrectly, the survey would be over before it began.
The difficulty with using this style of data collection is also its strength.
The difficulty is in the set-up of the geodatabase and the transfer of the
geodatabase onto the GPS and then the eventual transfer of data back into
ArcMap for analysis and display. This is also the strength though in the way
that data is far more organized and ready for display than a numbered GPS point
and a handwritten collection of weather data. Though more difficult to set up
using a geodatabase and attributes, domains, and ranges offers the better
option for data collection.
There
were many issues I ran into while conducting this test. The first mistake was
in my creation of a personal geodatabase not a file geodatabase, I ended up
with a geodatabase that could not be handled properly by the GPS I was using. I
then had several issues with the transfer of the geodatabase to the Juno. This
issue was eventually corrected with a small data formatting correction by
simply checking a box allowing for export. This just went to show me that the
large portion of frustration that can be had with data management is usually
handled by a simple quick fix. The only issue, and one that I had more than
once this week, was remaining vigilant enough to find that one small correction.
Data collection went smoothly but the transfer from GPS to Arcmap was not
smooth. I now know what I needed to do in Arcpad on the desktop computer to
bring the data into the software to be able to be unzipped. This was a needed,
though painful, learning experience that should make the real survey this next
week a much smoother process.
