Service Provider FMIS receives new boundary in order to geo-locate the grower's field and perform further analysis.

Partner FMIS leverages a unique plugin use where only a subset of the total available data in the Grower FMIS and in ADAPT is used to meet the specific needs of partner FMIS.

Geo-fence user story

A geo-fence can be the same as a field boundary. A geo-fence is generally used for real-time telematics tools to enable alerts to be sent to farm mangers or other parties so they know when a machine enters/leaves a specific area. Examples of when and how a geo-fence might be used are:

As a grower with a sensitive crop that is not resistant to certain crop protection products, I would like to set up a notification that whenever my applicator enters this field I receive a text message so that I can verify that the operator is in the correct field and does not apply a non-approved product to the crop.

As a farm manger, I would like to set up a notification to receive an alert when a combine leaves a field so I can be sure to redirect support/transport vehicles to the next field where the combine is schedule to harvest. This will prevent those vehicles from wasting time driving to the field the combine just left and will allow me to direct them to the current location.

Code implementation

Users can serialize all types of grower setup information via the ADM Plugin, including field boundary data. After rendering the data in the ADAPT Application Data Model, use the ADM Plugin to create an optimized serialization of the model. Upon receipt of the output, the consumer then deserializes the data with the ADM Plugin.

Sample code

See the full TreeDemo example in the ADAPT Sample Code (https://github.com/ADAPT/ADAPT-Samples).

Implementation notes

On Grower/Farm/Field/CropZone hierarchies and boundaries in ADAPT....

AgGateway's ADAPT is a model created through a series of compromises, and influenced by the group of volunteers who stepped forward to work on it with dedication over the past couple of years. Throughout the process, we tried not to pick winners. The goal was to support stakeholders (more or less) where they are and not force major refactoring on any one participant's part just to be able to integrate.

As a result, the way ADAPT implements and arranges its Grower, Farm, Field, CropZone, and boundary structures is extremely flexible. Here are some highlights:

Grower, while the theoretical root of the hierarchy, is not actually required by any of the other objects. This was necessary to support its optional nature in representing ISO 11783-10 data.

Farm and Field have collections of TimeScope objects which allow them to be "tagged" as being part of multiple crop years. Stakeholder's systems varied in how they scoped farms and fields in time. Some forced the objects to be redefined (with a new unique identifier) each crop season, others allowed the same object (and unique identifier) to span seasons.

Fields can have multiple FieldBoundary objects associated with them. This allows for a field's boundary to shift over time while still preserving the older versions, as well as supporting special purpose versions of a boundary. The FieldBoundary.SpatialData property is an ADAPT Shape object (which is an abstract class) - what is actually used is one of the child classes of Shape (Polygon, MultiPolygon, etc.). The Field object has a property (ActiveBoundaryId) that allows designation of the "default" FieldBoundary to use.

ADAPT defines CropZones as a spatial area within a field grown to a crop during a specific window of time. This is fundamentally different from the concept of a management zone (that might vary by plant population within the same crop variety, soil type, or fertility amendment requirements). The CropZone (unlike Field) holds its boundary internally. Also unlike Field, a CropZone is only expected to have a single boundary due to its scope in crop and time.