Field and Field Boundary Elements and Definitons per WG17

[crakerb-ship-it]

Attached list of terms and definitions WG17 has identified to be important in the context of transferring fields and field boundaries between systems. There are three files, one with the key elements and terms for Field, one for Field Boundary, and one for terms that came up in discussion we defined for clarity but were not included as elements of a field or field boundary. The goal would be to try and harmonize these with the terms and definitions within the ADAPT Standard.

Field Terms and Definitions.xlsx
General WG17 Terms and Definitions.xlsx
Field Boundary Terms and Definitions.xlsx

[knelson-farmbeltnorth]

I've taken the definition of Farm, Field, Field Boundary and Obstacle and used them in the ADAPT definitions.

A couple other points need discussion

1. Grower
   Current Definition-An individual/business entity engaged in agricultural production.
   Proposed Definition- An individual in charge of on-site farm operations to produce, harvest, transport and store a commodity; one who oversees mobile and stationary asset usage; one who oversees selection, application, and usage of all commodity inputs.

Is a grower always an individual? If so, how do we reflect business entities performing the same role? Also, what happens when different individuals/entities are in charge of the various roles defined above?

2. Additional Properties: FieldBoundary.Status, TimeBucket etc. Which if any of these are appropriate to include in ADAPT?

[crakerb-ship-it]

I do not think there would be objection to changing the grower definition to be entity instead of individual. Regarding multiple entities performing different aspects of the grower functions, would it make sense to add a context item or list of active/current function?

on point 2, the additional properties were identified as things the field boundary definitions group thought would be useful/relevant when exchanging field boundaries. So I would vote to include as many as make sense today but also expect there to be subsequent working groups that continue to refine the field boundary topic as we continue to ship away at the issues that make sharing field boundaries difficult today. For example we are about to start one up looking specifically at the GNSS technical aspects of defining a boundary.

[knelson-farmbeltnorth]

Following discussion in the 11 October 2023 meeting, we are evaluating what in the attached spreadsheets is missing and should be added to the ADAPT Standard. We've resolve the grower issue with item #123.

I have the following suggestions:

1. Regarding areas, "arable area" appears to be the primary objective area that can be readily defined and is likely the intent of what is today Field.Area. I recommend we change it to Field.ArableArea using the provided definition, and leave any other areas to be reported as Context Items where desired. Discussion on 11 October was that consumers are unlikely to reuse a calculated area, and that billable and reported area are not objective measurements.
2. Can we define a US-Specific Context item for Soil Type (something from SSURGO?). That could be the first of several geopolitical-specific types.
3. US Legal Description as defined assumes PLSS. Can we make it more generic as a text representation. If so, does it need to be US-specific.
4. The best definition I can find for Slope is on page 41 here: https://www.nrcs.usda.gov/sites/default/files/2022-09/SSM-ch2.pdf. It still leaves some particulars to interpretation. We need to discuss whether to include.

[knelson-farmbeltnorth]

Arable Area definition per 18 October 2023 meeting: "Total area of a field that is cultivated, excluding areas such as waterways"

[knelson-farmbeltnorth]

Further agreement in 8 October 2023 meeting to include all area types as defined in the "General" spreadsheet subject to the correction to Arable Area above. These will be scoped for use in Context Items.

We are deferring Slope and SoilType pending more formal definition and determination of need. Legal Description will be included as a free text Data Type Representation.

[andyjenkinson]

Hi @knelson-farmbeltnorth can I help somehow to get some of the missing things in? In particular the creation method, boundary type and dates would be good I think, as these are popping up in other areas like in FIBOA and it'd be good to align. The more that's already published in ADAPT standard the more can be carried across.

[knelson-farmbeltnorth]

Hi @andyjenkinson. Absolutely! Take a look at what we have in https://adaptstandard.org/docs/field-boundary/ and log a new issue here for any questions or suggestions.

Coincidentally, @crakerb-ship-it and I were planning to discuss #145 at our biweekly ADAPT Standard meeting (this Wed at 3PM GMT). If you can make it, we can put you in touch with the right people to get the meeting invite.

[andyjenkinson]

Sorry i could not make it. I'm not sure if a separate issue is needed, rather just to make more progress on completing this one? @crakerb-ship-it's spreadsheets already include many properties that aren't yet in the standard. I think for those that are vocabularies you'll need to refer to the pagers on the WG17 outputs confluence pages for the values?

The ones in particular interest on the Field Boundary type are:

• Creation Method
• Boundary Type
  Both are vocabulary terms (presumably the standard can express enums?)

[knelson-farmbeltnorth]

Closing this ticket as it relates to what was released in 1.0. Additional Field Boundary enhancements may be forthcoming at a later time from #145 and other work from the AgGateway Field Boundary working group.