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.
