Adding calculated or user inputted area to API and stored data model

Development
1

This issue came up in the FarmOS Element. Here’s the discussion.

Hey all! I won’t be able to make the dev call today. I’ll catch up next week. :slight_smile:

In terms of next steps in core, there’s an open feature request for adding a manual-entry measurement field to allow users to override the auto-computed measurements (in case they are incorrect).

https://www.drupal.org/project/farm/issues/3051971

It seems like that would be the first step… and then that field could be filled it automatically with a default value when an asset geometry gets saved (if it isn’t already set manually).

This would serve to expose those values via the API for both use cases (auto-calculated and manually overridden).

The big questions that remain to be answered are:

  1. How do we handle units? Acres are not used globally. Do we need to store an additional unit with every measurement? Or do we standardize on meters and leave it to API consumers to convert?

  2. Does this only get added to land assets?

Another consideration in my mind is: what about other types of measurements? Like “length” of fencing (not area)? If that’s going to be needed in the future (seems likely), then we need to consider all these use-cases together so we don’t shoot ourselves in the foot with a short-sighted implementation that only focuses on area.

Motivation

I feel this would be very helpful to external consumers of the FarmOS API, and also to the Common Convention we’re building off of the FarmOS Data Model. Farmers often associate field size (and field shape) more easily than field name, so showing acreage or an svg of the field shape in a selector menu is really key. This is confirmed by the use of these items in other FMIS / ag tech systems as well. I wonder if others like @Symbioquine and @braught agree (?)

Suggestions on implementation

  1. How to handle units

IMO you should store a known value in a fixed units, and allow the end user to modify it. Modifying units is trivial and essentially errorless on the API consumer end., calculating internal geometry is not (… the calculations are often off, there are questions about multi-polygon or cutouts, etc.). I would suggest square meters as a common unit, and potentially include it in the name like area_sq_meters to be explicit. This saves the need for additional units, and allows it to be an attribute which is where (IMO) it should be.

  1. Does this only get added to land assets?

IMO no, it should apply to all assets with an area. Arguably, it should apply to any entities with a geometry including logs. Area is so critical to so many things (calculating yield (per acre), calculating efficiency, animal growth based on areas grazed, sustainability or other supply chain calculations… the list goes on) IMO you should always calculate this if there is a geometry. Where and how it’s displayed in FarmOS is another question, but it should always appear in the API.

  1. What about non-area geometries.

I think this is a fair point… but these can be addressed one at a time. Let’s start with the 80% solution here which is area or multi-area (whether in a geometry collection or not).

What do others thing???

5 Likes
2

Oh… I also think we may want to consider looking at things like AgGateway’s Adapt model, or the one they are proposing as an ISO standard, and probably at John Deere also since this is a very important element for all those groups. They probably have structures and ideas that are relevant to the discussion.
@paul121 curious if you know what this looks like in JS Ops

1 Like
3

I agree that that having access to an area quantity associated with at least land assets would be very useful. I have not thought through other specific use cases.

For FarmData, the current use case is to calculate quantities of amendments based on recommended rates and the size of the area to which they are being applied. For example, FarmData aims to have an amendment form that when a field and amendment(s) are selected, it will automatically compute and display the amount of the amendment(s) needed. The yield calculations mentioned by @gbathree are also part our our plans, including using historical yield data in recommendations for future plantings to hit targets

I would also advocate for the ability to simply enter an area rather than always computing it from geometry or overriding that computation. I can imagine many users already knowing the size of their fields and not wanting to invest the time in marking the geometries.

My naive thought is that if assets had a quantity attribute like logs it would be a very general solution.

One other approach (though it may an abuse of the data model) could be to think of “area” (the amount of land) as an inventory instead of a quantity on the land asset. For example, a field (land asset) may change size from year to year and thus the “area” inventory of that field would change. Or for the fence example, it might be extended or shortened by different events. The inventories could then be adjusted by activity logs (e.g. building fence).

Or maybe this is just more of a fun metaphysical discussion… if we extend the fence is it still the same fence just with a different length inventory? :wink:

3 Likes
4

We’re talking to someone from aggateway has worked on the adapt standard, and I know especially in the machinery space acreage calculation is a big deal. It’s not just a single value, and it’s not just calculated or user inputted, there are additional values like the acreage including the hedgerow, the acreage excluding the hedgerow, the acreage with a buffer so that machinery doesn’t go beyond the edge when it’s generating guidelines, etc.

So I’m pretty keen to learn how others have worked on this and probably mimic that, even if it might feel a little overkill at first and foremost it is actually a complex topic I think.

3 Likes
5

FWIW in John Deere Ops Center “Fields” and “Boundaries” are separate objects:

In John Deere Operations Center, field boundaries are optional. It is possible for a field to have zero, one, or many boundaries. When one field has multiple boundaries, usually one boundary is marked Active. When a field has no boundaries, that field may still contain other data.

I think each boundary can have a name to describe how it might be used (like mentioned above, a property line vs fence line vs machine-workable area). But interestingly each boundary has two separate area and workableArea attributes, each a “complex area” object with value and unit. I guess there may be valid distinctions between a “workable-geometry” and “workable-area”? Workable geometry might be more important for tractor auto-steer while workable-area is more important for calculating various field metrics? And “workable-area” is basically a means to specify the area of the field as used for management?

Notably JD is only concerned about polygons (which they don’t use a standard data format geojson/kml for) so it may not be a good example for linear geometries. But they do allow multi-polygons.

Anyways, I guess I’ve always thought it would be best to store a computed area attribute with each geometry. Especially with this concept of “multiple boundaries/geometries” I think that would be essential. But perhaps the ability to override the geometry area (or even specify an area without having a geometry!) is useful, too, but I think these are two different things.

Having an attribute on the asset would make sense when providing a specific numerical area that has some specific meaning. But then there is the complexity… what does this single area value represent? In this case I like that JD calls it the “workable-area” because it is more specific than just “area”. It sounds like we usually want to provide this area for “management” types of use-cases, so maybe we could call it “managed-area”? And it defaults to the computed area of the geometry?

3 Likes
6

FWIW I created a “farm asset area” module some time ago that adds a single numeric decimal field intrinsic_area to all assets: GitHub - Vital-Agronomics/farm_asset_area: farmOS module that allows saving precise area calculations on an asset.

It is being used on both plant and land assets to represent the managed area. Having a dedicated numeric field makes it possible to do aggregated SUM queries. The units are inferred to be hectares or acres depending on the farmOS settings. This isn’t perfect but has got the job done.

IMO I don’t think an asset quantity would be the best option. There’s too much flexibility, especially with units. If we tried to auto-populate this value from the computed geometry area we would need to start managing unit terms from the user’s vocabulary. If they rename an acre unit to something else then things get messy. Instead, combining a numeric field and a fixed-list of allowed units makes sense to me.

This could also be a use-case for a dynamic asset attribute feature similar to what @Symbioquine has proposed, although these area attributes would not be derived from logs. In this case a quantity would make more sense and elegance… but still has issues with auto-populating :slight_smile:

2 Likes
7

I agree re. not using quantities - that would be messy, and I think these are kind of essential pieces of information. They should be stored in the same way in the same place, and geometry is already in attributes.

I also think that it’s important to note if the value is calculated automatically or not (ie assigned by the user). This is actually a broader issue… and I wonder if we shouldn’t consider solving it more broadly, for example, by having a ‘computed’ field which lists all items in a log or asset which are computed. Like this (with some made up ‘attributes’, and storing the list of computed values in a simple array which declares what piece is computed and where it was computed from).

I don’t know if this is best practice for how to handle this problem (or if best practice exists), but I like it because it addresses the broad need to allow computation across all attributes. I think especially as we think forward to planning activities and other things, this could be really handy.

Sorry mixing ideas here, but hoping this is useful :slight_smile:

{
  type: 'log--input'
  attributes: {
    name: 'the name',
    i_am_computed: 175.5,
    i_am_not_computed: 155,
    computed: [
      {
        name: 'attributes.i_am_computed',
        source: 'farmos'
      }
    ]
  }, relationships {
    asset: {
      data: [
        { id: '2323f23f-23r23fsdfsdf', type: 'asset--land' }
      ]
    }
  }
}