# Grazing Plan Module Brainstorm **URL:** https://farmos.discourse.group/t/grazing-plan-module-brainstorm/1970 **Category:** Development **Created:** [April 9, 2024, 5:05pm UTC](https://farmos.discourse.group/t/grazing-plan-module-brainstorm/1970 "2024-04-09T17:05:17Z") **Posts on this page:** 1 **Showing post:** 18
### Author: ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta) #### Post date: [June 11, 2024, 2:11pm UTC](https://farmos.discourse.group/t/grazing-plan-module-brainstorm/1970/18 "2024-06-11T14:11:20Z")
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: > [@mstenta](#): > > But if we started with an MVP (minimum viable product) of manually entering a recovery time (based on all the knowledge you already have in your head @BOTLFarm), then that gets the bare minimum job done… and that could then be automatically filled by one (or more) “recovery time recommendation” algorithms in the future as a next step (but also always allowing manual entry/override). > > Start simple and trust that the farmer knows best. 🙂 Regarding grass measurements… > [@BOTLFarm](#): > > +1 to the grass measurements @Farmer-Ed! 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. > [@Farmer-Ed](#): > > I never used the V1 module, but I don’t think we should be limited to what it had either. But I guess it makes sense as a starting point. 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). > [@farmOS Crop Plan module v3 alpha release](https://farmos.discourse.group/t/farmos-crop-plan-module-v3-alpha-release/1934): > > I’m pleased to announce that we just released the first “alpha” version of the farmOS v3 Crop Plan module! tada Read the release notes in that link for more information and to understand what to expect (and what not to expect sweat_smile). It’s safe to install this and start playing around with it, but it’s important to understand that this is still just a proof-of-concept. We have the basic data architecture nailed down (but there’s more to do!) an… 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. > [@Symbioquine](#): > > I don’t have a horse in this race (or pasture as it were), but I think I’d argue for not choosing aggressively coarse time units at the data-model level. > > Simplifying the input and display so users generally don’t have to type/see the minutes and seconds should be a separate concern IMHO. 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. --- _[View the full topic](https://farmos.discourse.group/t/grazing-plan-module-brainstorm/1970)._