I wonder if this could be modeled with the “configurable Observation quick form” idea I mentioned above…
I will start a separate forum topic to start brainstorming that feature, because I think it makes sense for it to happen in farmOS core. Then modules can leverage it and provide their own configurations.
Just to finish the thought I alluded to in my last comment… 
Imagine the following structure:
Each component is self-contained but builds on the lower-level pieces.
Here is the topic I started - would love to hear all the ideas!
I think this and the basic gantt chart (already implemented) are the minimum that a grazing module should have. So agreded this is a good place to start.
Maybe It should have said ‘automatic scheduling of rotations’. Similar to V1 where the paddock order was defined somehow, then the default durations and recovery periods work together to plan dates of all the following logs. Maybe your saying this is done already? I have not loaded the Alpha release.
I think this is a fine idea but the quick form should be able to adjust the overall grazing schedule. I feel like the in the field use should be entering info on the quick form not in the plan. IE I select the appropriate move on the quick form and moved animals out of paddock A and into paddock B a day earlier than planned, this needs to be reflected back on the plan.
Gotcha! This is not implemented. I think this would need to be implemented in a layer on top (eg: a Savory Holistic Planned Grazing module). The “automatic” durations and recovery periods in the v1 module were calculated using the Savory methods, and required additional information like animal type (using their fixed list), animal weights, dry matter intake requirements, paddock quality measurements, etc.
Agreed. I think general logic to for adjusting the grazing schedule when ANY log is added/edited in the plan would cover this, regardless of where that change comes from (quick form, manual log addition/editing, etc).
Another grazing season has ended in the northeast – sheep are in the barn happily munching hay and I am reflecting on my record keeping from the year.
Following up on this thread, there are a couple of outputs from the grazing data that I think are essential to support assessment of the previous season and planning for the next as well as in-season assessment and decision making. These are things that I think should be worked into the grazing module. BTW, I am curious if it is still the plan (or perhaps ongoing?) for this to be worked on by students this Fall?
Rest period: I think that the most basic and important thing to visualize is “how long has it been since an activity occurred in a given location?”. Perhaps a visualization somewhere of “last activity” and “days since last activity” would be useful and sufficient. I haven’t thought through yet where in the UX this should go. I just know that when I am trying to project out my next move, I want to know when a given field was last hayed or grazed. For me, haying re-entry windows are 35-40 days (for grass regrowth, depending on the season) and grazing are ideally 60 plus days (to break the parasite life cycles as much as possible). Ultimately, though, I think the most important piece of data we can provide users is simply a day counter since the last activity, allowing farmers to interpret that data in a way that makes sense for their operations.
Lbs Dry Matter (DM) per acre: This is a commonly used grazing figure that is getting at “how much food is out there, anyways?” It can be thought of as two separate calculations. The first is DM per group per day. Calculated as [(number of stockaverage weight of individual).04=DM per day]. For my sheep, I know that they eat about 4% of their bodyweight in dry matter each day. Perhaps that % variable can be set by the producer.
Taken farther, we know that the sheep are in a certain location/field/paddock with a given acreage for a certain number of days. So, we’d take field size divided by days that they are there to get acres per day and divide the DM per day by acres per day to get DM per acre.
All great points! Especially the days since last activity. This is a great quick metric I think a lot of people will use.
The students have gotten started on this. They are starting to lean towards implementing it using Asset Link, but it is too early to have a clear direction of where it is going at this point.
@BOTLFarm Awesome! If you would like any user feedback along the way, I am happy to help with that. Is there a MVP doc or similar somewhere out in the ether that I can take a look at?
When we get to testing I will loop you in.
This thread is the main document the students are using for the development. We are starting slow so the MVP is to link logs together so changing the done date on one log will adjust all logs downstream of it. Additional usability will come after that.
Ah, so that when a group or asset moves a day earlier or later than it was set to in the pending log, connected pending logs will adjust accordingly? Is there a record of the adjustment? I could see that record being a useful management tool as the farmer would be saying to themself, “something happened differently than I expected or planned here – why?”…
Excited to see this develop!
Exactly!
All logs currently store revisions in the revisions tab so at a base level yes there will be a record of it. Ideally we will want to create a better revision history for the entire plan. We don’t know what this will look like yet as everyone’s use case of how frequently they may want to see changes are different. Maybe a user can take a “snapshot” whenever they want to be able to refer back at a certian time period.
Great. Looking forward to seeing and contributing where I can.
Agreed this would be a great feature! I could see this being useful generally too, perhaps, outside of grazing plans. But starting with it in a grazing plan is probably the easiest first step.
The tricky thing is just defining what “last activity” means. In a grazing plan specifically it’s about figuring out when the animals LEFT the pasture. farmOS movement logs track when assets ENTER a location, but it is possible to figure out when they left too, as long as there’s another log that moved them somewhere else (or unset their location).
One other big potential complexity comes to mind…
It’s possible for animals to move multiple times within the same Land asset, but with different sub-geometries (eg: moving temporary fencing around within a larger paddock). So just calculating when they left the Land asset isn’t really enough in that case. We would need to be figuring it out at a geometry level. The only way I can think to reasonably visualize that would be on a map somehow. So it’s not just a simple text output of “X days since they grazed here” (because geometries could be completely arbitrary and non-repeating).
Alternatively, maybe we need to draw a line somewhere and say “this will only work if you are using permanent land assets, and not temporary sub-geometries”. But even that would require some thinking… 
@BOTLFarm mentioned on a recent call that the old v1 Grazing module provided this info. But notably, that module did NOT support sub-geometry rotations (if I remember correctly). Every paddock needed to be explicitly defined.
This actually feels very similar to this discussion: Medical Logs, withdrawal flags (which itself reminded me of @paul121’s “Restricted Entry Interval” module). Perhaps we should look at all of those cases again together and see if we can solve them all in a similar way in farmOS core.
Yea! The v1 Grazing module included a bunch of logic for calculating this! It would be good to revisit that and see what makes sense to bring over.
I think I would like to think about it in terms of components that can be stacked together to reach the desired estimation. For example, there is a farmOS Animal Weight module that is specifically for tracking weight in a standard way. We’ve also talked a bunch about a Configurable Observation Quick Form that could be used to make a standard “Pasture Condition Observation” quick form (eg: whenever you move your animals, you fill out this form for both the pasture they are leaving and the one they are going to, with measurements for things like grass height, etc). These two components could be independent of one another, and could be used standalone for other purposes, but together they can help feed data into the Grazing module for providing DMI calculations/suggestions.
Hi all - I have been following this thread for a while, but this is my first post. Thank you for all the work you have put into this project! I haven’t actually installed it yet, but tracking grazing is a big piece of why I am interested.
I apologize, my first post is going to be a long one.
This is an important issue, and one that we have faced with our paper-based (actually phone-based, but might as well be paper) system. I used to literally draw the outlines of each move on a paper map throughout the grazing season. This was super cumbersome, and in the end, of limited value. I tried making a map that included “all possible” paddocks and numbering them, then we would record the paddock number or numbers each move. This was better in terms of ease of recording, but generally inaccurate because you eventually got to a place where you set a fence half way between one paddock and the next.
At this point I don’t worry too much about the map. When I go into a field I determine how many paddocks I am going to make, and their general dimensions. Then I record a move like “heifer herd into paddock 4/6” (“paddock 4 of 6”). And somewhere I record what size (number of paces) each paddock is. For each field I have a note along the lines of “far field: 240 (1/4: 50; 2/4: 65; 3/4: 65; 4/4: 60)”. This tells me that the field is 240 paces long and if I am going to split it into 4 paddocks (of roughly equal acreage), the first should be 50 paces wide, the second 65, etc. This example assumes the paddocks are full width, but can be adjusted for different splits.
There are several advantages of this for me. First, it is easy to record a move. Second, I do not have to remeasure the field to set paddocks. Third, it is easy to adjust to 3 or 5 paddocks, just play with the numbers. Fourth, it is easy to communicate to someone where the fence should be. We “calibrate” our paces, so while I would make it 50 paces wide, someone else might use 55 paces.
I raise all this because I wonder if it would not be possible to do something similar in FarmOS. Rather than focusing on sub-geometries, which are tricky to enter, focus on the number of paddocks one wants to subdivide the asset into. Perhaps you could get to a place where there was a geometry associated with that subdivision, but as a first stab, just letting the person say they want to split the land asset into 6 “chunks”, and then provide a little detail about the “chunk” (number of paces, observations, square footage/acreage, whatever) would be great. I don’t know enough about FarmOS to know how you would need to set things up so you could move a group of animals to a “chunk”, but if you could, then you could answer some useful questions:
The questions you can answer today: when did my animals last enter this field, and when did they last leave?
The questions with some kind of “chunk” idea: when did my animals enter/leave chunk 4/6 of this field?
The question of rest periods is important. We have a field with 12 2-day paddocks. Our typical rest period is about 30 days. So they leave that field for about 6 days. If you can only determine rest at the field level, it will not really communicate what is going on. But the paddock layout changes from year to year as well as rotation to rotation. And within a rotation if we reconfigure the management groups. Drawing it on a map would be lovely, but is quite time consuming. Being able to say how many paddocks of roughly what size you are using, and when you move in/out, would be sufficient, at least for my purposes.
There are probably a bunch of assumptions in this. One is that you move through the field in roughly the same pattern in a given year. My paddocks are roughly the same for the first 3 rotations (May, June, July), but then they start to grow (August, September, October) and the rest durations begin to grow. I usually end up with about 5 rotations through any decent pasture in a ~6 month season. Some fields get hayed, others need longer rests, so those get fewer passes through. If you dramatically reconfigured your paddocks from one rotation to the next, the idea of “when did we last graze 4/6?” becomes less useful, because maybe what was 4/6 is now 1/3. For me paddocks only grow, and I always go the same direction, so if it was 4/6, now it likely part of 2/3. I know that, and knowing when they left 4/6 is useful to me.
Hopefully that is useful. I look forward to playing with FarmOS when I have some time!
Welcome to the forum @kinnebrook! Thanks for sharing all these ideas! It’s very helpful to just hear the different approaches and strategies people use currently.
Good to know. I imagine the value of that level of geometric accuracy will vary from farm to farm. It would be good to support it, but not require it IMO.
The easiest way to represent this approach is probably to create child land assets for each “chunk”. These could be “semi-permanent”, in that they are added as actual assets, but those assets could be archived at the end of the season and new ones could be created next season. Then, you can decide if you want to draw geometries of those assets (geometry of land assets is optional), or take some other approach (like putting “far field: 240 (1/4: 50; 2/4: 65; 3/4: 65; 4/4: 60)” description in the asset name or notes). It would still require creating those assets in advance, though, so maybe more work than what you’re doing now. It also doesn’t solve the “set a fence half way between one paddock and the next” scenario.
The alternative is to just put the “far field: …” description in the movement log notes, and just reference a larger “permanent” land asset on every movement. It’s OK to say “Move herd to Field A” and then “Move herd to Field A” again (and again and again)… and then just put more specifics in the notes. That would probably be closest to what you’re currently doing, in terms of flexibility and ease of data entry, at the expense of granular geometry records.
Yep this is the crux. In order to “compute” this we need more granular records. Not necessarily geometry… but we at least need an entity for each “chunk”. The way to do that right now is to have a land asset for each chunk. But again, the tradeoff I described above applies.
The way to achieve ultimate granularity for rest periods is to base all the calculations on geometry, with assets just being a handy reference.
What I was imagining was a map that shows polygons of varying colors, representing the state of the grass. A red polygon might mean that it was just recently grazed and shouldn’t be grazed again. But that could gradually fade back to green, indicating that it’s ready again. I think that would be awesome! Of course, that level of accuracy requires the most granular records (with accurate geometry)… not to mention pasture recovery logic and the data needed to support that (how well is the grass growing? what is it’s current height? what is the projected weather? etc etc).
But to your first point… there is diminishing value.
Nevertheless, ideally our data model would support the full spectrum, and if someone really wants that level of granularity then there shouldn’t be any barrier to them writing their own UI/UX modules to support it.
I should add: it wouldn’t be too hard to add additional “chunk” land assets on-the-fly throughout the season too. So this could still work fine.