Field Boundary Data Application Note

This page documents the field boundary data application note. It is part of the minimum viable product (MVP) for AgGateway's ADAPT.

The purpose of the application note is to create a transaction to support simple and complex field boundaries (e.g., multi polygons).

Assumptions

This section documents assumptions of this application note, which may include pre-conditions or things not being considered.

Assume unprojected Lat/Lon WGS84 coordinate system, closed polygon geometry (i.e., no line geometry support).

User stories

MICS to FMIS user story

As a grower or service provider, I want to import field boundaries from an MICS into my software tool for a variety of reasons:

Have an accurate geo-referenced field boundary that was created with a machine using an accurate GNSS receiver
Import any new changes or updates from existing boundaries that may have been modified by a machine during a field operation

FMIS to FMIS user story (simple)

As a service provider, I want to import a field boundary from a grower who is already using an FMIS into my alternative software tool for my own unique reasons to add value.

Grower has imported geo-referenced field boundary into an FMIS

Boundary derived from MICS using Accurate GNSS receiver for accuracy
Boundary only contains the outer extents of the field boundary as exact with no additional parameters

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

FMIS to FMIS user story (complex)

As a service provider, I want to import a complex field boundary from the grower's existing FMIS into my alternative software tool for my own unique reasons to add value.

Grower has an existing geo-referenced field boundary in an FMIS

Boundary can be of several different accuracy levels including hand-drawn, derived from an operation completed with a GNSS receiver, or specifically collected as a boundary from a GNSS receiver
Boundary contains outer extents with parameters, i.e. passable/impassable, CLU, Legal.
Boundary contains inner closed polygons with parameters, i.e. passable/impassable
Boundary contains relevant metadata for further calculation, i.e. actual area, entrance, max/min elevation

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.

Excerpt from sample code (C#):

//Initialize the ADM Plugin
var pluginFactory = new PluginFactory(applicationPath);
var admPlugin = pluginFactory.GetPlugin("ADMPlugin");
admPlugin.Initialize();

 //Store data in the Catalog object
ApplicationDataModel export = new ApplicationDataModel();
export.Catalog = new Catalog();
Field adaptField = new Field();
MultiPolygon adaptMultiPolygon = new MultiPolygon();
adaptMultiPolygon.Polygons = new List<Polygon>();
Polygon adaptPolygon = new Polygon();
adaptPolygon.ExteriorRing = new LinearRing();
foreach (var coordinate in myBoundaryPolygon.ExteriorRing.Coordinates)
{                     
      var adaptPoint = new Point();                       
      adaptPoint.X = coordinate.X;                      
      adaptPoint.Y = coordinate.Y;                     
      adaptPolygon.ExteriorRing.Points.Add(adaptPoint);                   
}
...
adaptMultiPolygon.Polygons.Add(adaptPolygon);
FieldBoundary adaptBoundary = new FieldBoundary();
adaptBoundary.SpatialData = adaptMultiPolygon;
export.Catalog.FieldBoundaries.Add(adaptBoundary);
adaptField.ActiveBoundaryId = adaptBoundary.Id.ReferenceId;
export.Catalog.Fields.Add(adaptField);

//Export the data
admPlugin.Export(export, outputPath);
...
//Import
var pluginFactory2 = new PluginFactory(applicationPath);   
var admPlugin2 = pluginFactory.GetPlugin("ADMPlugin"); 
admPlugin2.Initialize();
ApplicationDataModel imports = admPlugin2.Import(outputPath);

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.