There is a local university to me that was looking for ag related projects they can have students work on for their capstone project this fall. I had proposed to them they build the farmOS grazing module similar to the v1 module. I got notice today that the school is looking to move forward with this project and will assemble a team of computer science and animal science students to complete this module in the Oct-April simester.
This is all very exciting! On that note what does the community want to see in a grazing module? If you have input on features let me know. I will start to compile a list as I sit down and work with the student team.
This is awesome @BOTLFarm! I know there are others interested in these features, so I would love to help in any way I can. I may be able to carve out some time during their semester to provide support/guidance and bring other stakeholders together.
Some quick thoughts⌠based on the lessons I learned from the v1 grazing module:
The v1 module was built very strictly to mimic the Savory Holistic Management techniques, because that is what our sponsor wanted. If I were to approach this again, I would have made a simpler and more generalized Grazing module, and a separate Savory-specific module as a layer on top of that. There are a lot of things in the v1 Grazing module that could be omitted in a general grazing module IMO. It might be worth reviewing and outlining exactly what that module added, and take a pass at conceptually teasing them apart into two lists.
At the core, I think a grazing plan needs two types of entities:
A plan entity of type grazing, which represents the plan as a whole, and:
A set of plan_record entities of type grazing_event (or something like that), which represents a period of time that a set of assets (group or animal) are in a certain location (both a location asset reference and a unique geometry).
A grazing_event data structure would represent the planned grazing event and might look like this:
plan - references the plan that the event is a part of
log - references the activity log that will represent the actual movement of the assets, which includes:
timestamp - the actual movement timestamp
asset - references the animal / group asset(s) that are being moved
location - references the land asset that they will be in during the event
geometry - the specific geometry of the planned grazing event
start - a timestamp representing the planned start date/time
duration - how long the animals will be in this place
recovery - how long the grass will need to recover after the animals leave
A grazing plan could then be visualized in a Gantt style where each row is a grazing_event, showing the period of time that the animals are in a place, and the period of time after they leave that is needed for recovery.
It would be great to reuse the same Gantt chart code that weâve started developing in the Crop Plan v3 module. @paul121 and I talked about splitting some of that out into a reusable library that we include with farmOS core, so that other module (including core modules) could make use of it in other contexts. If we are able to do that before these students get started, they would be able to leverage that to use the same Gantt visualization for paddock rotations.
Perhaps a good question to help spark more conversation is: what would folks like to have in terms of âplannedâ vs âactualâ data? What is most useful to be able to look back on and learn from, assuming that things always change?
My thought exactly V1 was usable but in some ways too complicated. One of my favorite functions in the v1 module was to plan my rotations then if I made a modification (moved the animals faster, or they were in a paddock longer) then it would adjust the entire schedule looking forward.
It has been a while since v1 but I remember it being messy with multiple groups of animals in different places, following different schedules, and different paddock rotation patterns. Hopefully we can figure out a cleaner way to manage different groups. Maybe they are just different sub plans for of a seasonal grazing plan.
I think recording the actual day in, day out and calculated length of time is critical data to display. Along with a stats on how long a particular paddock has been in recovery, especially if this can be represented by the different groups or species. IE. recovery from sheep group has been 20 days and recovery form chickens group it has been 15 days.
Pasture conditions when they were moved in and out would be nice also. This could be forage height, photo, or a notes section, etc.
It would be cool to see how the schedule changed over time as the season moved on. Maybe a slider on the gantt chart to view planned moves as the year progressed.
It is great that this topic is back under discussion.
I have fall in the temptation of modifying on the fly the âgrazing planâ by editing the original âplanâ values with the âactualâ ones. The immediate reward was that the rest of the plan accommodated straight in behind of the last âactualâ. However, the trap was set and at the end of the season I realized I couldnât compare the planned with the actual, because the plan was swamped only with âactualâ data. Therefore, I think a good system has to run both in parallel: âplanâ and âactualâ
A digital set of recent âactualâ data is good for answering current important questions, such as in the case of an on-farm audit: the auditor requiring further detail on a matter and the farmer providing a fast answer showing that he is in control of his records, which is something the certification body needs to see happening to know there is a paper trail in case a complain or an outbreak arises. Thatâs all very obvious.
However, when it comes to using the data that has been gathered for years for improving the business, what questions one has that, if answered with all the keyed-in data, will lead to doing so? I find this is the difficult bit.
Sometimes I find myself with lots of accurate records great for âdata miningâ and still waiting for a genius to appear with the a posteriori golden question that will revolutionize the business
Then, I think it would be great if first professor/students attempt to define questions they wish answered with the data they will collect, before they set themselves to modeling and coding a grazing plan module.
Yea I think we should keep each plan relatively simple, and just encourage the use of multiple plans. So if you need to manage multiple herds, you just need to use multiple plans. Rather than making individual plans complicated.
The main consideration, I think, is that the recovery time of a paddock needs to take into account planned grazing events across plans. Not just the events in the plan youâre currently looking at. That wouldnât be too hard to query. The only question it might raise is: what happens if you want to âexperimentâ with some different options by creating multiple âpotentialâ plans side-by-side, before ultimately choosing which one to go with. In that case you wouldnât want them all interacting or adding to the recovery time calculations. But maybe that can be solved simply with a new plan status. In addition to active and archived, maybe we have another status called planning or something like that. And then we only use active plans in the cumulative recovery time calculation?
Oh yes that would be great. This was something that the v1 Grazing module provided, IIRC: a hard-coded list of animal types, with some stats about dry matter intake requirements on each that contributed to the calculations.
Agreed! I think this could be a new quick form, which creates observation logs. It could even be useful outside of the Grazing plans⌠and make it available from within the plans.
Great point @Guillermo. I do think itâs important to keep that distinction.
And the approach weâve taken with the Crop Plan v3 module is a good example of how we can accomplish that, I think! In a Crop plan, the âplannedâ seeding date, days to transplant, days to maturity, and days of harvest are stored on the plan itself. But the assetâs logs are used to record the âactualâ information, and both are displayed in the same Gantt chart.
I think we could accomplish the same thing with grazing events, by showing both the âplannedâ periods and the âactualâ locations of the animals. I can already imagine how that might look. Maybe we can do some whiteboard sketches on a future dev call and take some screenshots for this thread.
I believe it did this and based calculations on herd weight (or individual animal weight), which was not always practical to have.
I think this is useful in some situations but in many of my situations it starts to look like the overly complex v1 plan. For example when I graze pigs and chickens I donât particularly care about the dry matter intake they are getting form pasture, I just want a certain amount of time on a particular pasture. But with my sheep and goats dry matter intake is useful, but can be really hard to calculate in a silvopasture paddock, so if this is a requirement it may not be flexible enough for every days use.
Multi species grazing this becomes complicated very fast on seperate plans if you canât see what the other species are doing. I want recovery periods not only for plant/soil health but also for parasite reasons. For example I want my small ruminants to graze a paddock first for 12-32 hours (depending on the paddocks size and condition) followed by a minimum of 5 day rest, followed by chickens for 1 day. I want total rest period after my small ruminants to be 45 days for parasites before the small ruminants return, but it only needs a minimum of 30 plant recovery after my chickens, or whichever is longer. If I happen to move pigs thought that paddock in the meantime then I would want a 40 days recovery for plants as they do more damage before ruminants move back.
For me a lot of planning is manual as i think it may be to complex and too many moving parts to automate it all based on recovery times. But if recovery times of all species were displayed together then manual planning becomes easier. Maybe this means when in the sheep plan I can see an overlay of the other species. Hmm⌠but if i need to make an adjustment to the other species then im jumping between plans. Maybe each season is a plan and you can add âtabsâ to jump between each species. Switching tabs just activates the species you want to work on. Just some ideas.
Gantt is nice, maybe overlay on maps also? I donât necessarily follow the same pattern each time around the farm.
Yea, and Iâm not a fan of hard-coding the list of animal types.
This also raises the bigger question: how do you calculate recovery time? That was the main output of all the pre-data that needed to be entered in v1⌠which is why the actual âRoationsâ tab was the last thing you saw in v1. It makes sense from a planning perspective⌠but I wanted that to be up front and center.
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.
Barely begun⌠definitely not ready for use. But Iâm starting to make decisions, so I want to share with this thread and ask for inputâŚ
Iâm sketching up the initial data architecture based on my comment above, and have a question for the groupâŚ
How should we model the data types for start, duration, and recovery?
Based on what Iâve heard (from @BOTLFarm in this thread, and when I was working on the old Grazing module), we will want to allow rotations that are less than 1 day in duration. In other words, some operations move a herd multiple times in one day.
With that in mind, I think start needs to be a timestamp, so that it can capture time as well as date. Maybe we can hide time via UI/UX magic for folks who donât need that granularity, but it needs to be there in the data model for those who do.
What about duration? Should that be an integer? What granularity should we capture? Is âhoursâ granular enough? Again, we can handle things on the UI/UX side for folks who only deal in days/weeks, but from a data model perspective we need to decide the minimum granularity right now.
Same question for recovery. Grass only grows so fast, so I imagine âdaysâ is granular enough for this one?
Does that all make sense? Am I overlooking possibilities or excluding anyoneâs use cases with those assumptions?
Iâm on board with hou you defined start and duration@mstenta. There are occasions when I do a super dense mob grazing for 30 minutes in a spot but as far as my records go this is overkill on data and grazing to the hour is enough for.
Depending on how recovery gets used in application I can see the possibility of wanting to define it in hours. This may be me thinking how to force a system that is not built yet to do something different then it is designed, but hours may be useful in a multi species grazing situation where you want to graze species one then species two 12 hours behind. Not a good use of the term recovery but just thinking of ways people may want to use it and keeping things flexible.
Iâm not sure Iâd define that as a recovery though?
Maybe you need a different min pre-grazing yield per livestock type?
Should recovery be measured in time at all or rather actual grass measurements? As recovery time can vary hugely but a target pre-grazing yield is more definite.
Agreed! Iâm just thinking back to the V1 module and the types of things I had to do to make it work for my situation.
As far as recovery time vs pre-graze height, I typically graze tall and leave lots of residue behind. I look at recovery time from a parasite load lense more than a grass height lense, so for me time is more important most of the year. But of course have to take into consideration pre-graze height.
Intensive grazing is a hard thing to predict and plan for in a lot of situations.
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.
Itâs not hard to imagine scenarios where folks want to know the difference between planned and actual timing. At scale, Iâm imagining that the cumulative effect of moving grazing animals 15 minutes early every day could be non-negligible over a season. Presumably, youâd miss that detail if you were forced to round the number of hours up or down at data input time.
In practical grazing terms, Iâm honestly finding it hard to think of too many scenarios where finer granularity then an hour for grazing or day for recovery would be useful, but not opposed to finer granularity either if itâs likely to suit others.
Could just be my Irish timekeeping showing though.
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.
We had a great discussion on the monthly call today about this. I showed a rough sketch of a timeline visualization of grazing events that Iâm working on and we talked about the current data model and potential scenarios and use-cases. I didnât take notes but Iâll add comments here as I remember thingsâŚ
One interesting thought that came up at the very end (actually after most people left): do we even need to store duration? Or can we just visualize it based on when the ânextâ movement log out of the paddock is?
One benefit of omitting duration from the data model is that itâs one less thing to manage and keep updated. You could, for example, simply drop a log in between two other events and it would automatically adjust the visualization of durations.
The benefit of storing duration is that it captures the âplannedâ duration of the event. Without it we only have the âactual.â So I donât think Iâll remove it for now, but wanted to make note of these ideasâŚ
I want to emphasize that this is a very simple sketch, primarily to validate the data model, and to see if it can accommodate everything we want. This is far from usable, and a lot of it was able to be sketched up quickly by copying and modifying code from the Crop Plan module. But all of the ânext stepsâ will require more development work. Hopefully we can get this to a place where students can pick it up and run with it to work more on the UI/UX nextâŚ
There are a few things missing that I might try to knock off quick (and then this might be ready for others to start testing):
Allow editing grazing events by clicking on them in the timeline (similar to Crop Plan).
Show the movement log as a dot, to differentiate the âplannedâ from âactualâ event.
We also discussed an idea on the monthly call that would be really useful for a number of reasons: show all logs associated with the Asset/Location on its row (above the grazing event rows). For example, if you have other logs associated with the âSheep Herd 1â asset, they would show as dots for quick reference in the timeline.
