User Soil Database - CMPPCT Field

[Paul]

I am wondering about the inclusion of the CMPPCT field in the
usersoil.dbf file. If I am understanding things correctly this field
is used to disaggregate the spatially aggregated STATSGO soils data
for use in HRU definition. However, user soil data - such as SSURGO -
associates grid cell values with specific rather than aggragated soil
types, so this field should not be needed in usersoil.dbf since it
would always be 100%. Am I missing something?

[R. Srinivasan]

From my knowledge CMPPCT is not used within any of the interface.
However COMPPCT is a field in both STATSGO and SSURGO to show the % of the
component soil within a polygon.

Srini

[Paul]

Srini,

I think I have figured this out for myself, but I'll post here for the
benefit of others, and hopefully to obtain your concurrance.

- As you note, COMPPCT is the STATSGO field that shows the % of a
given component soil within a map unit polygon
- Likewise, the SSURGO data model uses the comppct_l, compct_r, and
comppct_h fields (for low, representative and high) to indicate the %
of a given component soil within a map unit polygon.

- CMPPCT is a field in the BASINS SWAT2000 usersoil.dbf file, and at
least by name appears to be intended to serve a function similar to
that described above.
- Examination of the STATSGO dbf files stored in C:\BASINS\models\Swat
\database\AllUs\statsgo\<ST> (where <ST> is the two letter state
abbreviation) reveals that these databases have exactly the same
fields as usersoil.dbf, including CMPPCT.

SWAT provides one dbf file for each STATSGO map unit, with a record
for each component soil in the map unit. The records contain all data
required to write the .sol file for each component soil, along with
the value of the CMPPCT field (which I assume is equal to the COMPPCT
field of the parent STATSGO dataset). This allows the component soil
data to be disaggregated at the map unit level and used to define
multiple HRUs in a subwatershed when that option is selected.

Since the User Soil Database Editor does not display the CMPPCT field
for editing, I assume the field is not used and is merely an artifact
of the template database from which the usersoil.dbf was apparently
created. Effectively, this means that user soil coverages are assumed
to have non-aggregated soil map units - one soil component per map
unit - or at least that the data required for the SWAT .sol files can
be aggregated to the spatial resolution of the map unit without
introducing significant error. This is in contrast to the way the
interface treats STATSGO soil data, where a mechanism for
disaggregation is provided.

I note that the SSURGO SWAT extension available at http://lcluc.tamu.edu/ssurgo/
appears to map the SSURGO compct_r field to CMPPCT. Although not used
by SWAT, this can provide the user with information useful in
assessing whether the extracted SSURGO data is representative of the
map unit. For example, I noted a map unit in my data for which CMPPCT
was only 20%. Looking at the parent SSURGO data, I found that the map
unit was an urban land complex and that 70% of the unit is urban
land. I will have to evaluate the appropriateness of the extracted
soils data given this degree of urbanization.

Comments on or corrections of the above are requested.

Thanks,
Paul

> >would always be 100%. Am I missing something?- Hide quoted text -
>
> - Show quoted text -

[Paul]

OK, an addendum to my post above:

I just noticed that the usersoil.dbf file produced by the SSURGO SWAT
extension has more than one record for some of the map units. This
appears to be in cases where there was soils data available for more
than one soil component of the map unit. The records are identified
with the same MUKEY and SNAME value, but are serialized with the SEQN
value (i.e., 1, 2, etc.). However, when I use the GIS interface to
edit the user soil database I see only the last record, so I assume
this is the only record that will actually be used in defining the
HRU's and writing the sol files. I am therefore contemplating using
the CMPPCT value to obtain weighted composite values of the soil
parameters for use by SWAT.

Am I correct that the GIS interface uses only a single entry in the
usersoil.dbf file per map unit when user soils are selected? If this
information is documented somewhere please point me to it!

IMHO, the GIS interface deserves a technical reference manual as
comprehensive as that provided for the SWAT model DOS executable.

Thanks,
Paul

> I note that the SSURGO SWAT extension available athttp://lcluc.tamu.edu/ssurgo/

> appears to map the SSURGO compct_r field to CMPPCT. Although not used
> by SWAT, this can provide the user with information useful in
> assessing whether the extracted SSURGO data is representative of the
> map unit. For example, I noted a map unit in my data for which CMPPCT
> was only 20%. Looking at the parent SSURGO data, I found that the map
> unit was an urban land complex and that 70% of the unit is urban
> land. I will have to evaluate the appropriateness of the extracted
> soils data given this degree of urbanization.
>
> Comments on or corrections of the above are requested.
>
> Thanks,
> Paul
>
> On Feb 24, 6:54 am, "R. Srinivasan" <r-sriniva...@tamu.edu> wrote:
>
>
>
> > From my knowledge CMPPCT is not used within any of the interface.
> > However COMPPCT is a field in both STATSGO and SSURGO to show the % of the
> > component soil within a polygon.
>
> > Srini
>
> > At 01:26 PM 2/23/2007, you wrote:
>
> > >I am wondering about the inclusion of the CMPPCT field in the
> > >usersoil.dbf file. If I am understanding things correctly this field
> > >is used to disaggregate the spatially aggregated STATSGO soils data
> > >for use in HRU definition. However, user soil data - such as SSURGO -
> > >associates grid cell values with specific rather than aggragated soil
> > >types, so this field should not be needed in usersoil.dbf since it
> > >would always be 100%. Am I missing something?- Hide quoted text -
>

> > - Show quoted text -- Hide quoted text -

[Paul]

Well I have found what appears to be the answer to my original
question on my own. Hopefully I am not boring everyone by posting
what amounts to a monologue here.

As a BASINS/SWAT user I confess I had never looked at the
documentation for the AVSWAT 2000 GIS interface (DiLuzio, et.al,
2002), posted here: http://www.brc.tamus.edu/swat/downloads/doc/swatav2000.pdf

Actually I didn't know this document existed or I would have consulted
it sooner. I am assuming that there are no significant differences
between the AVSWAT and BASINS/SWAT GIS routines.

Anyway, the information on how soils grid information is utilized by
the GIS interface is pretty well explained in Section 3 on pages 10
and 11. To summarize:

- In all cases, only one set of soil parameters is used per map unit.
- For STATSGO data, by default the parameters for the dominant (i.e.,
largest value of COMPPCT/CMPPCT) soil component in the map unit are
used. This is contrary to my posted speculation that this field was
used to disaggregate the soils in a landuse/soil map unit overlay
polygon for the purposes of HRU definition.
- The SEQN value is provided to allow the user to specify that the
parameters for a soil component other than the dominant one be used
(not sure if this option is actually implemented - I've certainly
never used it).
- The usersoil database is intended to have one soil data record per
map unit.

Here's a suggestion / question for the SWAT/GIS team: Instead of
discarding the data for minor map unit soil components, how about
providing an option to weight the parameters? This should give model
values that are more representative of the soils in a polygon,
especially for map units which have large secondary components.

[R. Srinivasan]

Paul,
We did consider the option for either weighted average or just average or
user selected values, later we found from soil scientists, it is WRONG to
just use any of the above method since the variables such as Saturation K,
AWC, soil depth can not be weighted that easily. Same goes to the
sand/silt/clay etc...so we dropped this idea.

Hope this helps.

Srini

[Paul]

Thanks Srini - I appreciate the feedback, and that does help.

Paul