SWAT+ (Soil Database) querry

[Mahesh Tapas]

Hello everyone,

Our lab is trying to set up a model for the Tar Pamlico River basin in Eastern North Carolina, USA. But we are facing errors in setting up our soil database.

We followed the process is given in the SWAT+ SSURGO soil (Using SSURGO and STATSGO soil data with QSWAT) manual. We currently have a Soil raster with integer data and clipped as per DEM, and (EPSG 2264 NAD 83 Projected) CRS. We downloaded squlite and mdb files of Soil from the SWAT website and kept them in C:\SWAT\SWATPlus\Databases. 

But we are still getting this error:

We checked the soil raster file but there is no Soil-1. 

We have the following Doubts:

1) Do we need to update the SWAT_US_SSURGO_Soils.mdb file stored in C:\SWAT\SWATPlus\Databases

2) If we don't need to update the database file, how shall we remove this error?


It will be a great help if you can help us in solving this error!

[Tom Bell]

I have an observation and solved a similar problem which might help you.  I am new to this and still blundering through so my level of expertise is low.   

I see a small but perhaps critical aspect of your error message.  The numeral 1 is suspicious because it is only a single digit.  It looks like it could be from the index (if you have one) or SPATIALVER field in your shapefile.  Be sure you are converting MUKEY to an integer and selecting MUKEYINT as the attribute when rasterizing your shapefile.  Also be sure you have added sufficiently large precision to your new integer field to capture all the digits in your largest MUKEY value.

I had the same problem and error message last week.  I had added polygons to my SSURGO shapefile which filled in the missing soils or areas like water bodies where there was no soil.  I gave them a value of -99999.  When SAGA rasterized this shapefile, it recognized the no data but substituted  a very large negative number and changed the field property from integer to Float64.

I solved the problem (which I created) by deleting the no data polygons in the shapefile.  SAGA still changed the value field type (four byte integer) in the shape file to Float64 in the tiff but inserted a no data value of -99999.  It looks like that -99999 is critical to preventing SWAT from using it in the lookup table to find a nonexistent soil.

 I hope this helps.