| [08:48:30] | * gbathree[m] has joined #farmos |
| [08:48:31] | <gbathree[m]> | Wondering if there's any plans in the API to save or pass the calculated acreage? In our application when showing fields it's always super helpful to show the acreage. I know also there's a deeper conversation about the types and number of field size calculations, but even just as a start to provide acreage potentially as a norm when querying a field via the api would be really helpful. |
| [11:52:35] | <mstenta[m]> | Hey all! I won't be able to make the dev call today. I'll catch up next week. :-) |
| [11:53:46] | <mstenta[m]> | gbathree: Yea I think those "deeper conversations" need to happen before anything is provided out-of-the-box in farmOS core. In the meantime you could consider adding a computed field to land assets via a custom module. |
| [11:54:14] | <mstenta[m]> | (And of course if you have the geometry you can do the math yourself right now) |
| [11:55:32] | <mstenta[m]> | In terms of next steps in core, there's an open feature request for adding a manual-entry measurement field to allow users to override the auto-computed measurements (in case they are incorrect). |
| [11:55:59] | <mstenta[m]> | https://www.drupal.org/project/farm/issues/3051971 |
| [11:56:25] | <mstenta[m]> | It seems like that would be the first step... and then that field could be filled it automatically with a default value when an asset geometry gets saved (if it isn't already set manually). |
| [11:56:42] | <mstenta[m]> | This would serve to expose those values via the API for both use cases (auto-calculated and manually overridden). |
| [11:57:44] | <mstenta[m]> | The big questions that remain to be answered are: |
| [11:57:44] | <mstenta[m]> | 1. How do we handle units? Acres are not used globally. Do we need to store an additional unit with every measurement? Or do we standardize on meters and leave it to API consumers to convert? |
| [11:57:58] | <mstenta[m]> | 2. Does this only get added to `land` assets? |
| [12:00:22] | <mstenta[m]> | Another consideration in my mind is: what about other types of measurements? Like "length" of fencing (not area)? If that's going to be needed in the future (seems likely), then we need to consider all these use-cases together so we don't shoot ourselves in the foot with a short-sighted implementation that only focuses on area. |
| [12:00:40] | <mstenta[m]> | This is all deserving of a forum topic IMO, if you want to copy and paste all of the above to get the ball rolling gbathree :-) |
| [12:00:53] | <mstenta[m]> | We may already have one... 🤔 |
| [15:39:09] | <gbathree[m]> | <mstenta[m]> "We may already have one... 🤔" <- fair enough... I'll try to get that in. I htink it's valuable but not critical but it keeps coming up so at least we need to move it along |
| [15:40:19] | <gbathree[m]> | mstenta: this may be a farmier question, but not sure if others have noticed or are experiencing it - it seems that the API is not seeing conventions any more. I swear I saw it yesterday... did something change or update since? We (me and Octavio MartÃn Duarte ) checked ourscitest and coffeeshop instances |
| [15:40:41] | <gbathree[m]> | ie in /api/schema no longer contains relationships.conventions |
| [15:40:51] | <gbathree[m]> | for anything (checked logs, assets, etc.) |