-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
soil data access (SDA) services #5
Comments
More general notes, for reference.
|
@dylanbeaudette I'm shifting over our exchanges to here, as I said I would. For now, I have one question (and sorry if I'm being lazy ...): for this query (which works and that I'll be using for our initial needs; it's shown on the first post of this issue): SELECT DISTINCT
taxclname, taxorder, taxsuborder, taxgrtgroup, taxsubgrp
FROM mapunit
INNER JOIN component ON component.mukey = mapunit.mukey
WHERE mapunit.mukey IN (
SELECT * from SDA_Get_Mukey_from_intersection_with_WktWgs84('point(-121.77100 37.368402)')
) Does the SSURGO vs STATSGO issue/mix come into play? If it does, are there any reasons I'd ever want to get STATSGO results rather than SSURGO (again, for this query?)? FYI, that particular query returns two records, with one of them being blank. More broadly, I see many possibilities for providing richer soil information and granular links to your agency's web applications, stemming directly from the lat-lon query. But that'll be for a later time. |
A couple of things. First off, I would suggest a slight modification of your query, so that all components along with some additional columns are returned: SELECT co.mukey, cokey, compname, comppct_r, compkind, majcompflag,
taxclname, taxorder, taxsuborder, taxgrtgroup, taxsubgrp
FROM mapunit as MU
INNER JOIN component AS co ON co.mukey = mu.mukey
WHERE mu.mukey IN (
SELECT * from SDA_Get_Mukey_from_intersection_with_WktWgs84('point(-121.77100 37.368402)')
); Results:
Note that for any coordinate submitted this way there may be multiple possible soil components. You can filter out the most likely possibilities using the SSURGO data are implicitly selected when using There is always a 1:1 relationship between point queries and records in the |
Thanks!! Very helpful explanations; plus that expanded query seems really handy for both making a more explicit choice (based on |
Some more suggestions:
|
One more comment: it is likely that any given map unit will contain components with different subgroup level taxa. |
@dylanbeaudette Thanks for the additional input. Follow ups:
I'm already using POST, mainly for simplicity; but glad to hear there's also a performance advantage.
What do you mean? I'm currently requesting
Very helpful, thanks. I'm trying to make progress without having to fully immerse myself in understanding every aspect of these data, yet. Some of this I used to know back when I worked with diverse soils data (to some extent) to parameterize hydrological and ecosystem models; it's coming back to me, to some extent. |
@dylanbeaudette a question: I found a location (lat 32.4263, lon -110.7612) for which SDA did not return any soil taxonomy designation. This is in Arizona or New Mexico, in the Catalina-Jemez CZO. Does SSURGO not have full CONUS coverage?? Or are there areas that have not been categorized? |
Correct, SSURGO isn't 100% complete. |
Ah. I thought these soil maps were wall to wall, at least for CONUS. Darn. |
Starting point tutorial from Dylan: http://ncss-tech.github.io/AQP/soilDB/SDA-tutorial.html
SQL query statements, tests so far
These queries are working, and are VERY close to what I think we want!!
But make sure to look over the section on "SSURGO vs. STATSGO" and filtering, in the tutorial. Note that I added a
DISTINCT
qualifier, to collapse duplicate rows.The query returns the following XML (when requesting xml response; JSON is also available?). But note the empty row.
This works, and approximates what I'm looking for.
Two relevant examples from Dylan's tutorial page
I used these to learn and build up the query I'm interested in.
"Get basic map unit and component data for a single survey area, Yolo County (CA113). There is no need to exclude STATSGO records because we are specifying a SSURGO areasymbol in the WHERE clause."
"Get the map unit key and name at a single, manually-defined point (-121.77100 37.368402). Spatial queries using SDA helper functions automatically exclude STATSGO records."
The text was updated successfully, but these errors were encountered: