search

ADAPT / Standard

ADAPT Standard data model issue management
https://adaptstandard.org
MIT License
7 stars 1 forks source link

Defining & Handling Crop Zone #48

Open knelson-farmbeltnorth opened 2 years ago

knelson-farmbeltnorth commented 2 years ago

In the C# code, CropZone.CropId is optional. I've assumed this is a typo and changed it to be required going forward.

I am also inclined to add documentation that states that one TimeScope of type GrowingSeason also is required.

Is a CropZone without a Crop and Season valid or useful?

brycehemme commented 2 years ago

I think we need to get really firm on how a CropZone is defined. Is it a zone where a field is managed differently year over year, and during a season, it may have a crop applied? Alternatively, and how I think it has traditionally been defined, it is the zone of a crop during a given season that is either planned to be planted/applied or has been planted/applied (actuals). I lean towards keeping it as the latter and requiring crop and season, but a solid solution for the former is also likely necessary (i.e. management zones).

andrew-granular commented 2 years ago

I'd also like to see a clear definition or something describing the purpose of CropZone as an entity. What does it do that a planting field op doesn't already do?

knelson-farmbeltnorth commented 2 years ago

There seems to be significant headwind regarding the concept of a crop zone in ADAPT currently. Issues include that fact that some field operations do not refer to a crop, introducing separate boundaries per crop often is redundant, and so long as crop zone is an optional entity, other entities need to refer to both Field ID and CropZone ID since one or the other may not be set.

As we current have Field Boundary as a separate collection from Field, I believe we can eliminate Crop Zone with the following changes:

  1. Put an optional Crop ID property on Field Boundary. If there is a field sub boundary for a crop season, it can be stored as a Field Boundary with a mapping to the field.
  2. Reintroduce Time Scopes on Field. We had removed it in favor of having information in a single place only (CropZone). Now the single place is Field.
  3. Replace CropZone ID with Crop ID on Work Item.
  4. On a case-by-case basis, where CropZoneId exists alongside FieldID, add a CropID property as may be necessary.

As such, systems currently modeling a crop zone boundaries internally would map them to individual Field Boundaries with a crop and season. Any systems modeling a plan to plant a certain crop on a certain field would set a crop and field on the Work Item.

knelson-farmbeltnorth commented 1 year ago

Consensus in Nov 2 2022 meeting that we should not eliminate the Cropzone, there are numerous valid use cases.

knelson-farmbeltnorth commented 1 year ago

It was further agreed that we would make an exception to the rule #38 that it not be possible to set both IDs of two entities that otherwise define their own parent/child relationship. Specifically, where one of Field or CropZone would be required, we will make Field always required and Crop Zone optional.

knelson-farmbeltnorth commented 1 year ago

Working definitions of Field & Crop Zone are as follows:

Field: A defined tract of land, usually farmed as a single unit over multiple seasons.

Crop Zone: A more detailed representation of/within a Field, defining a crop, its growing season and usually a separate boundary. Where Crop Zone is used within the ADAPT model, Field is also required.

knelson-farmbeltnorth commented 1 year ago

Discussion in 4 January 2023 meeting. Nothing remains unresolved with this issue.