Problem/Motivation

Logs in farmOS 2.x have an asset field and a location field, which are both for referencing assets. This is a natural progression from the 1.x logs, which had an asset field (for referencing assets) and an area field (for referencing areas). (See #2363393: Make "Area" into a type of Farm Asset.)

The intended way to conceptualize these fields is:

  • When a log uses the Asset field, it means "this happened TO this asset".
  • When a log uses the Location field, it means "this happened IN this asset".

This distinction is important, and it makes intuitive sense for many use-cases. For example, if you are creating a Maintenance log, you can say that it was maintenance applied to a Tractor asset (referenced in the asset field), and it was performed in a Barn asset (referenced in the location field). The location field is also used when creating "movement" logs to specify where assets were moved to (assets referenced in the asset field are moved to locations referenced in the location field).

However, some cases are not intuitive - specifically when you want to represent an action that is being performed directly to location assets. For example: applying an input to a Land asset... the action is happening TO the field, but it is also happening IN the field. So should the Land asset be referenced in both? Or only one or the other?

Proposed resolution

One idea that came up was: whenever a Log references an asset in the asset field that is also a location asset (has is_location set to true), then automatically copy it to the location field when the log is saved. This would essentially make the assumption that the log is happening both TO and IN the location, so it should be referenced in both. But this means duplicated references on the log... which introduces other potential issues (the logic would need to detect changes to the asset field and remove the asset from location perhaps, or other things like that). Furthermore: is that a safe assumption to make in the first place? Or are there cases where you DON'T want a location asset referenced in both fields?

I think this is largely a "convention" question - and a question of "what does this mean" in varying contexts...

It's entirely possible that we don't make any decision and just leave things "as-is" (closing this as "won't fix"). Or we could add the logic described above to automatically copy the reference. This could also be done in the future, potentially, with some automated update logic to backfill old Logs in the same way.

In either case I wanted to open this issue to document the thoughts and invite others to chime in.

Comments

m.stenta created an issue. See original summary.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

Perhaps a good question to pose is: where is the location field actually used?

As stated above, it's used in the asset location logic for determining where assets are located.

Another place it may be used (and what prompted me to create this issue) is in #3188586: Add Views of logs that reference assets. In farmOS 1.x, when you are viewing an Area record, you will see lists of logs that reference that Area in the log's area reference field. In farmOS 2.x, should assets have two sets of lists? One that shows logs that reference it in their asset field, and one with logs that reference it in their location field? That seems to be the most sensible approach...

I'm concerned that this ambiguity will be a point of confusion - especially in these contexts where a log is referencing things like Land or Structure assets ("location" assets, in other words). But I'm not sure if there's a good way around that, other than in documentation.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

Another place where location is used currently: when a log is saved, if it references assets in the location field, and if the log does not have a geometry stored on it, geometries from those locations will be copied to the log.

So the idea described above would be somewhat similar to that behavior:

whenever a Log references an asset in the asset field that is also a location asset (has is_location set to true), then automatically copy it to the location field when the log is saved.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

I think this is the key question we need to think about:

Furthermore: is that a safe assumption to make in the first place? Or are there cases where you DON'T want a location asset referenced in both fields?

If so, then we shouldn't add logic for automatically copying assets to the location field.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Related issues: +#3188586: Add Views of logs that reference assets, +#2363393: Make "Area" into a type of Farm Asset
mwrlanphear’s picture

mwrlanphear CreditAttribution: mwrlanphear commented

Hi Mike: I wanted to comment that the location feature in the context of growers is quite confusing. Its also redundant to have a location for a planting, which inherently has a geographic boundary and location. I think an important consideration for farmOS core is whether or not you want to force that on the user when most of the time it will be a point of confusion. Julie at Roy Farms already mixed up location vs asset when creating activity logs (luckily we were able to pair it down to just the essential information in the activity plans).

I also think you may be overthinking this use case:
However, some cases are not intuitive - specifically when you want to represent an action that is being performed directly to location assets. For example: applying an input to a Land asset... the action is happening TO the field, but it is also happening IN the field. So should the Land asset be referenced in both? Or only one or the other?

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 but that can be recorded at the field ID level without any need for specifying if the log is a location or not. Agrian simply uses fields and plantings for their data model and they are the de facto spray record platform in the US...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.

Either way, the location feature will definitely be a redundancy and point of confusion for growers. I would suggest that you simplify things and have the farmer specify whether an asset is a location or not when creating the asset. Specifying if its a location asset for each log is very laborious. At the end of the day, you want your roadmap to driven by users...has a location feature been a frequent request?

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

Edit: I moved my reply to the forum: https://farmos.discourse.group/t/locations-features-redundant-confusing/...

---

All of these thoughts are WAY more general than the very specific topic of this issue - and ultimately it's a very low-level nuts and bolts question about the log data model, with a bit of complexity due to the fact that "areas" are now "assets" in farmOS 2.x. It is partly a question of "convention" and ultimately will/should not be of concern to the end-user ideally... but we're not quite there yet.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

(@mwrlanphear If you do decide to open a forum topic we can copy the last two comments from here and edit/delete/link them to the forum to reduce the length of this thread for future readers...)

Edit: Scratch that: I copied this over to the forum.. :-)

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Issue tags: +beta blocker
m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

One other consideration that came to mind with this: we have logic to automatically copy the geometry of referenced locations to the log when it is saved, but the same is not true of referenced assets.

So, if we DON'T sync the assets+locations fields as described above, and a log happens TO a location asset (referenced in the Asset field), but does not reference it in the Location field, then the asset's geometry will not be copied to the log.

So, we may want to consider either/or:

1. Copy location assets from asset field to location field (as described above), OR:
2. If location assets are referenced in the asset field, and no geometry is provided, copy geometry from them (but only from location assets, not all assets).

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

This "copying geometry" question might warrant it's own issue, but another thought there: there has been discussion around making this less "automatic" and more intentional - by adding a checkbox in the UI that says "Copy geometry from referenced location assets" (or something). Or... just automatically updating the map to display geometry of referenced assets as you reference them, so you can see it happening BEFORE you save. Something like this might be a better approach, perhaps.

However, that would NOT necessarily cover cases where logs are pushed via the API (or other programmatic means), unless we still had some default logic in place to do so in the absence of an intentional choice.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta at Farmier commented
Status: Active » Closed (works as designed)
Related issues: +#3216843: Views of logs that reference location assets, +#3253116: Copy geometry from locations in asset reference field

Discussed this with @jgaehring and @paul121 on the dev call today. Talking it through helped to highlight that this is the primary issue:

if a log happens TO a location asset (referenced in the Asset field), but does not reference it in the Location field, then the asset's geometry will not be copied to the log.

I opened a separate issue with a proposed solution here: #3253116: Copy geometry from locations in asset reference field

The other issue discussed no longer applies (fixed by #3216843: Views of logs that reference location assets):

when you are viewing an Area record, you will see lists of logs that reference that Area in the log's area reference field.

The remaining question of whether or not you *should* reference an asset in *both* the asset and location reference fields is more of a convention question, and farmOS core doesn't need to make a decision on that. We can punt that out to "convention land" and let downstream implementations (eg: quick forms) make that decision on a case-by-case basis.

With all that in mind I think we can close this.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta at Farmier commented

FWIW I documented some of these thoughts in the data model docs: https://github.com/farmOS/farmOS/commit/af2393bfc51da42f01e619915603e974...