Interest in a new Farm asset type?

Using farmOS
1

Would it be useful for farmOS core to provide an optional “Farm” asset type?

In general, a single farmOS instance represents a single farm. We’ve had a lot of discussions around supporting “multiple farms” in a single instance, but most of those have been focused on creating access control logic to support multiple separate farms within a single instance and restricting access to users based on the farm they are associated with. Setting the access restriction question aside for a moment, I’m curious if it would be useful to offer a “Farm” asset type for other reasons.

We’ve heard from some users who manage multiple properties that they think about their operations in terms of “farms, fields, and people”, where each “farm” is in a separate (sometimes distance) geographic location, and within that they have individual “fields”, and sometimes the “people” are assigned to specific farms.

If we added a “Farm” asset type, it could appear in the Locations hierarchy alongside other location assets like “Land”, “Structure” and “Water”. You would be able to organize fields (Land assets) under farms (Farm assets) to create a hierarchy that matches your mental model.

Historically, this has been accomplished in farmOS already using the “Land type” field on “Land” assets. One of the available land types is “Property”, so it’s already possible to create this kind of hierarchical model using existing asset types. But one key limitation of using “Land” assets to represent “Farms” is that you cannot add Farm-specific attributes/relationships without them being added to ALL Land assets. It isn’t possible to add special attributes to just “Property” Land assets. Attributes are shared across all Land assets.

This gets to another broader discussion we’ve been having about the need for more “Farm-level data storage” options. A “Farm” asset type could have new fields on it for standard things like “Mailing address” and “Telephone number”, which don’t have a place in farmOS currently (and don’t make sense on Land assets). Custom modules could add their own fields too, for whatever purposes they have. There has been talk about wanting to store things like “the list of certifications my farm has”, or “the locations where our products are sold”, for example.

And, getting back to the “access restrictions between farms” idea… this still leaves the door open for that. It could be possible to make some generalized access logic that restricts user access to “specific assets and their children”. So if a user is granted access to a “Farm” asset, and that has 3 “Land” assets in it, then the user has access to those as well. It’s still a large development effort, and separate instances are already an easy option that achieves the same thing, but this could be a step towards it regardless.

Thoughts? Strong opinions for/against? I’m curious what the wider community thinks, and how they might use a “Farm” asset type.

1 Like
2

For the sake of discussion (and to highlight how easy it is to create asset types :smile:) I drafted a pull request that adds a “Farm” asset type: Add a Farm asset type by mstenta · Pull Request #784 · farmOS/farmOS · GitHub

1 Like
3

Hi Mike,

I have seen several use cases where having a ‘farm’ asset would be helpful. I have seen large operations that have multiple farms that they manage and I have talked to gardeners/agronomists that tend to multiple locations/farms. In both scenarios it seems that they want to be able to focus in on one location/farm at a time when capturing operations or pulling out information for reporting without having to log out and log into a separate instance.

3 Likes
4

I think this could be useful information for an Organic operation. The organic module could add fields to show the operation’s organic certifications. Ideally this would get pulled in through the USDA Organic Integrity Database API directly. https://organic.ams.usda.gov/integrity/Developer/APIHelp.aspx

2 Likes
5

Hi Mike,

Given the proposal we have submitted, I can second @AmberS in terms of having an agronomist with multiple farms. However, he’s our agronomist and we are only one of his clients. We (Rothamsted) don’t have this particular issue, but I can see it being a useful feature to people outside our organisation.

That said, we do manage 3 different farms. Some of those farms already have multiple Properties associated with them (usually where we have bought or loaned land on a second farm a short distance away from our own property).

Currently we manage 3 instances with very little issue (each farm has it’s ow farm manager, and anyone who needs to has login details for all three). I’d say this has actually been helpful because things like the taxonomies (products, crops, varieties) and equipment (tractors, etc) are specific to individual farms and this helps us keep those assets and taxonomies separate. The person in Devon for example doesn’t want to have to flick through all the crop, pesticide and equipment assets in Suffolk (many miles away) when filling in a quick form (even if there is some overlap perhaps in products, crops and varieties). Each farm would ideally also have its own inventory to manage, and this I think becomes especially important for pesticides (legal compliance) and crops (you only want to calculate your tonnage for sale, not everybody else’s). In short, having a separate instance for the farm management side of the system works for us.

However that said we really struggle to manage the scientists over three sites. We ask for experiment proposals via FarmOS which are managed at an institute level even though the experiments associated with the proposals are managed at farm level. Also the scientists aren’t massive fans of having three logins and having to go look for their experiments.

It can also be difficult to standardise across instances, which is important to us. For example we need to make sure everyone is calling it Winter wheat not Winter Wheat.

From our perspective it would be great to be able to view all the farms in a single location but the farm gives you permission to view their data in the collated instance. Equally we’d want to offer standardisation from the top down. For example the top most level offers you quick forms, but you can decide which non-compulsory data fields you want to remove from a specific farm or how the questions are ordered. Similarly we offer you a high level taxonomy that you can select terms from and import into your own instance, but as the farm manager you are still only managing your own instance.

These are just my initial thoughts. It might be that some things like the quick forms are completely separate modules. Similarly, how much you want to enforce from the top down will depend on who you are and how the farms are related. If I own all three farms I might want to impose standards across them, but coming back to @AmberS comment above if I am an agronomist who is a consultant to multiple farms then I might want to offer standardisation (in the UK for example our agronomists might want to offer standardised formats for nutrient applications that follow the UK RB209 guidelines) but I can’t enforce standardisation.

Sorry if that is complicated. Just some of the specific issues I have seen from our use case.

1 Like
6

I like the idea of a “Farm” asset type. For me I manage my own farm but I also want to track my hay which comes from another local farm. The only interaction I have with them is buying hay off the fields, but because I buy most of their hay I like to track yield and cuttings for each field. This “Farm” asset would give a clear split in my database of what actually is in my control and what is not. This is especially useful at audit time to be clear what is my fields and what is not.

2 Likes
7

Great ideas all around - thanks for the input @AmberS @graffte @aislinnpearson @BOTLFarm! Very good use-cases!

We gave some thought to merging the Farm asset type pull request into 3.1.0, but ultimately decided to wait and give it some more time for the ideas to brew. @paul121 made the good point that simply adding the asset type without also providing some UI support to guide users and help them understand what its for could cause confusion. Perhaps starting with some base fields (like “Address”, “Telephone”, etc) would help with that, at the very least.

1 Like
8

Yes, although the main concern I have with Farm assets regards how they fit within the log logic of our data model. What does it mean for a Farm asset to have an inventory, be grouped or have location moved with movement logs? And more generally, what does it mean for logs to reference a Farm asset? You could certainly make an argument for how each of these use-cases could work with a Farm asset but IMO it feels “hacky” and like there should be a better solution. Implementing it as an asset type is the easiest option, but I’m not convinced it is the best option.

I am very much in favor of having some concept of a Farm in farmOS for many of the reasons described above. But in other farm management systems the concept of a “farm” is different than a “field”. It is a “first-class citizen” for good reason. Implementing it separately from assets would force us to consider it as such, require that we build a separate UI and give us more flexibility to implement Farm-level features without worrying how they interact with assets.

4 Likes
9

Great points @paul121!

I commented on another topic, but it feels related to this “first class citizen” idea, so I want to cross-reference it here too:

Specifically:

I think a good question to ask is also: what features of assets DO we want on the new entity type? In many cases, we may find that a lot of the asset entity features are in fact desirable. So it’s worth doing a comparative analysis along those lines too…

10

Just to play devil’s advocate a bit (and maybe we really need a dedicated topic to brainstorm “When to create an asset type vs a new first-class entity?” because it’s a bit beyond the scope of this thread and the Document one)…

The same question can be asked of Land/Structure/Water assets. A “Farm” asset type is really just another type of “Location” asset in many ways, so all the same considerations apply.

In the upgrade from v1 to v2 (when “Areas” because “Land/Structure/Water” assets) we had to deal with some of the oddities of “Asset location” with regard to “fixed” assets like land and structures (while also allowing for “movable structures”!). In that process we added concepts for “Is fixed” and “Intrinsic geometry” to allow them to be treated differently.

I don’t see anything wrong with this. It means the same thing as a log referencing any other asset. It applies to that asset as a whole.

Examples:

  • A “Purchase” log that shows when you purchased the farm.
  • “Activity” logs to record when legal processes happen like lease renewals or organic certifications.
  • “Input” or “Observation” logs to record rainfall on the property as a whole.

It is 100% reasonable to consider making a new entity type.

It’s worth thinking about all of the features that assets already provide out-of-the-box first. Because I bet a majority of them will be desirable. And would need to be replicated somehow if it’s not an asset… which means more development and maintenance.

There is an elegance to “assets” and “logs” that simplifies those two considerations greatly (no extra dev or maintenance). That shouldn’t be an excuse to fit a round peg into a square hole, of course… due diligence (like this conversation!) will tell us what shape they really are. :slight_smile:

2 Likes
11

Talked with @paul121 about some of these ideas again today. We thought through some of the costs/benefits of the “asset type vs new entity type” question.

One idea that came out of the conversations was the idea of adding a new “Organization” entity type, which could have sub-types including “Farm”. So the API route would look like /api/organization/farm (rather than an asset type at /api/asset/farm).

What do others think about this? It might deserve it’s own forum topic, as an alternative to the solution proposed in this thread. I will also propose it as a topic for the monthly call on Wednesday, for anyone who is able to join.

3 Likes
12

I’ve started a new forum topic dedicated to the new idea of an “Organization” entity type, with a “Farm” sub-type. Let’s continue discussion over there (assuming everyone agrees that makes sense).

1 Like