This map is the collected data gathered with ArcCollector on March 8th 2016. The data as described in the post above, was combined with the class data to create larger microclimate maps. This map contains the points collected from one device and by clicking on the points a list of the attributes for microclimate data will appear.

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.

Development of a File Geodatabase for Microclimate Data

Construction of a Navigation Map

By: Joey Mandelko

 

            For this activity the instructions were to construct a map to be printed off for navigation for a later field project. The area of interest lies just south of Eau Claire Wisconsin at a University of Wisconsin Eau Claire owned piece of property called the Priory. The goal for the navigation maps is to be able to successfully use them in the field to follow a path. The things to include in the maps are the following: a direction indicator, a scale bar and a ratio scale, projection, coordinate system, labeled grid, background, list of data sources, name, and pace count.

            The first thing I did was create a geodatabase to transfer the pre-existence geodatabase contents in so I could easily access and edit them. The next step is to choose a projection and coordinate system that best matches the area of interest. I chose the Transverse Mercator as the coordinate system and three NAD 1983 Universal Transverse Mercator state plane projection system. These were the two best choices for a small area in western Wisconsin. The UTM projection is best for areas in North American so that the curved ellipsoid can be best represented flat at the mid-latitudes. As shown in the image below the western side of Wisconsin is in the 15 column and the specific projection used, in this case UTM 15N, is the northern section of section 15. The goal of this is to limit distortion as much as possible.  

                After the projection and coordinate system are chosen and applied in ArcMap you can begin to add files to the map to start making a map that is used for navigation. The layout chosen in this case is the landscape 11x17 because it fits the area of interest the best and is a nice size to have in the field. In order to use a map for navigation it is important to be able to have a continuous point of reference on the display surface so that navigation from point to point is possible. In order to do this a measured grid can be selected under the layers properties tab. For this map I chose a grid measured in meters from 0 degrees latitude and longitude. The point of using a grid measured in meters not degrees is that it is much easier to use meters in the field to measure distance than degrees. This grid can also be used as a reference to a pace of steps per 100 meters. To do this I went outside and counted how many steps I took in 100 meters. My number was 61 steps for every 100 meters. This number should be added to the map and can be used for distance measuring in the field across terrain.

            The first map I created used satellite imaging under the grid so that navigation could be used by using roads, buildings, tree stands, and general look of the land as a reference. The goal was to keep this side of the map as clean as possible to avoid any layers that, while they may look fancy, become too busy for simple navigation. I also added a layer showing in red the outline of the area of interest to make it clear for the map user where the boundaries were. I then added a panel on the side of the map to display the various map elements as listed previously. The second side of the map focused not on look of the land but the lay of the land in terms of topology. I made sure to create a copy of the first map so that both sides have the same image and grid reference system. I applied a 60% transparency to the satellite image so it was still visible for reference from the other side of the map but not over powering. I then added the 2 foot contour lines on top of the image to show where elevation changes occurred. I now had a map for a visual reference and a map for topologic reference. The maps shown below contain the needed information on creation and display of the map and can be used in tandem to travel cross country through the forest in the Priory area of interest.