FYI for anyone who wants to try this out now, you’ll need three things:
farmOS with the 3.x-timeline branch of my fork checked out: GitHub - mstenta/farmOS at 3.x-timeline (This generalizes the timeline UI components out of the Crop Plan module so they can be reused in the Grazing Plan).
I would be very curious to see what it looks like when we throw all kinds of weird data at it. For example: lots of movement logs referencing lots of different assets and locations in different combinations. The grazing plan timeline UI logic should be able to display them all… but it might not be pretty.
One of the neat features of the svelte-gantt library we’re using is the reflectOnParentRows option. When set to true, this causes all of the child tasks to be “reflected” on the parent row. It was set to false in my screenshots above, but this is what it looks like when set to true with the same data:
The “by Asset” display shows all of the grazing event durations and recovery periods overlapped on the “Sheep Herd 1” row.
It’s nice to have the “durations” displayed here, but the “recovery periods” feel unnecessary. Unfortunately it doesn’t seem like there’s an easy way to limit what is reflected in the parent row. It’s all or nothing by default. But it raises a question: maybe “recovery periods” could be hidden in the “by Asset” display altogether, and only shown in the “by Location” display? And maybe “by Location” should be the default that you see when the plan loads?
Here is what the “by Location” display looks like, with the parent rows expanded and collapsed:
The collapsed version is more useful on the “by Location” display I think, so perhaps it would make sense to default to collapsed for that display, but leave it expanded by default on the “by Asset” display.
Yes! We talked about potential map features on the monthly call. Excited to see what might grow on top of this.
The colors represent the duration of the grazing event (green), and the recovery time of the area afterwards (orange). So you can see how long to wait before moving animals back into the same area.
If you are familiar with the farmOS location logic, and/or you have used the Movement quick form, you know that it’s possible for an asset to be moved to a sub-geometry of a larger area. This is how you can represent that animals were moved to a “temporary” area within a paddock, for example. Some graziers use movable fencing to intensively graze sections of a paddock, for instance.
This new grazing module simply references individual movement logs, so in theory it supports the same level of granularity. But it doesn’t currently show anything in the UI to indicate that a particular grazing event is a sub-geometry. So right now, if you have 6 grazing events in different areas of “Paddock 1”, you will just see “Paddock 1” listed 6 times in the grazing timeline.
This also makes me wonder about the way we’re modeling “recovery time”. The recovery period is only relevant for the area that was actually grazed, which is a bit tricky to represent in the timeline UI. Maybe a map visualization is the only way to effectively visualize these sub-geometry movements.
Even so, and in the meantime, is there anything we can add to a timeline to make this easier to see? @paul121 and I were thinking about adding “mini geometry” icons of some kind to each row in the timeline as a way of visually showing the different shapes (we’ve also talked about adding this to other places in the farmOS UI, which I think would be really nice). This might help a little in this particular case, but if all of your sub-geometries are the same shape (rectangles in the same orientation), then it still wouldn’t help.
Of course, if you add separate land assets for each “sub-geometry” with unique names, it avoids this whole problem. It’s just more assets to manage, and ultimately a lot of these decisions come down to how you’re managing your operation. So in some ways this comes down to conventions. But I’m curious if we can find clever ways to visualize the “temporary” geometries in this UI.
It could help if you also render the polygon for the enclosing location.
e.g.
vs
Owing to some nice properties of farmOS’ geometry support, it is actually pretty trivial to render geometry to SVG - when one ignores all the broader map rendering concerns (like interactivity, coordinate-reference-systems, etc).
Hey @mstenta I think this should be the next thing we prioritize here because it really seems quite important for this brainstorming process. Without this it’s easy to miss in these screenshots that the “planned” movement time is captured in addition the “planned/actual” movement log. Looking back on these conversations I think our use “planned” has been confusing and let this slip as well.
In some ways I wonder if there is desire for a “simpler” grazing plan that is truly only movement logs and a visualization/editor that lets you make them in future and mark them done as necessary. This could be accomplished quite easily if we generalized the concept of durations/recovery periods to be some data associated at the log level.
Of course the desire to have the true “planned” data is clear and valid as noted above:
Adding the complexity of “planning your grazing plan” is significant for both the data model and visualization. I’m still wanting to learn more about these planning use-cases specifically, it needs more thought IMO…
I myself certainly don’t have the answers/definitions of these questions but would like to see some discussion focused on this idea!
The proposed data model that includes log references in the plan_record is convenient. The log reference defines the target animal and location assets so this “planned” grazing event data will always match the “actual” grazing event animal and location in the future. The only potential difference is the actual event timestamp and duration (in relation to other grazing events).
I think this data model misses two important planning use-cases though: when the target animal or location for a "grazing event’ changes mid-season from the “planned”, there is no way to separate this intention from the “actual” data on the log (unless if you consider log revisions). In some ways this is a matter of perspective, I’ve heard “are you managing the grass” and “are you managing the herd”, but maybe you’re just “managing for efficiency/constraints” of human time and working around natural events…
eg: when a weather event creates significant impact on the landscape and its not possible to move one herd of animals, perhaps a different herd gets moved to the pasture. OR perhaps a pasture is no longer suitable for grazing, so the herd gets moved to another pasture.
I see the planning and actual layers as two separate “full” data models that need to be layered on one another to answer some of these “what happened” questions.
For my personal use case season long planning does not work for me. I move lots of groups of animals in very different rotation timelines and in very different rotation patterns. With lots of small frequently moved paddocks I find I can only realistically look out a month or so in advance. Anything beyond that and I can’t accurately predict the regrowth/recovery due to weather. The system is a lot more weather dependent for me ie. If it is really hot move animals faster out of the fields and into the silvopasture. Or we are having a great growing season and I want to skip the woods rotation and keep them in the open fields. It is a much more dynamic system in my case.
This being said I don’t find a lot of use looking back at previous seasons grazing as a whole. I am much more interested in what groups of animals were last on the paddock and when this season. I don’t find it useful to plan an entire grazing season at once then refer back to. Looking back at my last planned rotation vs actual is useful but this is only a look back at planned for the last 35-55 days typically.
I know a lot of pasture based farms will want to do a full year long plan and see the comparison though. So it seems to be a much more dynamic of what people want out of it.
All that being said I don’t know the best way to visualise this for everyone. Certainly a moving timeline showing how the grazing plan has changed day to day would capture probably everything people may want to see out of the plan, but that my be overkill. Maybe a “snapshot” button and that save views of the plan whenever someone wants.
Each “movement row” shows a single yellow dot representing the actual movement log.
Notice that on the first “movement row” (“Move Sheep Herd 1 to Paddock 1”) has a movement log that happened later than the planned movement date. That is how the difference between planned and actual is represented.
On the “By asset” view, it is also adding ALL of the asset’s logs as dots. This was an idea that came out of a previous dev call conversation. You can see that there’s a blue dot representing a medical log.
Regarding (3)… these dots are currently only displayed on the “By asset” view, not on the “By location” view. We could consider doing the same thing on the “By location” view, but I think that would need to load the location asset’s logs, not the animal/group asset’s logs. And I’m not sure how useful that would be. It might be confusing?
Note: much of the stuff you see in these screenshots is dependent on core features that are currently in development but should be included in the next minor release of farmOS (v3.3.0). Once that’s released I will tag an alpha release of the Grazing plan module so folks can start playing around with it.
Agreed it should show location asset logs and not animal asset. This would be interesting to see how busy it gets, but I think it would be super useful for planning purposes to quickly see all logs associated with a location.
As it gets closer to students starting to work on this project I have compiled a list of basc module requirements and if they get that done extra features they can work on.
Goals of the module basic functionality:
Be able plan movements of multiple assets
Visualize multiple assets on the same screen for planning
Visually depict movements on a gantt chart
Actual plan
Planned plan
Visualize other paddock/group events on grazing plan (harvest, inputs, etc)
Connect movement logs together (ie. when one log gets delayed then all logs down stream of it get time adjusted)
Basic scheduling of rotation
Recovery periods
Grazing length
Rotation pattern
Quick form to record actual gazing event
Ability to use sub geometries of a paddock
Advanced module functionality”
Quick form to include observation logs on paddocks
Photos
Graze in height
Residual left
Holistic grazing integration (similar to V1) as an optional addon
Dynamic adjustment of recovery period, herd growth rates, etc
Dry matter intake requirements
Multi-species or leader-follower “recovery” time
Visualizing movements on map
Let me know if anyone has thoughts or if I should add/remove anything to this list for the students to work on.
During the last comunity call @Farmer-Ed showed some grass prediction graphs that would be super useful in a grazing module. Recording falling plate measurements in paddocks to predict how much forage is in each paddock and how that projects over time. I think this would be a nice additional to the “Advanced Functionally” of the module. I think this is a bit more info on what the “holistic grazing” integration I mentioned above could include.
I obviously think this could be very useful too, but I haven’t sat down to work out how the data model might work in farmOS. I’ve a feeling this may need to start as a separate module, as there may be a fair bit of wok. I’m open to some brainstorming though.
Please read the release notes to set your expectations… (copied below)
1.0.0-alpha1 2024-09-24
This is the first official alpha release of the farmOS Grazing Plan module.
It is considered “alpha” because it is still very much a proof-of-concept, and is not going to be useful for most real-world grazing planning. It can be used to visualize grazing events on a timeline, but using it for day-to-day management is quite tedious. Moving forward, we hope to work as a community to identify and prioritize next steps based on what would be most useful.
This project is inspired by the original farmOS v1 Grazing module, but was built from scratch with a new data architecture based on farmOS v3. The v1 module was designed around a specific prescriptive grazing management system, but this one is designed to be more general. The hope is that it can be used as a foundation to build more prescriptive workflows on top of.
Here is a summary of the major features this release provides:
Added
“Grazing” plan type, with a “Season” reference field
“Grazing event” plan record type, with a “Log” reference field, a “Planned start date/time” field, and fields for “Duration (hours)” and “Recovery (hours)”.
Form for adding movement logs to the plan, along with plan-specific metadata.
Gantt chart visualization of grazing events in the plan, using svelte-gantt, with the ability to view by asset or by location.
Great list @BOTLFarm! I think the first alpha release of the Grazing Plan module covers some of these items (more or less)… but all could be iterated on and improved!
Some quick notes/thoughts based on the points you outlined:
See my screenshots in this comment above for what this currently looks like.
This is NOT implemented yet. Makes good sense to provide some automation for these kinds of updates!
We may want to consider how “grazing event” logs (logs that are connected to a grazing plan) are managed. There are multiple ways to change a log’s timestamp… from within the plan, editing the log directly, using the “Reschedule” bulk action, using the API, etc etc… so it probably makes sense to implement this “connected movement logs” logic at a low-enough level so that it happens in all cases.
Perhaps grazing plans could have a configuration option “Automatically reschedule logs” (enabled by default, I imagine), and we add an event subscriber that runs the logic whenever any log is updated.
This could be a nice isolated chunk for a student to work on!
This is basically implemented. Grazing events have planned “duration” and “recovery” values.
There isn’t any concept of “rotation patterns” though… this might be something fun to explore. Could you describe what you’re imagining a bit more?
The Grazing Plan module can make use of the existing Movement quick form, which allows sub-geometries to be drawn. So technically speaking these two items are “done” - but there are numerous ways we could improve the workflow, no doubt! The way that grazing events are added to a plan is quite clunky in this first release.
I’m excited to build a “configurable” Observation quick form, and I think it would be able to handle exactly this kind of thing! I’m envisioning a general-purpose Observation quick form, similar to the Inventory quick form, which users can create “instances” of through the UI with specific things filled in and pre-configured.
The great thing about “configurable” quick forms is that the configuration for them is stored as Drupal config entities, which means they can be exported as YML and shared between farmOS instances, or included with a module so that they are added when the module is installed. This means that the Grazing module (or another module), could include a pre-configured “Pasture Health Observation” quick form with standard fields like the ones you described.
Which is just to say… perhaps we can design this feature outside of the Grazing module… but then the Grazing module can make use of it at a higher level. I like thinking about system design in this way… how can we build components that are useful on their own, but combine together to make a cohesive and holistic system?
Yes! As I described in the release notes of the new Grazing Plan module…
I think the ideal approach would be to create a new module (eg: farm_holistic_grazing_plan), which depends on the farm_grazing_plan module, and extends it with UI, quick forms, and workflows that are specific to more prescriptive systems like the Savory Holistic Planned Grazing system.
I would love to think through what this would look like!
This feels like an obvious next step for the core Grazing Plan module UI! The Crop Plan module could make use of something similar! So I wonder if we could approach it in a general way, like we did with the timeline gantt visualization library (which is shared between both Grazing and Crop plan modules)…
vs 
