-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path01-mapunits.Rmd
69 lines (47 loc) · 5.68 KB
/
01-mapunits.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# Mapunits
```{r, echo=FALSE, message=FALSE, warning=FALSE}
my.components.MLRA <- fetchNASIS(from = "components", dsn = "C:/Users/Nathan.Roe/Documents/ESS-FAQ/SQlite_tables/components18.sqlite", SS = FALSE)
```
```{r, echo=FALSE, message=FALSE, warning=FALSE}
library(soilDB)
library(dplyr)
library(aqp)
library(sf)
library(stringr)
library(ggplot2)
library(maps)
```
This section deals with mapunits. Mapunits have limited application for ecological work because they are broad concepts. Mapunits frequently contain multiple components, each occurring on different parts of the landscape and having different soil properties. Ecosites are correlated to components rather than mapunits because of the variability of mapunits. It should be noted that mapunits are spatially delineated, though, whereas components are not. Therefore, an attempt to map ecosites would rely heavily on mapunit delineations. An example of this can be seen on Web Soil Survey. Web Soil Survey can be used to map ecosites. These maps use mapunit delineations and show the ecosites that are correlated to the dominant component in that mapunit.
For the purpose of this document, mapunits are primarily used as intermediate steps in different methodologies. For example, some NASIS Reports are particularly useful and require mapunits as input. Therefore, determining what mapunits are in your area of interest is helpful.
The NRCS has four soil mapping products: SSURGO, gSSURGO, STATSGO, and gNATSGO. SSURGO is the most detailed product but is not available in all areas of the country. The resolution of SSURGO data ranges from 1:12,0000 to 1:63,360. gSSURGO is a gridded (rasterized) version of SSURGO - hence the "g" prefix. It covers the same areas as SSURGO but is gridded at a 10-meter cell size. STATSGO is a less detailed product but is available across all parts of the US. The resolution is 1:250,0000 in the continental US, Hawaii, Puerto Rico and the Virgin Islands. In Alaska, the resolution is 1:1,000,000. gNATSGO is a gridded combination of SSURGO and STATSGO. gNATSGO is primarily SSURGO data, but where SSURGO is unavailable, STATSGO is used to fill the gaps. The state-wide geodatabases are 10-meter cell sizes and the CONUS database is a 30-meter cell size.
Data mapunits are the internal structure of mapunits. Data mapunits contain the mapunit component data as well as some information about the data mapunit itself. Over time, changes are sometimes made to data mapunits. Examples include adding a mapunit component to a mapunit, changing the particle size percentages of a mapunit component, or as a result of mapunits being renamed and aggregated as a result of transitioning into MLRA mapunits. When changes are made to a data mapunit, a new data mapunit is created. This new data mapunit becomes the representative data mapunit and the old data mapunit becomes a non-representative data mapunit. By doing this, a historical record of data mapunits is created, that way past versions are not lost. For ecological site work, we are almost always interested in working with representative data mapunits because they are the most up-to-date data available.
## What mapunits are in an MLRA? {#mapunitsinMLRA}
If your MLRA uses primarily SSURGO data, the [Mapunit in MLRA tool](https://nroe.shinyapps.io/MapunitsInMLRA/) is the best option. It allow you to simply enter your MLRA of interest and define what percent of the total mapunit acreage must be within your MLRA for the mapunit to be considered a member of your MLRA of interest.
Note that this tool will make two groups of mapunits if there are more than 2,100 mapunits. This happens because most NASIS queries do not allow for more than 2,100 mapunits to be included in a query.
Why not use a NASIS Query that queries components by MLRA, like NASIS > Queries > NSSC Pangaea > Area/Legend/Mapunit/DMU by MLRA? Unfortunately, this is not the most reliable way to determine what mapunits are in an MLRA. Mapunits are assigned to an MLRA via the mapunit area overlap table. These tables are not perfectly populated. Some mapunits are not assigned to an MLRA and others could be assigned to multiple MLRAs. For this reason, using a spatial intersection, as is done in the 'Mapunit in MLRA tool' is the preferred approach. Components are assigned from the same mapunit area overlap tables and therefore suffer from imperfect population of mapunit overlap tables also. Components
## What mapunits are in a Soil Survey Area? {#mapunitsinSSA}
Queries by Soil Survey Area are much more reliable than queries by MLRA. As previously mentioned, queries by MLRA are not ideal because the mapunit overlap tables are imperfectly populated. The Soil Survey area corresponds to the legend, and this means that components are reliably associated with Soil Survey Areas. Therefore, let's use the following: NASIS > Query > NSSC Pangaea > Area/Legend/Mapunit/DMU/Pedon/Site/ by areasymbol.
1. Run against National
![Run against National SSA](_book/componentsinSSA.JPG)
2. Run against Local
![Run against Local SSA](_book/componentsinSSAlocal.JPG)
3. Acquire component names and IDs using R.
Load the soilDB package and fetch NASIS data
```{r, eval=FALSE}
library(soilDB)
my.mapunits.SSA <- fetchNASIS(from = "components", duplicates = T)
```
```{r, echo=FALSE, message=FALSE}
library(soilDB)
my.mapunits.SSA <- fetchNASIS(from = "components", duplicates = T, dsn = "C:/Users/Nathan.Roe/Documents/ESS-FAQ/SQlite_tables/componentsSSA792.sqlite", SS = FALSE)
```
Look at the mapunits - the ```head()``` function shows just the first six records. Remove the ```head()``` function to see all the component names
```{r}
head(my.mapunits.SSA$muname)
```
Look at the mapunit keys
```{r}
head(my.mapunits.SSA$mukey)
```
## Mapping mapunits
Using Soil Web and R.