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 #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.

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

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