adding my notes too! this conversation was inCREDIBLY helpful to me
- Between Kevin & Octavio’s work, there’s one data point that we know will be hard to map - Conservation Practice Implementation (it’s a long string without a unique identifier - practical issue with the API)
- Is there a basic Comet Planner API? Yes and no. There’s a working, implemented version, but not usable or documented given concern that the project won’t be able to support server hosting needs. Possible we could figure out a back-up way in the future to get that public, but no documentation yet.
As we’re experimenting with PCSC workbook automation, we have some simple things to test – like running Comet Planner via API directly, in advance of switchboard and conventions. If we could use the spreadsheet version, this could be a great place to start, prototyping direct connections between farmOS → Comet
- We’re here to do whatever we need to do to take this practical dataset and get it in a usable way. We want this translation to happen regardless.
PCSC is a big, obvious place for connection - lot of need, also lots of bespoke-ness to what USDA is asking, lots of potential for convention-building. And the USDA sees this!
So where do we store the reference to a conservation practice? And should we start having a simple data dictionary to start converting USDA practice codes to Comet Planner strings?
Practice standardization -
Does the USDA have internal codes (including for application options) for practices?
Is it published somewhere?
Some of this information exists in NRCS reference tables:
-
These get published as PDFs & updated when there are code changes
-
can be derived from publicly available sources.
-
but doesn’t exist as a complete, public resource
CPS Code - is there a code for implementation?
- There are scenarios and practice components, and those get a little fuzzy by region (at state → region implementation - they don’t have documented versions and codes - but there are databases that have that information)
It would make sense to have a translation from USDA database practices simple code to comet-planner API, and then to use those as a standard for farm conventions.
Where to put that from a schema perspective? If we can start to know where it’s stored…
NRCS Reference Tables - NRTs - holds standards across organization
- Practice codes, then narratives (00N etc )that describe variations on how codes are implemented
- Further specification by scenarios (they are the same across all programs, but differ by state x region) ID# by component - can be derived from PDFs if you need it
- When it comes to Comet, how detailed do we need to go? Do we require state-specific IDs, what range conservation means by state, etc, or is Narrative level sufficient?
All Comet values (GHG data) are attached to implementation
-
Narrative level should be sufficient
-
Values are all available at the level of implementation
-
But there are state & county changes.
-
Then class, then CPS, then implementation (as a string of characters - not narrative number)
-
that’s as far as it goes.
When did these numerical descriptions originate? We don’t know that the narrative numbers are public, anywhere.
“Would be nice if this were in a public API…it’s just not”
Conservation practice standard (CPS) is publicly available - Conservation practice implementation is not.
- Comet Planner started with a bunch of DayCent runs - how were those strings derived?
- Probably in-house adapted because it’s applied to each type of land - doesn’t go into those details in USDA docs - and capturing multiple points at once (bucketing scenarios)
- Likely these are dictated by the model and not by NRCS.
None of the workbook categories that have to be specified by practice are the same as the ones used by Comet, or the same as what’s asked for getting CPIs from CPSs - three completely different and incompatible data collection methods?
What’s the relationship between these three sets of options? Clarifying and standardizing across them would be obviously helpful–is it possible?