(My original response, copied from https://www.drupal.org/project/farm/issues/3210067#comment-14115490):
@mason.lanphear Sorry I just saw your comment now! I think Drupal.org didn’t show it at first because your user account was new or something. Apologies for the late reply.
I think it would make sense to move this to a more general topic in the forum. There might be some confusion about what this issue is about specifically. I’ll respond to a few things here, but I’d love to have a broader discussion in a forum topic if you’re still interested…
Its also redundant to have a location for a planting, which inherently has a geographic boundary and location.
A diversified vegetable operation will have hundreds of planting assets, many will start in seeded trays in a greenhouse and then be transplanted out to fields. Sometimes plantings will be transplanted more than once. So “location” of plantings is very much a real-world use-case, and one that we must accommodate in farmOS. It may be less relevant in operations that only direct seed their plantings, and in farmOS 2.x it is possible to have a Plant asset with an intrinsic geometry just as you describe. So there is no need to think about “Location” if you use it that way.
Most of the time you are applying an input (irrigation, fertilizer, chemicals) to a planting asset, not the land. Yes, its happening in the field and to the field, but why is that relevant to a farmer? Perhaps they’ll want to see what chemicals were applied historically to a field…
That’s exactly why.
but that can be recorded at the field ID level without any need for specifying if the log is a location or not.
In order to say that the input was applied to both a field and a planting, the log should reference both of them in the asset reference field. As I stated in the issue description:
When a log uses the Asset field, it means “this happened TO this asset”.
An input to a planting in a field is an input to both the planting and the field. Whether or not you decide to record both is up to you. Some growers may want to see these logs related to both the plant and the field. Some may not. farmOS doesn’t enforce that either way. Nor should it. If your particular use-case calls for that, then you can enforce that as part of your own conventions. If not, you don’t have to.
I see your challenge in trying to create a generalized data model but I think if you can simplify things and make the platform more intuitive for a larger audience, you’ll see more adoption.
I think it’s important to separate the data model from the user interface. Currently, the farmOS UI is pretty directly tied to the data model, because as a first step it has to be. It is a CRUD application for editing the lower-level general purpose records. This is an intentional upfront sacrifice we are making, with the hope that it will have greater long-term benefits as more higher-level UIs are built on top of the flexible data model.
Enforcing conventions and “making the platform more intuitive” should NOT be directly tied to these lower level CRUD UIs. Instead, these should be handled by quick forms, plans, field modules, third-party survey applications, API integrations etc. “Intuitive” user interfaces are inherently limited in what they can model and represent, and every ag data software I’ve seen has made the mistake of tying their data model directly to their user interface. We’re trying to do something different. And therefore we have a different set of challenges. But I think it is worth it.
I would suggest that you simplify things and have the farmer specify whether an asset is a location or not when creating the asset.
This is exactly how it works in farmOS 2.x. Go to Records > Assets > Plants, click “Create Plant asset”, then click the “Is location” and “Is fixed” toggles at the bottom. This will cause an “Intrinsic geometry” field to appear, which will allow you to define the fixed geometry of the plant asset.
You don’t need to use the “movement” location features if you don’t want to.
I agree that the standard asset/log edit form UI is not “intuitive” - because “intuitive” means “tailored for a specific use case”. The /asset/add/plant form is not the place to be tailoring for specific use-cases. That should be done in higher-level UIs - and the hope is that more organizations in the community will step forward to build and maintain these. The asset and log edit forms themselves are essentially low-level database editing forms - which are a necessary layer, and the responsibility of farmOS “core” to provide.
Specifying if its a location asset for each log is very laborious.
I agree using the log forms directly in general is laborious. This should be solved at a higher level.
As it relates to this issue specifically (the asset and location reference fields on logs – which to be clear are different than the is_location field on assets), my proposed solution was to automate it (see “Proposed resolution” above).
At the end of the day, you want your roadmap to driven by users…has a location feature been a frequent request?
Yes, from the very beginning of farmOS. To name a few specific use-cases:
- Diversified veggies that start in greenhouses and are transplanted to fields
- Nurseries that only grow/sell potted plants or flats/trays of starts
- Rotating animals through paddocks
- Recording when equipment moves from one farm/field to another
This ended up being a bit more long-winded than I hoped, but I hope it provides some more context for you, and helps to illustrate why we’ve taken the approach we have.