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
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.
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).
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
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).
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”.
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 9th,2013.