| [12:06:21] | * steve456[m] has quit (Remote host closed the connection) |
| [14:06:17] | * farmBOT has joined #farmos |
| [17:09:29] | <paul121[m]> | Okay, this idea comes up a lot in my head: "intrinsic location". I want to specify an asset's fixed location without needing to create movement logs. |
| [17:10:06] | <paul121[m]> | We have "intrinsic geometry" which lets you say an asset is hard-coded to be at a given location. I think "intrinsic location" could work similarly so I can hard-code an asset's location to always be that of another location asset. |
| [17:10:12] | <paul121[m]> | s/// |
| [17:11:17] | <paul121[m]> | This is similar/can almost be achieved with the location hierarchy (setting an asset's parent to that of another location asset).... but it requires that the child asset is a location as well. In this case, the child asset is not a location, but I know it will not be moving, so thus I want an "intrinsic location" |
| [17:18:00] | <mstenta[m]> | I suppose that could make sense - and might work off of the same is_fixed logic |
| [17:18:24] | <mstenta[m]> | Curious: what use-cases are you think about? |
| [17:18:45] | <mstenta[m]> | We added intrinsic geometry specifically for location assets |
| [17:19:09] | <mstenta[m]> | But it sounds like you want assets with is_location: False + is_fixed: True? |
| [17:19:59] | <paul121[m]> | (yes! is_fixed is important context here, thanks) |
| [17:20:45] | <paul121[m]> | Assigning the location of a Product asset is top of mind rn |
| [17:20:48] | <mstenta[m]> | Related: this reminds me we talked about making the computed location show the parent of location assets. |
| [17:21:31] | <mstenta[m]> | (Because right now the "Location" column of Land assets, for example, is always blank) |
| [17:21:35] | <mstenta[m]> | (It would be nice if it showed the parent) |
| [17:21:44] | <paul121[m]> | But I think this would also be useful for more perennial plant assets (like orchard/tree) where seeding/transplanting movement logs may not be available or necessary |
| [17:21:48] | <mstenta[m]> | So what you're describing might involve touching some of the same logic |
| [17:22:06] | <mstenta[m]> | Yea those two use-cases are good ones |
| [17:22:36] | <mstenta[m]> | I think adding intrinsic_location would be a non-breaking change, so it could happen in the 2.x branch |
| [17:23:02] | <mstenta[m]> | Maybe worth opening a d.o issue to start outlining everything that would need to happen + all considerations |
| [17:23:46] | <paul121[m]> | Interesting... I suppose you could use the `asset.parent` + `is_fixed` to represent "intrinsic location", perhaps? |
| [17:24:10] | <paul121[m]> | But that kinda makes things complex. Product assets might have valid reasons to have a product asset as a parent |
| [17:24:27] | <mstenta[m]> | right yea sorry i was thinking about them as separate things... |
| [17:25:51] | <mstenta[m]> | hmm |
| [17:26:18] | <mstenta[m]> | maybe we would want to migrate all location asset parents to the new intrinsic_location field and use that for hierarchy instead? |
| [17:26:23] | <mstenta[m]> | (that would be a breaking change) |
| [17:27:22] | <mstenta[m]> | then we could just say: "if is_fixed is true, the computed location == intrinsic_location (as well as intrinsic_geometry)" |
| [17:29:15] | <paul121[m]> | mstenta[m]: yeah was wondering the same |
| [17:29:55] | <mstenta[m]> | that would simplify some things |
| [17:29:55] | <mstenta[m]> | but it's a big change |
| [17:30:19] | <paul121[m]> | is is_fixed needed for this though? right now it basically allows you to add geometry as metadata to an asset, but only use it as the location if is_fixed = True |
| [17:30:41] | <paul121[m]> | I'm not sure we need "intrinsic location" to ever NOT be the asset's actual location? does that make sense? |
| [17:31:31] | <mstenta[m]> | intrinsic_geometry is only shown in the UI and used in logic if is_fixed is true. so i figured it would work the same as that. |
| [17:31:53] | <paul121[m]> | in other words, if intrinsic_location is set, it is the law |
| [17:32:13] | <mstenta[m]> | in other words, intrinsic_geometry basically doesn't exist when is_fixed id false |
| [17:32:34] | <mstenta[m]> | gotcha. that would mean intrinsic_geometry and intrinsic_location work differently, then... which would be confusing |
| [17:32:56] | <mstenta[m]> | is_fixed essentially means "not moveable" |
| [17:33:08] | <mstenta[m]> | so when is_fixed is false it means "this asset is movable" |
| [17:33:42] | <mstenta[m]> | so i would think we want intrinsic_location to be the location of the asset ONLY if it is fixed |
| [17:33:43] | <paul121[m]> | yeah that makes sense |
| [17:34:17] | <paul121[m]> | I guess I wonder why we added is_fixed ? instead of just letting the presence of intrinsic_geometry determine that? |
| [17:34:29] | <mstenta[m]> | otherwise: what would it mean if you had a movable asset with an intrinsic geometry? what would happen if you added movement logs? |
| [17:34:29] | <paul121[m]> | I imagine there was a reason! :D |
| [17:34:52] | <mstenta[m]> | that's a fair question! maybe it could have worked without is_fixed |
| [17:35:09] | <paul121[m]> | It's just more explicit it seems |
| [17:35:19] | <mstenta[m]> | yup |
| [17:35:29] | <mstenta[m]> | we can review everywhere is_fixed gets used... |
| [17:35:39] | <mstenta[m]> | and if that made sense then maybe we consider this for 3.x |
| [17:36:04] | <mstenta[m]> | (remove is_fixed and just key off of the presence of intrinsic_geometry and intrinsic_location) |
| [17:36:31] | <paul121[m]> | so then: what gets priority? `intrinsic_geometry` or `intrinsic_location`? both, similar to how a movement log w/ geometry & location works? |
| [17:36:52] | <mstenta[m]> | i would think if EITHER are set, then it means the asset is fixed |
| [17:36:57] | <mstenta[m]> | but the other could be blank |
| [17:37:13] | <paul121[m]> | and if both are set? |
| [17:37:18] | <mstenta[m]> | and then movement logs are ignored for that asset |
| [17:37:28] | <mstenta[m]> | if both are set, that's the asset's location + geometry |
| [17:37:37] | <mstenta[m]> | (same as it works now on movement logs) |
| [17:37:49] | <paul121[m]> | sorry yeah that's what I was trying to say :-) |
| [17:39:11] | <mstenta[m]> | > maybe we would want to migrate all location asset parents to the new `intrinsic_location` field and use that for hierarchy instead? |
| [17:39:11] | <mstenta[m]> | thinking... are there any risks with this? |
| [17:39:36] | <mstenta[m]> | ... cases where it might break a user's data if their asset's parents disappeared? |
| [17:44:34] | <paul121[m]> | Certainly could be breaking to existing conventions/integrations... but not sure how it would "break" |
| [17:45:13] | <paul121[m]> | * would "break" outside that context |
| [17:45:24] | <paul121[m]> | hmm |
| [17:58:47] | <mstenta[m]> | Yea seems like it would be pretty safe |