Data Gathering with Trimble Juno

Introduction

One of the basic elements necessary for the geospatial analysis is data – which many times are obtained by governmental institutions, as USGS, counties, US Census and many others. However, when the data is needed, but it still not available, one of the most traditional ways to collect data is with a GPS Unit. It’s the case for the Priory, a property owned recently by the University of Wisconsin – Eau Claire, containing a large portion of wooded land, which doesn’t have detailed information gathered.

Therefore, this exercise intends to, at the same time, provide detailed data for the Priory management and give practice and experience for the students in geodatabase creation, deployment and data collection in the field. Because there are a lot of features that need to be collected (trails, erosion zones, fallen trees, markers, benches etc.), the class divided in groups to collect different features. This report refers to the collection of point feature classes of markers and benches with a Trimble Juno GPS unit.

Methodology

It’s possible to simply go to the field with a GPS unit and start collecting points, lines or polygons randomly, giving the name and attributes on-site for the features. However, that’s not an efficient and clever way to collect data in an organized fashion. Instead, it’s better to plan ahead the features that will be collected, the attributes each feature will have and even which symbols they will have. Then, a geodatabase should be created including all these elements, including relevant rules or relationships, if that’s the case. For data collection on the field, an important element that should always be present is domains.

Attribute domains are used “to constrain the values allowed in any particular attribute for a table or feature class.” (ESRI, 2013), that is, when a domain is applied to a field within a particular feature class, it will allow the entry of only specified values. It can be divided in two types: coded values and range values. 

When creating coded value domain, all the appropriate options for that specific attribute will be already made, and during the data collection, there’s no typing involved – only the selection one of the options available. That was the case on the markers: for the condition (Figure 1), there were four options, good, fair, poor and other. In the same feature class, for the medium (Figure 2) – the material the marker is made of – there were also a few options: metal, wood, flag and other. The benches also had a coded value domain for the attribute regarding if it was within a viewpoint or outside it (Figure 3), in this case, only two options were available: yes or no.

Figure 1 - Condition Domain

Figure 2 - Medium Domain

Figure 3 - Within Viewpoint Domain

Coded values domains are commonly used when the field type is text, while when it’s a number (float, integer, long integer etc.), it might make more sense to use range domains. In this case, the user still will have to type the value, considering it can have a wide variety that cannot be categorized in all the possible options. However, a range is determined to avoid inputs outside this range. 

For example, when acquiring data for the benches, one of the attributes was the direction the bench was facing. For that, a laser device was used informing the azimuth value, ranging from 0 to 360 degrees. By establishing a range domain with these values (Figure 4), it won’t be possible to input negative values or values higher than 360 – which allow the error to be fixed right away. The same idea was used for the proximity attribute, regarding the distance from the bench to the closest trail – because it was known that the benches should not be extremely apart from the trails, a maximum value of 100 meters was defined (Figure 5).

Figure 4 - Azimuth Domain

Figure 5 - Proximity Domain

It’s important to recall that attribute domains pertain the geodatabase and are not created directly to the feature class. After creating the domain within a geodatabse, it’s necessary to apply it to a specific feature class. For that, it’s necessar to go to the feature class properties, in the field tab  and click the field where the domain should be applied (Figure 6). The “Field Properties” below will then give the “Domain” option, where a list of domains is available to select the appropriate one.

Figure 6 - Associating domain to feature class

When the geodatabase is already with all the feature classes, fields and domains appropriates, it will be ready to be transferred to the GPS unit. The Trimble Juno units (Figure 7) contain the ArcPad application, which is a mobile version of ArcMap. To make this transfer, an ArcMap document should be created with all the features and, optionally, a basemap (in this case, based on the imagery). The ArcPad Data Manager extension should be selected to make its toolbar available, where the ArcMap project will be converted to an ArcPad project, by clicking “Get Data for ArcPad”. The resulting files should then be transferred to the memory card in the Trimble Juno, making the GPS unit ready to go to the field.

Figure 7 - Trimble Juno GPS Unit

In the field, when opening the ArcPad application in the GPS units, the Create QuickProject option should be selected, where you’ll be given the option of different projects to be opened. Firstly, the group started to collect all the features together, but because that would result in duplicated results and the amount of markers was much higher than imagined before, it was more efficient to separate the group in different collections: circle markers, triangle markers, and benches. After the collection, the data was gathered together to produce a map regarding the collection (Figure 8).

Figure 8 - Final Map

Discussion

The use of domains has a lot of advantages not only with the efficiency of collection – since the entry of data happens much faster – but mainly regarding the integrity of data. The field environment cannot be compared to an office environment – where there’s time and amenities to allow the user to be very careful in the data input. Contrarily, a lot of elements might compromise data input like weather conditions – rain, snow or even the sun light reflecting the interface screen and compromising visibility. The different places also don’t allow much attention to detail, like being in the middle of the forest, at the top of a tree or inside a ravine. For that reason, it’s very common to have lots of typos in the data input, which can compromise a future analysis. Even if the error is noticed, in larger databases, it’s very time demanding to correct all the entities. Considering that, the use of domains can minimize or even remove these kinds of errors and should, then, be encouraged for all the possible fields.

 In that matter, the group could have added more domains to the collection, for example, in the Color field for the Markers (Figure 9). All the markers collected were orange, but because the group wasn’t sure of all the possible colors, the field remained without any domain, and should then be typed in every point. A way to avoid that in the future is to be knowledgeable of the area before going to the actual data collection – it doesn’t need to be an actual visit to the place, but even talking to someone who knows the area, so you can design some main categories for your field. Of course it’s always possible that you find something unexpected on the field, which was not predicted on the coded values domain. That’s the reason why all the coded domains include the “Other” option, where the specific attribute can be added in another field, called “Notes”.

Figure 9 - Marker Colors

Fortunately, the GPS unit is already prepared for this kind of situation and has an intelligent dictionary which recognizes the most common words used to fill the fields and gives the option to them when the user is typing. That is also a way to increase data integrity, but should not be counted on individually, especially when dealing with large geodatabases.

Another point to be considered is the need to divide tasks, which will depend on the accuracy the GPS is having and the purposes of the collection. If data is being collected for a very specific in-site project, requiring a high accuracy, it’s important to have three people collecting the same data – in that way, it’s easier to detect accuracy problems and correct them. Also, if the PDOP is too high in one of more units, it’s better to have more than one collection, for the same reason.

However, if the PDOP is reasonable and meets the purpose of the project, which was the case, there’s no need to collect the same data three times. Then, it was possible to cover a much larger area after the group divided tasks, in a short period of time.

For last, this activity took place without the use of paper maps. In this situation, it was very useful to have the imagery background in the GPS unit, so the user could identify areas covered already, and the following areas he or she would need to go. It’s important, though, to remember that mobile devices tend to have limited memory compared to computers, and therefore, a world-map imagery should not be transferred to the unit. Instead, the “Extract By Mask” tool should be used to select only the area of interest.

Conclusion

This exercise was a very good opportunity to practice the use of a new technology in GPS, the Trimble Juno is one of the new models of GPS and one of the only ones where Arc Pad is available. It was very interesting to integrate the GIS knowledge to the GPS data collection.

Also, this project reinforces the use of the object-oriented model, over the georelational. While shapefiles are still widely used, the geodatabase model offers so many components that guarantee data quality and integrity and should be encouraged to be used. The main point in this project was the use of domains, but there are many other options, as establishment of rules, relationship and so on. Although it would be great to have this model everywhere, because it requires an ESRI license to be used, it can many times limit its access. However, it’s important to be aware of the potential present in this model and in the ways it should be used, so it can be applied when the license is available or designed when this option is possible.

References

ESRI. An overview of attribute domains. Available on <http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#geodatabases/an_ove-1191742984.htm>. Access on May 9^th,2013.

Balloon Mapping & HABL Launch - Video