| [20:20:20] | <jgaehring[m]> | <gbathree[m]> "Cool, I recently talked to..." <- oh man, we just mentioned Farmobile on today's monthly call! you'll flip when you hear how that came up... someone from the Free Software Conservancy joined the call to talk about how to keep John Deere honest in how they make the data and software on their newer tractors available to farmers... when he asked about examples of larger farmers collecting data via onboard systems, I mentioned |
| [20:20:20] | <jgaehring[m]> | Knuth Farms and pointed him to the In-Depth Angela did a year or so ago, where she goes into some detail about how she uses Farmobile together with farmOS and CropZilla... the Vice article I posted above is also related to that general discussion. |
| [02:11:37] | * jonasbits has quit (Quit: No Ping reply in 180 seconds.) |
| [02:12:46] | * jonasbits has joined #farmos |
| [02:19:38] | * jonasbits has quit (Quit: No Ping reply in 180 seconds.) |
| [02:20:56] | * jonasbits has joined #farmos |
| [09:29:16] | <gbathree[m]> | omg! |
| [09:29:23] | <gbathree[m]> | dude we could build around that |
| [09:29:32] | <gbathree[m]> | they are seriously interested based on this conversation |
| [09:30:38] | <gbathree[m]> | so context: general mills projects (Kansas and in Canada) which are the ones that are going to be int he coffee shop, were also testing using farmobile while collecting data in surveystack. The farmobile team was actually collecting the survyestack data on GM's request (they were basically managing the data collection end), and so we connected because they wanted to figure out how to more efficiently do the GM work together |
| [09:31:51] | <gbathree[m]> | when I talked to them about the conventions we're starting to build, and how we store data, they seemed very very keen (and very very much recognized the need) to create some thoughtful standards. From their perspective, they want to make sure their electronic field records (kind of a raw tractor data + estimated actual field operation based on the implements + information from the tractor) end up in a structure that anyone can use (ie... |
| [09:31:51] | <gbathree[m]> | ag data wallet ie... convention ie... switchboard) |
| [09:37:08] | <gbathree[m]> | and they were like 'how can we better integration with surveystack'... and I was like 'well, actually in this case you should just build a farmOS integration... because if a farmer is generating EFRs, they should get pushed/synced (whatever) to their farmOS instance directly and then any missing information could... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3102655ada...) |
| [09:37:37] | <mstenta[m]> | Angela would be very interested in this I'm sure |
| [09:38:05] | <mstenta[m]> | She's also keen on "spraying plans" for pre-planning spray activities ahead of time |
| [09:38:09] | <gbathree[m]> | I'm curious, she's obviously already using both... maybe I'm way off in my idea or maybe we're already close. Having an active farm using both services is a great connection point to initiate some work |
| [11:37:06] | <FarmerEd[m]> | I presume this is all for collecting data from modern Tractors through ISOBUS? |
| [11:37:06] | <FarmerEd[m]> | Any thoughts on older stuff? I've been considering a few projects to integrate farmOS with older pre computer age tractors using microcontrollers and possibly old tablet or touch screen laptop. |
| [11:37:35] | <mstenta[m]> | Indeed - FarmMobile plugs into the ISOBUS |
| [11:38:02] | <mstenta[m]> | Similar to this other one I described, which is open source: https://www.isoblue.org/ |
| [11:40:16] | <FarmerEd[m]> | No ISOBUS here so would need to build bespoke system, to integrate agopenGPS and FarmOS. |
| [12:00:18] | <mstenta[m]> | farmOS dev call happening right now |
| [13:02:20] | <symbioquine[m]> | paul121: 32.7 KB ... Seems a bit large! |
| [13:02:57] | <mstenta[m]> | Ok so maybe that's a good reason to package some things! |
| [13:08:48] | <symbioquine[m]> | If you don't take the intermediate step of turning it into a Polygon object it goes down to 5.8 KB |
| [13:09:41] | <symbioquine[m]> | Context: https://github.com/paul121/farm_farmlab/tree/1.x/js/farmos-map-extent |
| [13:16:50] | <symbioquine[m]> | <symbioquine[m]> "If you don't take the intermedia..." <- It goes up to 5.95 KB if you use the `ol/extent` functions to get the corner coordinates (untested code 😁);... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4b0ee413df...) |
| [15:08:44] | <paul121[m]> | > <@symbioquine:matrix.org> It goes up to 5.95 KB if you use the `ol/extent` functions to get the corner coordinates (untested code 😁);... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4b0a35faac...) |
| [15:09:29] | <paul121[m]> | I was using the Polygon method for convenience but yeah those look better :-) |
| [15:09:34] | <symbioquine[m]> | I think I spent 5 minutes on it :) |
| [15:09:56] | <symbioquine[m]> | Okay, maybe 8 |
| [15:11:00] | <paul121[m]> | Could probably just implement the topLeft bottomLeft logic without importing too |
| [15:11:38] | <symbioquine[m]> | In less than 160 bytes? |
| [15:12:21] | <symbioquine[m]> | If I'm doing my math right that's the difference between 5.79 KB and 5.95 KB |
| [15:12:53] | <paul121[m]> | ohh yeah. sorry misread, definitely |
| [15:14:23] | <symbioquine[m]> | I wasn't super clear when I wrote it above. 5.79 KB is the size when you just return the transformed extent. (which would be broken, but is a useful baseline) 5.95 KB is using the `ol/extent` fns to produce a rectangle's coordinates. |
| [15:14:54] | <paul121[m]> | if this would useful more generally happy to make a PR to farmOS-map :-) |
| [15:15:01] | <paul121[m]> | * this would be useful more |
| [15:15:59] | <paul121[m]> | it seems like getting the view's extent could be useful for other use-cases but perhaps too early to decide that |
| [15:16:28] | <paul121[m]> | also symbioquine the ability to turn a single feature's geometry into the SVG.... that seems quite worthy to be included as well |
| [15:16:45] | <symbioquine[m]> | Maybe... |
| [15:17:02] | <symbioquine[m]> | I was thinking about putting it in a separate NPM module, but I'm not opposed to that |
| [15:18:03] | <paul121[m]> | and maybe include that NPM module in farmOS-map? :-) |
| [15:18:32] | <paul121[m]> | having it in farmOS-map would make it the easiest to use, but maybe I'm being lazy |
| [15:24:05] | <mstenta[m]> | @room I'm working on the farmOS Maple module port to v2... curious to get thoughts on data model for it... |
| [15:24:20] | <mstenta[m]> | https://www.drupal.org/project/farm_maple/issues/2851950 |
| [15:25:01] | <mstenta[m]> | In v1, the module added a dedicated `sugar_bush` asset type (to represent stands of maple trees) and a `tap` log type (to represent when trees were tapped) |
| [15:25:27] | <mstenta[m]> | I'm leaning towards migrating these to ordinary `plant` assets and `activity` logs in v2. |
| [15:26:05] | <mstenta[m]> | Also thought about migrating them to `land` assets with a new `land_type` of `maple`... but I dunno. |
| [15:26:12] | <mstenta[m]> | What do you think? |
| [15:27:40] | <mstenta[m]> | Feels weird to add additional asset/log types for this (`farm_maple` was one of the earliest contrib modules I made for farmOS v1, so it was still pretty experimental)... hence why I'm rethinking it for v2 |
| [15:29:12] | <mstenta[m]> | The `sugar_bush` asset type didn't have any special fields on it, so doesn't really need to be a dedicated asset type IMO. The only real benefit is conceptual separation from other assets. But filtering by Crop/variety on Plant assets achieves the same thing. |
| [15:29:33] | <mstenta[m]> | The `tap` log type added `tap_count` and `tap_size` fields - but those can just be quantities in v2 IMO. |
| [15:29:57] | <mstenta[m]> | I'm thinking about whipping up a simple Maple Tapping quick form to make it easier to record tapping events consistently. |
| [15:32:49] | <mstenta[m]> | I'm still on the fence about the asset type though... should it add a new `maple` asset type? Otherwise you wouldn't really know where to start if you're installing the module fresh... |
| [15:34:29] | <mstenta[m]> | (Just typing this out is making me think a dedicated asset type DOES make sense...) |
| [15:34:55] | <mstenta[m]> | One that `is_fixed` and `is_location` by default (like `land` assets) |
| [15:43:43] | <paul121[m]> | <mstenta[m]> "(Just typing this out is..." <- This sounds similar to what we have discussed about orchards - a long-lived plant asset or a land asset w/ plant assets for each year? |
| [15:44:24] | <paul121[m]> | Not familiar with maple/syrup production. Might depend how those are managed |
| [15:45:03] | <mstenta[m]> | Yea thought about `forest` assets too - but yea I think the management is just different |
| [15:45:17] | <paul121[m]> | <mstenta[m]> "(Just typing this out is..." <- would this new asset type have a crop/variety reference field (`plant_type` or other?)? |
| [15:45:18] | <mstenta[m]> | And a `maple` asset might be a subset of a `forest` |
| [15:45:39] | <mstenta[m]> | I wondered about that too (`plant_type` field) - maybe that would be useful! But might punt on that for MVP |
| [15:45:54] | <mstenta[m]> | Then you could say what type(s) of trees are in a particular grove |
| [15:46:20] | <paul121[m]> | That seems kinda important? Although I guess it wasn't a feature in v1? |
| [15:46:32] | <mstenta[m]> | Right - it wasn't |
| [15:46:38] | <paul121[m]> | Dang. makes it hard to migrate to plant assets. |
| [15:46:44] | <mstenta[m]> | But another rabbit hole I started going down was: what about birch sap? should this be the `farm_sap` module? haha |
| [15:47:04] | <mstenta[m]> | But the huge majority of users would be focused on maple, and it could still be used for birch |
| [15:47:10] | <mstenta[m]> | naming... |
| [15:47:15] | <mstenta[m]> | always hard |
| [15:47:24] | <paul121[m]> | ahh. then migrate all `sugar_bush` assets to `plant` assets of type `maple`... |
| [15:47:29] | <paul121[m]> | as a default |
| [15:47:44] | <mstenta[m]> | yea i actually implemented that in a wip commit |
| [15:47:54] | <mstenta[m]> | but then started doubting that |
| [15:49:56] | <mstenta[m]> | for one thing: you'll pretty much always want `is_fixed` and `intrinsic_geometry` - which means users will need to know to manually set that when they set up new plant assets |
| [15:50:05] | <mstenta[m]> | unless we also have a quick form for mapping maple trees |
| [15:50:56] | <mstenta[m]> | (same might be true of orchards, but maybe not all the time... maple groves are typically not "planted" - they are existing trees in a forest stand) |
| [15:51:25] | <mstenta[m]> | so adding a `maple` asset type with `is_fixed: true` is an easy solution to that |
| [15:51:47] | <mstenta[m]> | but yea... i dunno... `plant` asset? `maple` asset? 🫠 |
| [15:52:14] | <mstenta[m]> | also makes it easier to reference `maple` assets specifically in a `MapleTap` quick form |
| [15:52:34] | <mstenta[m]> | (filtering down to "Maple" crop/variety is also possible... but what if that term changes, new terms added, etc) |
| [15:53:39] | <mstenta[m]> | I think in practice maple producers do think about their groves as a distinct thing - so I feel like separating it does have a good amount of value from a UX perspective |
| [15:53:56] | <mstenta[m]> | And if you're also doing veggies it might be weird to have them mixed |
| [15:54:03] | <mstenta[m]> | 🤷 |
| [15:55:19] | <paul121[m]> | Yeah being able to make them a distinct thing seems important... |
| [15:55:29] | <paul121[m]> | Reminds me of asset categories idea |
| [15:55:58] | <paul121[m]> | IIRC Walt is going to be importing orchard as plant assets, possibly using transplanting logs for location |
| [15:56:16] | <paul121[m]> | Curious his thoughts on how to distinguish the two |
| [15:56:47] | <mstenta[m]> | also important to acknowledge: we aren't starting from scratch - the v1 module does have them as separate assets, and no one has complained or suggested that we change them to plantings... so doing so would be a change |
| [15:57:20] | <mstenta[m]> | they are `sugar_bush` assets (my early attempt to stay general with birch syrup etc in mind) - but IMO `maple` is better/simpler |
| [15:57:36] | <mstenta[m]> | (and actually they are called "Maple" assets in the UI so it was just a machine name difference) |
| [16:01:53] | <mstenta[m]> | i think for now i'll just plow ahead with a new `maple` asset... but keep my wip branch that uses `plant` assets just in case |
| [18:35:14] | <mstenta[m]> | paul121: what do you think of this idea... "view mode quick forms" |
| [18:35:36] | <mstenta[m]> | imagine a quick form that simple renders an entity form in a given view mode |
| [18:35:43] | <mstenta[m]> | s/simple/simply/ |
| [18:35:57] | <mstenta[m]> | (and therefore already supports editing existing entities as well) |
| [18:36:10] | <mstenta[m]> | for simple quick forms, that could be pretty powerful |
| [18:36:59] | <mstenta[m]> | and... could potentially allow quick forms to be built through the UI - using Drupal's normal Field UI features, plus maybe an option we could add to "make a quick form for this view mode" 🤔 |
| [18:37:33] | <mstenta[m]> | @pcambra basically took this approach with the NFA work |
| [18:37:55] | <mstenta[m]> | (loading view modes in off-canvas) |
| [18:37:59] | <paul121[m]> | view mode or form display? |
| [18:38:08] | <mstenta[m]> | yes sorry, "form display" |
| [18:38:24] | <mstenta[m]> | (i still use those interchangeably - bad habit) |
| [18:39:33] | <mstenta[m]> | > (loading view modes in off-canvas) |
| [18:39:34] | <mstenta[m]> | (still eager to experiment more with this too!) |
| [18:39:50] | <paul121[m]> | yea I like that idea! is there a concept of "Form modes" tho? |
| [18:39:57] | <mstenta[m]> | yep! |
| [18:40:07] | <paul121[m]> | I actually just created a custom view mode for something but I don't see the UI for custom form mode... ? |
| [18:40:29] | <mstenta[m]> | oh hmm... i know there is... but hmm i wonder if they are programatically defined? not through the UI? |
| [18:40:42] | <mstenta[m]> | @pcambra used it in NFA so I know it's there |
| [18:41:08] | <paul121[m]> | ah okay yeah maybe. here is what I see: |
| [18:41:14] | <paul121[m]> | ACTION uploaded an image: (22KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/tEYqsLiDnGJ... > |
| [18:42:05] | <paul121[m]> | oh oh I see it. `admin/structure/display-modes` lists Form modes, and View modes |
| [18:42:14] | <paul121[m]> | you only see the option to edit Form modes if you have additional ones :-) |
| [18:42:39] | <mstenta[m]> | https://github.com/Cambrico/farm_nfa/blob/2.x/config/sync/core.entity_fo... |
| [18:42:44] | <mstenta[m]> | (an example of one @pcambra made) |
| [18:43:05] | <mstenta[m]> | basically a "quick form"! |
| [18:43:15] | <paul121[m]> | so - create quick forms for asset/log form modes, configured using entity form displays? |
| [18:43:18] | <mstenta[m]> | yea |
| [18:44:21] | <mstenta[m]> | maybe we could provide a simple quick form base class with core that does all the lifting, so you just extend it and specify the view_mode to use |
| [18:44:34] | <paul121[m]> | form_mode !!! |
| [18:44:53] | <paul121[m]> | :D |
| [18:45:23] | <paul121[m]> | or maybe the form_mode could have third party settings saying "use this as a quick form" ? |
| [18:45:28] | <mstenta[m]> | yeaa maybe |
| [18:45:35] | <paul121[m]> | and use plugin deriver to create the plugins? |
| [18:45:35] | <mstenta[m]> | i like that idea! |
| [18:45:46] | <mstenta[m]> | boom. |
| [18:46:03] | <mstenta[m]> | Quick form builder UI :-) |
| [18:46:11] | <mstenta[m]> | for very simple forms anyway |
| [18:46:26] | <paul121[m]> | Right, I think there's a way to expose a UI for third party settings too? |
| [18:46:36] | <mstenta[m]> | and from there we could start building out more widgets or something - to expand possibilities for individual fields |
| [18:46:46] | <mstenta[m]> | like @pcambra's quantity widget |
| [18:46:49] | <paul121[m]> | Or maybe we use a convention that the form_mode starts with `quick_form_*` |
| [18:46:58] | <mstenta[m]> | oh yea maybe |
| [18:51:23] | <paul121[m]> | mstenta[m]: does this allow submitting multiple quantities, each with different config? |
| [18:51:41] | <paul121[m]> | just thinking, most form widgets don't quite work like that |
| [18:52:27] | <paul121[m]> | but I imagine you could make one that requires a `delta` of 3, and item 1 needs to look like this, etc... |
| [18:55:31] | <mstenta[m]> | yea that was the idea - i forget where it stands, or if he's done more |
