Soil Test Workflow in ADAPT

[knelson-farmbeltnorth]

As an initial use case for Observations, we are investigating how to model soil test data in ADAPT. This diagram illustrates (at left) how ADAPT models field operations and (at right) my own initial thoughts on how we could reuse the ADAPT document types to model the soil testing process.

[zwing99]

I think this way of modeling soil test works fine.

[knelson-farmbeltnorth]

We started discussion with the above in the 7 August 2024 meeting. Some participants liked the documents approach as laid out, others pointed out that the two Work Records were in common practice two parts of the same document.

[knelson-farmbeltnorth]

Renaming this ticket to "workflow" to separate it from modeling the observation codes.

[knelson-farmbeltnorth]

I've expanded on diagrams for continued discussion. In the below:

• I've mocked up the initial request to pull with a vector file listing the defined points. To the extent there is any industry demand for such an electronic format, the points may or may not be defined at this stage.
• The document defining the location of the samples is reclassified as a Work Order. While it is completed work in some sense, it is not unlike the work of having completed a Prescription. It is intermediate work.
• I've included Document Correlations between the documents and PrescribingOperationIds between Operations.
• The Work Order requests the tests to be run by referring to a defined Product that has meaning to the lab.
• I mocked up "VariableContexts" (first discussed in Abstract Model for Observations #147) to define the top and bottom of the soil core pulled.
• I'm using Modus2 codes as the Definition Codes. These are denormalized, each with every parameter fixed per code similar to how we've denormalized Target Seed Rate vs. Actual Seed Rate, etc.
• Geometries are points here. For the less common composite sampling use cases, we could substitute multi-points or polygons.

[aferreyra]

I like your work, Kelly. It makes me wonder how to represent the finer points of a desired observation, like the depths, any specific sampling or observation method desired, etc. Curiously enough, I wonder if, analogous to what ISO 11783-10 does, we might not be able to re-use the format of the actual observations, adding a status (1: planned / 2: running / 3: paused / 4: completed / 5: template / 6: canceled).

[aferreyra]

From 11783, explaining what "template" means (which is a very valuable concept in scouting),
The XML attribute TaskStatus has values 1 to 4 and 6 for specifying the lifecycle of a Task. In addition
to these 5 states, the TaskStatus can be specified as “template” (value 5). When a Task with status
“template” is started, then a new Task, which is a copy of the template Task, shall be created and started.

[crakerb-ship-it]

Per sampling discussion on 14 Aug 2024 attached is the examples and information the Modus team documented for how sample points generally work for both grid and zone methods as well as single point and composite samples complete with pictures.

WG04-Sample Collection Examples.pdf

[DarinGary]

An example list of ala carte nutrients and depths from Agvise Labs. I will find packages as well as they are commonly used.
soil-table-doc23.pdf

[knelson-farmbeltnorth]

In the 14 Aug 2024 meeting we discussed my latest mockups above.

@aferreyra recommended that we need to keep the separation between Work Orders and Work Records as in my initial mockup for cases where what happened was different from what was intended. General agreement from group.

We debated representing the lab package as a product or something else. Wherever we model that data, we agreed that we need flexibility to model a group of requested tests by a package name, or individual tests down to the specific test methods.

Re the final Work Record above, we agreed that I should not have used the same UUIDs from the work order to map back to the depth, rather that the depth should be explicit in the report. @DarinGary pointed out that common industry practice is one column per test per depth.

We will continue to discuss and refine in the next meeting. Please continue to add comments, feedback and any corrections to the above.

[DarinGary]

Zone Soil Testing in MN, ND, SD Our System

Not going to say this is right, but it is what is done in our workflow.
I can see this being useful for managing the workflow and storing results.

Work Order for Soil Sampling

A customer requests zone, or grid sampling for a field, a zone map is then developed.
It would look something like this for a 3 Zone field.

Our soil testing lab has an API, and workorders for sampling are generated with that API. The Return from that API is a PDF to print for the sampler to tag bags with while sampling. In this case this was for a 2-zone field with 2 depths TopSoil and Sub Soil. The field could have more zones, and/or a DeepSubSoil Tag
From top to bottom, this field sticker sheet has enough information for the sampler to do his/her job.

Lab ReferenceID
Grower ID and Grower
Field Name
Zone Name
County
Portion of Section and Section and Township

The field could have more zones, and/or a DeepSubSoil Tag

This printed Label sheet is taken, and the field ID is already available as a TIF or SHP Points in a cloud folder accessible by the sampler. Multiple cores in the DK Green are placed together in one bag per depth and labeled with TopSoil or SubSoil Tags.
Then multiple cores are taken and bagged separately per depth in the Red Zones.

Tags for labeling bags:

The bags are then sent in for analysis.

Soil Test Results

Once the results are available, through an API we retrieve the results, and they are returned as a CSV. W would request by field ID and the API would group all of the zone in the field into the CSV with depths identified in the columns Like below.

<style> </style>

Ref No	GrowerID(25)	Fld ID(1st 8)	Sample ID	County	Twp	Qtr(11)	Sect No	Acres	pH	BpH	OM	N1 lb	N2 lb	N3 lb	N-(N1+N2)	P-O ppm	P-B1 ppm	K ppm	Ca ppm	Mg ppm	S1 lb	S2 lb	Zn ppm	Salt1	Salt2	Cl-1 lb	Cl-2 lb	Cl (Tot)	Cu ppm	B ppm	Fe ppm	Mn ppm	Na ppm	CEC meq	CCE% D1	CCE% D2
20520441	REDACTED	SOUTH OF	RED	DIVIDE	DEWITT	S	24	10	8		2.2	9	12		21	6		258	5240	1035	120	360	0.27	2.13	2.19			172	0.9	0.65	10.44	1	470	37.53	5
20520442	REDACTED	SOUTH OF	YELLOW	DIVIDE	DEWITT	S	24	40	7.8		2.4	20	36		56	6		311	5404	1224	120	360	0.33	2.08	1.99			180	0.98	0.92	13.49	1.33	288	39.27	3.4
20520443	REDACTED	SOUTH OF	DARK GREEN	DIVIDE	DEWITT	S	24	27	7.7		2.7	15	36		51	8		356	4294	782	120	360	0.4	0.93	1.06			120	0.95	0.77	14.85	1.88	171	29.64	0.3

In zone or composite sampling, the sample locations are in another dataset in the navigation software that the sampler used.
One row in the table describes all nutrients and depths for that zone. If it was a grid field the sample ids would be merged with the point ids from the navigation software, but for zones or composites they would just be stored, and used to navigate to those points the next time that field was sampled.

These sample results are then mapped, and nutrient prescriptions created from the zone map and the soil test results.
One row in the table describes all nutrients and depths for that zone.

[knelson-farmbeltnorth]

I've created 3 new issues to continue specific points of the discussion above:

#152 Types of Workflows
#150 for identifying requested tests
#151 for identifying completed tests