search

fiboa / ai-ecosystem-extension

Extension for properties needed for fiboa to interface with AI ecosystem
Apache License 2.0
0 stars 0 forks source link

Typology #1

Open andyjenkinson opened 6 months ago

andyjenkinson commented 6 months ago

Hi @hannah-rae @jacobsn thinking we could start to consolidate some of the fields already, in particular the 'types'.

The 'creation_method' is the same concept as was intended for the 'determination_method' in core, perhaps you could comment on the allowed values in the enum? The list was based on the outcome of AgGateway WG17: Field Boundaries Use Cases and Definitions. I expected there'd also be more method-specific detail (e.g. the ML model and version) so good you have that in the AI extension but you may want to rename it to match.

I think we could also propose to put the 'boundary_type' into core somehow. For reference, this is what AgGateway WG said on this concept:

A field boundary can fit into one, or even all four categories below, it is not related to how the boundary was created but what it is used for.

Conceptual Field Boundary: How the grower thinks of the field, this is the boundary they would share with service providers to allocate information at the highest level of the field concept within their operation

  • This is a Field per the definition, with a boundary. (Field: "A named and farmer-accepted physical space where production agriculture takes place used to partition and identify data.")

Operational Boundary: The boundary for a specific set of field operations as defined by or for the grower.

  • Management area for the purpose of sharing with service providers for analysis or recommendations
  • Area for a specific field operation for a specific machine

Economic Defined Boundary: A boundary used to define, plan, and analyze a field for business purposes as defined by or for the grower.

  • GHG/Sustainability/Traceability
  • Ownership/Splits
  • Billing

Administrative Received Boundary: A boundary used to organize data that is defined by some other authority and is generally not easy to change:

  • Governmental programs
  • Insurance
  • Legal land description

Notably, it was seen as not mutually exclusive (i.e. a boundary can have multiple types...) Personally I feel that there is something not captured here which is what is the thing on the ground the geometry represents, which is not quite the same as its purpose - for example does it represent a physical boundary feature, or a single crop.

jacobsn commented 6 months ago

Thanks for getting the discussion started.

I'm wondering if we should separate this into two notions:

1) A universally agreed-upon definition of a given boundary, which we would move to the core. 2) A dataset-specific definition of a label for the region, which we keep in the extension. This is nice because it grants flexibility to the person building a dataset.

FWIW we've been using https://github.com/Kitware/kwcoco on another project to represent similar data for training ML models. Perhaps there are some lessons to be drawn from that.