Hello all, new to FarmOS and looking to figure out how to keep all of our research plot’s data in one place as much as possible, considering the fact that every seasonal rotation, the design of our plot changes (except for location of till/no till areas and where compost is/not applied). We will put anywhere from 1-3 rows of a crop in each bed, and the higher-ups would like each row to be viewed as a single data point. We tend to only put one crop in each row which helps simplify the potential polygons, but once in a previous rotation we’ve put equal amounts of 3 crops in a single row as well, though to avoid mapping headaches I’d like to at least avoid that part in the future. How can this be accomplished without a bunch of overlapping polygons in our field for each new shape the field takes every season? Below is our current rotation’s design map (left) and and how it looks in farmOS (right).
Welcome @chicostateRADlab! Looks like a neat project.
The tricky thing here are the rows. If you would like to track which plantings are in the same row season after season, then you will need to create areas for each row. Like you say though, the challenging thing about rows is that they can change - one season might have 1 row in a bed, and the next may have 3. This makes it challenging to reference the same row year after year… hence why we have beds 
So instead of creating areas for each row, I think I might recommend creating areas for each of your beds. This will result in 16 areas. Then when you create your Planting Assets, you can create movement logs that specify their precise location with an additional geometry you draw. You can draw this geometry to reflect the “row” space it is in (1/2, 1/3 width x 1, 1/2, 1/3 length of the bed). If you create a single Planting Asset for every row, then you can still track each planting per row as a “single data point” (when it comes time to harvest, etc.)
Although taking into consideration the North/South aspect of the study, I’m curious if you might want to track each rows’ North and South planting separately? So each bed would have 4 plantings, 2 per row?
If you really need to track plantings in the same row over time perhaps you could create your bed areas with geometries (so they appear on the map) and then create “child” row areas without geometries. This would simplify the visual aspect of things, but allow you to still keep track of the rows. If a planting is in a single row the width of the bed, you could specify that it is located in rows 1, 2 and 3 of that bed. Conceptually we understand what is happening, but it doesn’t necessarily need to be visualized. This way you can sort of abstract out the geometries, while maintaining references to common “row areas” over time.
I hope that makes sense… I’ll attach some photos that might help. These are showing individual Planting locations created from a movement log. I recommend using the Snapping Grid (documentation) and Movement logs (documentation) for creating these records. This was my first time really giving the snapping grid a go, it’s really quite useful!
Perhaps someone else will have other recommendations! The challenge with collecting such granular data is that it quickly becomes more and more complex. I think farmOS can keep these records at any granularity, it just depends how much you want to input!
This is great, thanks! I wasn’t aware of the movement log tool yet, I’ll try this out. No matter what rotation we’re on, we won’t have more that 3 rows per bed, so this rotation with 2 rows for planting, for example, I could say the planting is located in rows 1 and 3 or something like that.
Everything will be planted within a couple days of each other, but yes the north and south ends will have a different compost/no compost factor on top of the till/no till factor in each whole bed, so I’d need 4 planting areas for 2 rows.
but yes the north and south ends will have a different compost/no compost factor on top of the till/no till factor in each whole bed, so I’d need 4 planting areas for 2 rows.
Ah yes, you’ll probably want to create 4 areas for 2 rows then (I had suggested just the 4 planting assets). Making your areas 75ft long I suppose? An activity log (tilling) and input log (compost) can only reference the areas, not the Planting assets. 
Hi @chicostateRADlab - welcome! @paul121 covered most of what I was going to say!
I will add: in the future we plan to add the ability to “archive” areas (similar to how you can “archive” assets). This will make it a lot easier to deal with changing area geometries over time. You’ll be able to create an area, even if it is only for a season, associate records with it, then archive it at the end, and all those records will still be associated for historical purposes.
Currently, it’s best to think of “Areas” as “permanent areas”, and use the movement geometry on the logs themselves (eg: on your seeding/transplanting logs) to define more specific geometries for that particular action. farmOS figures out the geometry of a planting (and all other asset types) based on its most recent movement log, not from the area record itself. This allows for “temporary” geometries (they don’t appear under your “Areas” list, but they are stored on the log itself).
This approach is also used for livestock operations that move animals around with temporary/movable fencing within a larger paddock/area. It wouldn’t make sense to add permanent areas for each new fence location (they may never be the same), so instead you draw the more specific geometry in the movement logs themselves. The same can be done with plantings. For example, you could say “this planting is in Bed 1” but also draw a geometry in the log that is only a small portion of Bed 1 (because perhaps you are also planting other things elsewhere in Bed 1).
The cool thing about all of this, behind the scenes, is: we will be able to take a GPS coordinate and say “tell me everything”, and we can perform a simple query to find all areas AND all logs that have an intersecting geometry.
Like @paul121 said, it’s up to you how granular you want to get with it - it’s just more data entry needed. Our goal with farmOS is to be able to accommodate the granularity, and over time make it easier and easier to record/manage at those levels.
Hope that helps! Thanks for posting to the forum!