Orchard in FarmOS

Hey folks, I’m a newbie. I did a quick search for my question but couldn’t find an answer. If this has already been discussed, just send me a link to the thread (and apologies for the redundancy). I’m in the process of setting up FarmOS for our orchard. We have multiple blocks (fields) in our orchard of various fruit trees. Some of our blocks have different varieties of the same fruit. Most of these varieties are organized along rows, but some rows have mixed species due to pollination requirements. Finally, in between the tree rows we manage our alley. Some alleys have different perennial mixes. We manage these alleys at different times based on pollinator requirements and harvest periods. Bees are a constant presence (we manage 80 hives), and we rotate layer chickens through the orchard. That is the basic set up.

I have already set up each individual field as an area, but I need to start adding the row/alley details to these fields. What I can’t figure out is what I should do next. The Bed Generator doesn’t seem to get at what I’m trying to do. Should tree rows and alleys be individual drawn areas within the larger field? Should they be assets? (We planted 11,000 trees this spring so generating individual trees seems daunting. Yet, I know there will be times I will want to flag/mark certain trees or sections of rows.) I know I will create various logs throughout the season based on our nutrient and IPM protocols. This will include foliar sprays, mowings, beneficial insect releases, pest sprays, and irrigation/fertigation events. I’m afraid to proceed thinking that I may create the wrong category for the trees and alley plants and would love some advice in thinking this through before I continue. Thanks! Kyle


Hi @kyle - welcome to the farmOS community!

Someone asked about similar ideas in this topic - see my answer there for some general ideas and ways of thinking: How to easily map individual trees?

This might also be relevant: Hierarchical function - watering "fruit-trees" (group of trees) instead of each single tree

If you need to be able to record logs against individual trees, then you will probably need an asset per tree (a lot I know!). Otherwise, you might just want to have an asset per variety (further broken down by row perhaps). Ultimately the way to think about it is in terms of “management units” - so the granularity that you decide on is a balance between the need for granularity vs the data management burden.

What level will you be logging at, most often? The block level? The variety level? The row level? the individual tree level?

Welcome Kyle,
nice to have other orchardists using farmOS.
There is a feature to draw lines between points (the points can be GPS coordinates) that we have been using to record our rows. Not sure if there is a possibility to mark some trees in one row and then copy paste them to another row.
Additionally you can use the hierarchy of blocks for perennial mixes.


Thanks for the suggestions. I’m still trying to figure out what will be best for my application. Most of our records are on a per/block basis. I’m not normally needing data for specific pollinator trees in the fields. However, the need to define area between alley and row is still key. I’m still finding the need to define areas (rows) within blocks that have specific tree types for harvest logs. I’ve considered using the bed generator but including both row and alley as a way to manage this. It’s a bit messy, but may be what I end up doing. For now, I’m adding planting assets to the areas defined as fields. Once I get to alley management, I’ll have to make a decision. @Lars, the line draw for rows is still intriguing. I like with a line draw that I can draw only half of a row if my variety only takes up half of the row. It seems odd to add inputs to a line, but I’m guessing it isn’t a problem as long as I’m not basing my inputs off of an area defined by FarmOS.


@mstenta @Lars Here is one way I used the line draw function. Maybe it will be useful for others to see. I have two varieties of peaches in one of my fruit blocks. I manage the block as a singular unit when it comes to inputs and my integrated pest management. However, I do want to have a place where I can isolate key information for each variety. In this example, I want to isolate harvest data (they are picked at different times), so that I can associate yield and other downstream information with each variety. So, I ended up drawing lines at 15 feet apart. I can now attach harvest logs to the lines (variety), but I also grouped the lines within the larger block so that I can associate inputs with both varieties when need be. Feel free to leave any further suggestions.


@kyle Cool! Thanks for sharing!

I want to isolate harvest data (they are picked at different times), so that I can associate yield and other downstream information with each variety.

Are you saving this set of line geometries as a separate Area/Asset record from the Block (which I assume is an Area record)? Or are you just recording those lines in the actual Harvest logs?

Either approach could work, but having a separate area/asset to represent the variety (with those lines as it’s “current geometry”) would make it a lot easier to record future logs against that area/asset. Otherwise you would need to manually copy that set of lines into each new log, if I’m understanding correctly.

Yes, those lines are a separate area.

1 Like

Great! Out of curiosity what “Area type” are you using for them? The migration logic for farmOS 1.x → 2.x generally converts Areas into “Land” Assets (because Areas are converted to Assets in 2.x). It might be worth coordinating that migration so that they become a different type of asset, like “Plant” or maybe we add a new “Orchard” asset type? Something to consider in the near future… :slight_smile:

1 Like

I’m putting all area that are associated with either a fruit block or a group of rows as “Fields”. Will this go to land assets? Will the area function in 2.x be eliminated?

Kyle Holton
Honey Rock Landing

Email: kyle@honeyrocklanding.com
Phone: 501.701.8130
2444 Dominguez Canyon Rd
Delta, CO 81416

@kyle That should work fine! Yes, those will be migrated to Land assets.

Will the area function in 2.x be eliminated?

We basically are adding three new types of assets in 2.x: Land, Structure, and Water.

Land assets have a field on them for “Land type” with default options including: Field, Bed, Landmark, Paddock, Property, Other (more can be added via modules). Structure assets have a field on them for “Structure type” with default options including: Building, Greenhouse. And Water assets are just a simple asset type (without a “Water type” field on them - although we can consider adding that if there’s a need).

As you know, in 1.x we have a concept of “Areas” (separate from Assets), and each Area can have an “Area type” (including all the Land, Structure, and Water types listed above).

So, when upgrading from 1.x to 2.x, we basically map Areas in 1.x to Land, Structure, and Water assets, and fill in the Land/Structure type field on them. So your “Field Areas” will become “Land” assets with a “Land type” of “Field”, if that makes sense.

This unifies a lot of the shared functionality we had between Areas and Assets in 1.x, because Areas really are Assets if you think about it - and can be treated the same way. All the same functionality that existed in 1.x for Areas (including being able to arrange them in a hierarchy) is still possible in 2.x. And we get some new features for free - like the ability to “archive” them, which is helpful if you make major changes to your areas, but want to preserve the old records/relationships. You can just archive the old ones, and make new ones.

Here is the original (very old) feature request to make areas into assets, if you’re interested: Make "Area" into a type of Farm Asset [#2363393] | Drupal.org