Thanks for all the input @Farmer-Ed @BOTLFarm @Symbioquine!
Great thoughts regarding recovery, and the different ways of calculating it. On that note, I want to emphasize that right now (early data model design), I’m only concerned with what needs to be stored in the database. How that gets calculated (manually, based on other data like grass height, etc) can be figured out later. That can be a UI/UX concern, I think.
As stated earlier in this thread:
Regarding grass measurements…
In farmOS v1, the “Animal Movement” quick form included options for recording grass height before/after movements. We generalized that quick form to be applicable to any asset type in v3, and removed those options. But I’m imagining a new quick form specifically for pasture condition observations, which could potentially be used in tandem with this Grazing Plan module in the future, perhaps as an input to some kind of “suggested recovery time” calculation.
The v1 module was based very strictly around the Savory Holistic Grazing method, which is one way of calculating recovery time. I think that method could be provided as an add-on option on top of all this, potentially. But for now we just want to lay some groundwork that is unopinionated in that regard.
I’m redesigning this new module from scratch, and trying to be as simple as possible with it. The primary goal right now is to define the data model, with maybe some minimal UI/UX work. @BOTLFarm might be working with some students this coming fall to pick up from there and focus more on the UI/UX.
In my mind, the minimum data model just needs to represent a “grazing plan” with a set of “grazing events”, that define the grazing duration and recovery of each geometry. With this, we can then render a timeline visualization similar to the one that we built in the crop plan recently. And notably, each “grazing event” will link to a movement log that represents the actual movement. So we can use logs for the actual and these grazing events (aka plan_record
entities) to store planned info like planned start date, duration, and recovery).
From there, the sky is the limit for next steps! This first pass just lays the initial data architecture, but then everything else can be about additional UI/UX for data entry, recovery calculation, pasture observations, etc etc etc. This module will primarly be concerned with grouping and visualizing the events.
From what I’m hearing, “days” seems to be an appropriate granularity for recovery time. However, I also see @Symbioquine’s point that from a data model perspective it doesn’t really need to be limited, and could potentially be stored in “hours” or “seconds” in the database. This might be overkill most of the time. There is also something nice about consistency between all of the values (start
, duration
, and recovery
), though, if we were to just store them all in seconds (start
is a timestamp so it’s always in seconds anyway). But seconds does feel like extreme overkill, so maybe a good balance is to just model both duration
and recovery
in hours, so at least those two are consistent? The more I think about it, it feels weird for duration
and recovery
to have different units. Especially if you consider a third-party application that wants to modify these via the API. Consistency at the data model level is better for DX.