Creating a Geodatabase for Arcpad and Microclimate Data

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 23^rd 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.