Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The first version of this module (included with farmOS v1) provided a feature for selecting points on a map and querying the NRCS Soil Data Access API to retrieve soil information. Specifically, it pulled the names of the soils at those points and used them to fill in the old "Soil names" field on Soil Test logs. This was not ported to v2 (see #3176503: Migrate soil names field + terms to farmOS 2.x), but it would be great if this module could provide a general purpose service for running similar queries.
Proposed resolution
Provide a general purpose service that other modules/code can use to query the Soil Data Access API, starting with simple GPS coordinates.
The 7.x-1.x logic can be adapted as a starting point: https://github.com/farmOS/farmOS/blob/509cfb2e928ef7537977a0f53eb93ee12a...
API references:
- https://sdmdataaccess.sc.egov.usda.gov/
- https://sdmdataaccess.sc.egov.usda.gov/WebServiceHelp.aspx
- https://sdmdataaccess.sc.egov.usda.gov/QueryHelp.aspx
Remaining tasks
- Add a
farm_nrcs.soil_data_accessservice. - Provide a method that takes a GPS coordinate (or set of coords), queries the Soil Data Access API, and returns the results.
- Automated tests.
User interface changes
None.
API changes
Provide a new farm_nrcs.soil_data_access service with methods for querying the Soil Data Access API.
Data model changes
None.
Comments
Comment #2
m.stentaComment #3
tbacon commentedCan this support taking a polygon or will it only a point or set of points? The polygon is desirable in addition to the points as input.
Comment #4
m.stentaYes! I believe any valid geometry can be used, although I haven't tested. I am thinking that this will simply accept a WKT string as a first step (which can contain any geom you want). That's how it worked in v1.
Comment #5
m.stentaComment #6
m.stentaRenaming this to "Soil Data Access API" rather than "SSURGO API" because I think that's more accurate.
After discussing this a bit with @tbacon, I decided to start with two simple methods on this service:
mapunitWktQuery($wkt)- Takes a WKT string and assembles an SQL query to get the following mapunit information:muname,musym,nationalmusym. The query is then passed to `tabularRestQuery()` to get the data, parse it, and return it in a structured array.tabularRestQuery($query)- Generic method that takes an SQL query and runs it against the Soil Data Access tabular REST API endpoint.I figure these provide a simple starting point, and are specific enough to avoid potential conflicts/overlap with future additions/changes. I imagine we'll want to expand on these methods, and add additional ones, to get access to more data over time. For now these bring us to parity with what the module provided in v1. So I think that's enough to start with.
Comment #8
m.stentaComment #9
tbacon commentedFrom this: https://sdmdataaccess.sc.egov.usda.gov/documents/ReturningSoilTextureRel...
It appears there are soil texture attributes that PODS desires (although I have not identified exactly which ones are needed).
Comment #10
m.stenta@tbacon - Sounds good! Let's open a new feature request to add the soil texture attributes once we have more specifics about the requirements and how/where to pull them from the API.
Comment #11
m.stenta