How to model multiple area values/geometries associated with a single asset

Using farmOS
1

We have a use case that needs to represent multiple area values associated with the same plant asset. I’m curious for thoughts on doing this in a more generalized way than just creating separate fields for each value… if possible.

The different “area values” represent different attributes on the asset:

  • field area (our standard geometry, basically the perimeter)
  • planted area
  • irrigated area
  • spray area
  • etc…

These are necessary because the total area associated with each “attribute” isn’t necessarily the same. These differences are significant when performing calculations over the total area: 20k gallons water applied to 20 acres vs 18 acres.

A good example of this is an Orchard. The field area might cover an area larger than the actual planted area due to access roads around the perimeter or other natural obstacles. The irrigated area is likely smaller than the planted area due to rows/roads in within the orchard. Similarly, the spray area could be different than the other values.

I see the argument for keeping the field acres and planted acres as separate assets with separate geometries, and assigning one asset as being located in the other. But (in my opinion) this added complexity shouldn’t be the only option.

One complexity is how to store these values… a couple options…

  • As a percentage of the total area (doesn’t seem as flexible)
  • As the actual total area value (decimal)
    • But how to account for different units? save in metric and convert as needed? or save the value as a quantity w/ specified units?
  • Store separate geometries for each, and compute the total area
    • Hard to store a specific value
    • Not needed for my use case where only the total area is needed, but this could be useful if the geometry is inherently important to the attribute. Is the irrigated area a straight line or curved??

Then there is also the matter of how/where to associate the values with an asset…

  • Create a separate field on the asset for each value - asset.planted_area, asset.irrigated_area, etc.
    • Maybe a single quantity field?? Then a quantity could be added for each of the above area attributes with value, units and a label.
  • Save the data in a log that references the asset
    • Don’t like this, these values do seem like they should be “attributes” of the asset
    • But this might be the best way to save some additional geometries describing the asset… like a geometry of all obstacles in a field as an observation log
  • Take it a step further and create a concept of “area attributes” as a single field, where assets could provide values for only the “area attributes” applicable to them (only provide planted & irrigated).
    • This is similar to a quantity field, but could be more tailored to the area attributes.

This reminds me of the “farm_trait” concept @Symbioquine proposed awhile ago: Implement a farm_trait module by symbioquine · Pull Request #285 · farmOS/farmOS · GitHub. Not quite the same, but similar.

Anyways, curious if this seems useful to others and if so, how it could be abstracted a bit more than just separate fields for each value.

3 Likes
3

@paul121 Thank you very much for this long and detailed post. There are a few approaches to these important issues. The bed feature is one option to deal with different areas within a field but in my opinion its too simplified for usage in a orchard for example. We have been using the line option to locate the orchard rows but this is not connected to a real area calculation.
The use case you mentioned would be useful in vegetable fields, orchards and could be quite useful in agro-forestry systems that grow multiple row crops in a single field (e.g. wheat + walnuts or olives…).

For a normal orchard you would have the

  • total field area
  • area/ rows planted with trees
  • irrigated area (depending on application method sprinkler or drip irrigation; and number of drip lines (1-2) besides the row and spacing of emitters in the drip line (in the case of drip this would result in different wetting patterns depending on the soil type and the discharge rate see example of wetting patterns depending on discharge rate)
    *spray area, fertilizer compost application area
    • one could calculate this aromatically by adding the application area (by value field, available to the user) to each side of the row. This would actually be a very useful feature for precision farming of orchards.
  • there is also the area between the rows that might receive a spray or fertilization application, that could be calculated be subtraction of the other areas (however it might be useful to be able to exclude the headlands)

If possible a ‘stacked’ approach might be used but it needs to be flexible

  1. level total field area (metric decimal and convert as needed)
  2. planted row areas
  3. irrigation area (this is where it gets tricky, since this might not be the same every time due to the intensity of irrigation), maybe one could use some formula to calculate this based on irrigation method, soil type, discharge rate and time period)
  4. weed control strips directly underneath the trees
  5. spray and fertilization area (this will be variable and change and also depend on the age of the orchard, with older and larger plants a bigger area might receive applications)
  6. grass alleys between the rows that might receive some inputs if precision application of fertilizer is not possible or wanted
  7. headlands, hedges and slope areas

I would suggest to store values in metric with conversion as needed. This could also be done automatically.
In general I would split the field in the areas mentioned above but maybe the actual area of each application could be stored in a log.

It would be great if we develop a approach that enables such a feature set.

2 Likes
4

I believe all these geometries can be represented with assets and logs already…

  • field area (our standard geometry, basically the perimeter)

This would be a Land asset (in 2.x, an Area in 1.x) with an intrinsic geometry.

  • planted area

The Plant asset can have a movement log (for an orchard this could be either a Transplanting or simply an Observation log). In 2.x you can also represent this without a movement log as the asset’s “intrinsic” geometry, and make the Land asset a parent).

  • irrigated area

Ideally this will be represented in the geometry field of an Input log - to record the actual places that were irrigated each time, along with quantities. If the irrigation system is permanently installed, and covers a fixed area, then this can be added as a “Water” asset (or water area in 1.x), which can then be referenced by input logs. This will automatically copy the geometry into the input log when it is saved, saving you time if it’s always the same geometry.

  • spray area

Similarly, this should be recorded on input logs, IMO.

Now, all of the above is the “ideal” approach according to the data model - but that doesn’t mean it’s the only way to do it. If you want to create a custom module that adds additional fixed geometry fields to the Plant asset, that is also certainly an option.

I see the argument for keeping the field acres and planted acres as separate assets with separate geometries, and assigning one asset as being located in the other. But (in my opinion) this added complexity shouldn’t be the only option.

I think this separation is warranted for exactly the reasons you need it to be! You have different assets: the land and the plants that are on it. Even if they are mostly the same, the fact that you need a distinction is the reason for keeping them as separate records.

Take it a step further and create a concept of “area attributes” as a single field, where assets could provide values for only the “area attributes” applicable to them (only provide planted & irrigated).

Ah OK maybe I misunderstood… it sounds like you are primarily concerned with storing a number (the total area), and less so about specific geometries?

Store separate geometries for each, and compute the total area

  • Hard to store a specific value

I still feel like this is the best way to do it. It isn’t too hard to get a specific computed geometry value when you are drawing a polygon on the map. The computed area is shown as a tooltip over the polygon and updates as you move vertices around, so if you absolutely need a very precise value (eg: 20 ac instead of 20.05?) then you can get close enough I think.

The main reason for using geometries on assets and logs, in my mind, is that it makes it possible to account for changes over time. I’m assuming you want to use these numbers to generate reports and/or auto-generate input logs with quantities pre-filled? What happens if an area is expanded? Or new irrigation systems are installed? Or you aren’t able to spray the entire “spray area” for some reason?

By keeping these things as separate assets/logs, a report can take these changes into account. Otherwise, they would need to dig into the asset revisions to get a truly accurate result.

Maybe this is overkill for your use-case. If so, and you want something simpler (and more custom), then perhaps some custom fields on the asset is the best option.

Another thought that comes to mind: perhaps some of these things should be represented in a “Plan” entity, which provides UI for drawing out “target areas” for each type of activity (irrigation, spraying, etc). Along with UI for recording “actual” events, which then save as Logs with specific geometry and quantity. It does seem like a lot of what you’re aiming for is about planning/reporting. But I’d be curious to hear more about the end goals you have in mind.

There’s been some talk about a general purpose “Input Plan” that handles these “target” vs “actual” applications, reporting, etc. Perhaps that would be worth thinking about in this context as well!

1 Like
5

Great thoughts @Lars and @mstenta. I think I agree with most of your suggestions that ideally this could represented with separate assets + logs, especially in the “ideal” data model.

Thinking about it as “stacked” as @Lars described makes sense, and that could likely be represented in the hierarchy of Land Assets (areas in 1.x). A land on asset on top, with Plant assets (orchard + maybe additional for hedlands, etc) and Water assets (irrigation). A separate log for each activity certainly gives the most granular level of control, especially for changes over time.

Agreed - glad you mentioned this (I hadn’t thought of it!) but the auto-copy of geometry into the input logs would be quite helpful.

Must admit I don’t like the redundancy of saving the same geometry multiple times, but these are good reasons. Edge cases and “what ifs” are bound to come up. Perhaps instead of auto-copying the entire geometry, I could just copy the total area of that geometry into a quantity on the input log. I think that is all I need anyways…

Perhaps a plan would make sense here… the values I described aren’t necessarily “target” area values since it is a fixed irrigation system, but it might make sense to save them on the plan. The general challenge with a plan would then be needing an irrigation plan for each asset. Technically I think that’s OK, it’s really just a UI problem… but hmm. At that point, it’s probably just easier to add custom fields to the asset itself. An a single irrigation plan that monitors multiple assets? Hmm.

The end goal is evolving as I get more info… :smiley: my objective right now is figuring out how to represent what’s happening. But goals seem to be tracking & optimizing overall water usage for what the plants/trees need. I suppose there is also a desired element of detecting problems/broken irrigation equipment too.

A few other implementation details are that the irrigation activity is coming from sensors (unsure what the data looks like!) and each sensor represents a flow of water going into multiple areas. These are specific details, sure, but I don’t think this will be all that uncommon in larger operations. Ideally there are sensors detecting flow at the most granular level but that costs $$.

With this coming from sensor data I’m not sure a log is really necessary… but maybe it makes sense. With the new quantity system I think it would be possible to have multiple “input quantities” on a single log that represent how the single flow was split across multiple plantings. This could be configured on a Water asset (or maybe Irrigation equipment - hmm).

This way the raw sensor data doesn’t need to be saved, but just converted into logs. Need to think more about if that will be OK… but I’m coming around to the idea of using logs. My main concern is that this will create A LOT of input logs. Again, perhaps it’s mostly a UI issue… but I also have a feeling that these things coming from sensors are better saved as raw sensor data.

2 Likes
6

Must admit I don’t like the redundancy of saving the same geometry multiple times

That’s understandable. Most of the time shapes don’t change, so saving the same ones over and over does feel redundant.

farmOS’s goal is to keep an archival and granular record of everything, though, and that requires thinking about each event as a self-contained representation of the data. Logs reference other records to create a web of context and understanding, but ultimately all data that is core to the log itself should be stored on the log - and this includes the geometry.

The side-effect of this is that the same geometry may be saved many many times in the database, which could be considered inefficient at some scales. But, that should be considered a separate problem, in my opinion, and it could be solved with some form of indexing in the future if need be (eg: imagine a table of all unique geometries, which are then referenced by logs/assets). These should be considered a separate layer from the “data model” representation in either case, and would be more of a performance enhancement. Each log needs to be able to have its own geometry, regardless.

The general challenge with a plan would then be needing an irrigation plan for each asset.

Not necessarily. Perhaps irrigation plans encompass multiple assets, like crop plans do, and are instead organized by location or season. Lots of options!

With this coming from sensor data I’m not sure a log is really necessary… but maybe it makes sense. With the new quantity system I think it would be possible to have multiple “input quantities” on a single log that represent how the single flow was split across multiple plantings.

Yea it depends on how you want to report/summarize it later, but in many cases I think having logs would still be valuable. The benefit of a log is that it is a granular “event” associated with specific assets, and with fixed quantities. These could be generated from sensor data, while still having the data stream as a raw and separate record (tied to the irrigation system itself, rather than the assets receiving the water, perhaps). Lots of ways to slice it, depending on what the goals are! :slight_smile:

My main concern is that this will create A LOT of input logs. Again, perhaps it’s mostly a UI issue…

Yea this is valid! But I do think it’s mostly a UI problem. With better filtering/indexing it ideally wouldn’t matter if you have hundreds of logs per season or hundreds of thousands! The UI we provide for filtering logs is still pretty basic IMO, and I expect we’ll need more specialized options as data scales!