| [03:02:17] | * farmBOT has joined #farmos |
| [03:38:03] | <RUros[m]> | ACTION uploaded an image: (93KiB) < https://matrix.org/oftc/media/v1/media/download/AaAXWgYRnEqhJDK4CDqRkxVf... > |
| [03:38:04] | <RUros[m]> | Hi, all. Have question regarding polygon on map (i use google maps). Recently i noticed that all my polygons (all land assets has locations with defined polygon) have an offset on Y axis (North/South) orientation. I do not know how this happened, but it might be when i updated from 3.4.5 to 3.4.6. But I am not 100% sure because I notice this few days after update. Seems familiar to anyone, and is there a simple fix for this ? |
| [06:23:22] | <mstenta[m]> | RUros: Did Google's satellite imagery update at the same time? |
| [06:24:04] | <mstenta[m]> | It's possible that the base imagery is wrong. Or was wrong when you drew it, and now is corrected. |
| [06:24:12] | <mstenta[m]> | I've heard of this happening before. |
| [06:25:21] | <mstenta[m]> | I think it was someone in Norway who reported that Google layers were always wrong. Off by a certain number of feet. And didn't line up with the GPS from their tractor. |
| [06:26:02] | <mstenta[m]> | So they used map layers from somewhere else that was correct. |
| [06:26:38] | <mstenta[m]> | For what it's worth, nothing in the farmOS updates would have changed your geometries. |
| [06:31:15] | <mstenta[m]> | Out of curiosity: How did you create your polygons originally? Did you draw them by hand with Google layers as the reference to trace over? Or were they mapped via GPS? |
| [06:32:06] | <mstenta[m]> | If you have access to a high quality GPS device, you could try walking a boundary and seeing if it lines up. |
| [07:38:34] | <symbioquine[m]> | RUros[m]: * How accurate does your geometry need to be for your use-case? i.e. Is it a functional problem or just an aesthetic one? |
| [07:38:34] | <symbioquine[m]> | * At the risk of adding a third conflicting datasource (in addition to G-maps and GPS), can you add aerial data from a local government or similar for your area? (sometimes they use more accurate local cartographic projections) |
| [07:38:34] | <symbioquine[m]> | * If you do decide you need to "fix" your geometry, I'd be happy to brainstorm with you on approaches. I do have a bit of experience with that sort of thing: https://farmos.discourse.group/t/translating-rotating-historical-geometry (though I'd be inclined to do it through the API for your use-case) |
| [08:50:08] | <mstenta[m]> | symbioquine: I did some follow-up research on the action links dropdown from our discussion yesterday. Documenting here: https://www.drupal.org/project/farm/issues/2513056#comment-16489358 |
| [08:50:44] | <mstenta[m]> | One thing I just realized: it's not Gin's fault! We are overriding Gin's action links block to make them use a "dropbutton". |
| [08:50:52] | <mstenta[m]> | So I was wrong when I said "it's not our fault but it is our problem" |
| [08:51:07] | <mstenta[m]> | It is in fact BOTH our fault AND our problem 😂 |
| [08:51:56] | <mstenta[m]> | But the other neat thing that I uncovered is a feature request in the Gin issue queue (which paul121 discovered years ago) that suggests a totally different approach... which may be worth considering |
| [08:52:13] | <mstenta[m]> | tl;dr: Create a single "Actions" button, which opens a list of actions in a modal dialog. |
| [08:52:37] | <mstenta[m]> | (This is all outside the scope of the feature request I'm working on, but would be a nice next step) |
| [08:54:13] | <mstenta[m]> | Something like this: https://www.drupal.org/files/issues/2022-03-23/gin_add_content_modal.png |
| [08:54:20] | <mstenta[m]> | (From https://www.drupal.org/project/gin/issues/3211772) |
| [08:54:41] | <symbioquine[m]> | Could be the right move |
| [08:54:44] | <mstenta[m]> | I wrote this in our issue: |
| [08:54:44] | <mstenta[m]> | > maybe we can implement our own modal approach. I'm imagining a route that is provided by our module, which essentially works the same as our "index" routes (eg: index of quick forms, reports, etc), where each item is an action that is available to a given entity. We could replace all of our action links with a single "Actions" button that opens this index up in a modal dialog. That wouldn't be too hard... and would make these actions a |
| [08:54:44] | <mstenta[m]> | lot more scalable. |
| [08:55:20] | <mstenta[m]> | Also: |
| [08:55:20] | <mstenta[m]> | > This approach could have a lot of benefits, including the ability to add descriptions or other content alongside each action. |
| [08:56:25] | <mstenta[m]> | I'll work on wrapping up a PR for this first step (exposing entity actions as button) first... and if I have time maybe I'll give that a quick try... |
| [09:00:41] | <mstenta[m]> | I guess it raises another question: would we want to do that everywhere? Or just on asset/log/organization/plan entities? |
| [09:01:07] | <mstenta[m]> | The "Add Log: [type]" action links are shown in other places too |
| [09:01:25] | <mstenta[m]> | (As well as generic "Add Log", "Add Asset" etc on the dashboard and other places) |
| [09:13:44] | <RUros[m]> | <mstenta[m]> "Out of curiosity: How did you..." <- It was done by hand, following google maps imagery. This is why i am confused, why all of sudden there is offset. I made polygons few months ago and it could be possible that google imagery was updated meanwhile. I have to check if this is true |
| [09:14:28] | <mstenta[m]> | RUros: Can you try a different base layer? Mapbox? |
| [09:14:34] | <mstenta[m]> | To see if they are different? |
| [09:15:30] | <mstenta[m]> | Chances are BOTH base layers would not have been changed... so if they are both wrong (relative to your geometry), then maybe Google "fixed" their positioning. |
| [09:15:53] | <mstenta[m]> | Or if Mapbox is "correct" and Google is "wrong", then maybe they broke it. |
| [09:17:02] | <RUros[m]> | <symbioquine[m]> "* How accurate does your..." <- It is more for reference and aesthetic case most of time. For accurate calculations i also use intrinsict area calculation module |
| [09:19:27] | <symbioquine[m]> | mstenta[m]: It's also not entirely unlikely that they're both buying the imagery data from the same original provider so they could both change at a similar timeframe. |
| [09:19:54] | <symbioquine[m]> | That's why I was asking about sources like county aerial imagery. |
| [09:20:01] | <mstenta[m]> | yea true... my tests are not necessarily conclusive |
| [09:20:55] | <symbioquine[m]> | Ultimately, it may be necessary to choose one as a source of truth and accept that they may not all match. |
| [09:22:38] | <symbioquine[m]> | The GPS test is a good place to start if it's not too difficult because many folks like to be able to treat the GPS data as fairly accurate and you won't be able to "fix" that - whereas you can always create modified satellite/aerial imagery layers (for your specific spot) if you need to. |
| [09:29:39] | <mstenta[m]> | symbioquine: Separate topic but curious what you and others think... I'm thinking more about revision messages (reviewing these bulk actions to see if any of them should be setting revision messages). |
| [09:29:53] | <mstenta[m]> | Couple of ideas: |
| [09:30:39] | <mstenta[m]> | In edit forms, there is a field for setting the revision message, but it's not required and is empty by default. Probably never gets used. |
| [09:31:05] | <mstenta[m]> | Should we consider adding a default value to that field? Something like: "Updated via log edit form." |
| [09:31:37] | <mstenta[m]> | That got me thinking about API updates too... and if we should try to add something similar: "Updated via API." |
| [09:32:15] | <mstenta[m]> | But I think that's difficult... we tried doing something similar in the past and I think we found that it's hard to differentiate updates that come from the API (although we might be able to dig deeper and find a way). |
| [09:32:30] | <mstenta[m]> | Then it made me think: what if we made the revision log message field required? |
| [09:32:40] | <mstenta[m]> | This would be a breaking change, so it would have to wait for 5.x. |
| [09:32:52] | <mstenta[m]> | But that would mean that API updates would need to set a revision log message. |
| [09:33:45] | <mstenta[m]> | The goal of all this is to have a better record of why changes were made. |
| [09:33:49] | <mstenta[m]> | And where they happened. |
| [09:35:24] | <symbioquine[m]> | This might fall into the category of premature optimization, but would that add 26 and 16 bytes of uncompressed (by default) data to the DB for every form and api update respectively? |
| [09:35:44] | <mstenta[m]> | Yes. Good consideration. |
| [09:36:47] | <symbioquine[m]> | I don't have a sense of what the disk footprint of a revision record is as a whole though so maybe that's tiny or large relatively speaking. |
| [09:37:44] | <mstenta[m]> | Yea... and revision rows are created regardless, just with an empty column for message. |
| [09:37:55] | <symbioquine[m]> | It presumably would compress pretty well, so backups likely wouldn't get too much larger. |
| [09:38:14] | <mstenta[m]> | Mm yea especially with stock/default values. |
| [09:38:23] | <mstenta[m]> | (values that are repeated a lot) |
| [09:38:32] | <symbioquine[m]> | mstenta[m]: Presumably varchar not a fixed character field? |
| [09:38:46] | <mstenta[m]> | Checking... |
| [09:39:25] | <mstenta[m]> | text |
| [09:40:02] | <mstenta[m]> | defaults to null |
| [09:45:25] | <symbioquine[m]> | https://dba.stackexchange.com/a/267424 |
| [09:53:45] | <symbioquine[m]> | ACTION sent a text code block: https://matrix.org/oftc/media/v1/media/download/AVPgWoHucjHFdQuGHY5mjwU-... |
| [09:56:02] | <symbioquine[m]> | https://stackoverflow.com/questions/41991380/whats-the-difference-betwee... |
| [10:01:17] | <mstenta[m]> | <mstenta[m]> "One thing I just realized: it'..." <- FYI this is what it looks like if we remove our override: |
| [10:01:28] | <mstenta[m]> | ACTION uploaded an image: (62KiB) < https://matrix.org/oftc/media/v1/media/download/AbOMvuBzuTsEnoIAHRKEuBUj... > |
| [10:01:38] | <mstenta[m]> | 😵😆 |
| [10:23:12] | <symbioquine[m]> | <symbioquine[m]> "farm=# SELECT pg_size_pretty( pg..." <- I really hope each revision isn't 100+ KB 🧐 |
| [10:24:54] | <mstenta[m]> | Hmm |
| [10:25:06] | <mstenta[m]> | Well and that's only the asset__revision table... |
| [10:25:14] | <mstenta[m]> | Fields have field_revision__[field-name] |
| [10:27:40] | <symbioquine[m]> | Yeah that "+" in my statement might be doing a lot of work. |
| [10:28:22] | <mstenta[m]> | If we want to dig into this, I can probably run some queries on real world databases with lots of revisions to get a better sense |
| [10:28:48] | <mstenta[m]> | (Some other time...) |
| [11:22:35] | <symbioquine[m]> | On one hand it probably doesn't matter too much, but it would also be incredible if toggling the archived boolean 11 times takes up ~1MB |
| [12:04:47] | <edbob[m]> | if it helps to know whether change came from UI or API, maybe add a "flag(s)" to revision table for those instead of injecting comments? i think comments are mostly useful for "unusual" changes, better to avoid the noise even if storage is not an issue. fwiw |
| [12:06:54] | <mstenta[m]> | Yea that's interesting... almost like the "source" field we talked about, for designating where something was created... but this would be at the revision level. I know it's possible to alter the schema of revision tables, but they are not "fieldable entities" in the same sense, so it would be a custom change. I'm hesitant to hack core structures like that unless necessary... |
| [12:08:49] | <mstenta[m]> | > i think comments are mostly useful for "unusual" changes, better to avoid the noise even if storage is not an issue. fwiw |
| [12:08:49] | <mstenta[m]> | yea this is valid too. my motivation is to encourage more detailed change records... repeating the same message is not very useful, other than as a default that shows the general source. |
| [12:09:23] | <mstenta[m]> | making the revision log message required without a default would encourage API authors to vary their messages based on the actions that their app is taking, which would be a good thing, I think |
| [12:09:29] | <edbob[m]> | makes sense, i wondered about that (altering revision table). anyway just my 2c - practicality may dictate what path to take |
| [12:09:36] | <mstenta[m]> | but it does add another hurdle |
| [12:09:58] | <mstenta[m]> | (and would be a breaking change, so we wouldn't be able to add it until 5.x) |
| [12:10:09] | <mstenta[m]> | (making revision log message required, I mean) |
| [12:10:39] | <edbob[m]> | hm i think requiring API calls to include a message will wind up with just as much "noise" comments with not a lot of great detail/info probably..? |
| [12:11:18] | <mstenta[m]> | the problem i'm trying to solve is: when I look at the "Revisions" tab of an asset that has been changed a lot, 99% of the time the messages are blank. what did they change? why? from where? via edit form? via api? elsewhere? |
| [12:11:58] | <mstenta[m]> | (eventually we'll have a "Diff" option to see the actual changes, which will help... but that doesn't tell where/why it happened) |
| [12:13:07] | <edbob[m]> | can't say what is possible with drupal revisions..but yes i think a diff would give enough info? is it also possible to attach a comment to a revision after the fact? |
| [12:13:39] | <mstenta[m]> | not after the fact... there is a UI field for adding a comment when you make a revision through the edit form, but it is not required |
| [12:13:54] | <mstenta[m]> | can't edit old revision logs via the UI |
| [12:13:59] | <mstenta[m]> | (currently) |
| [12:14:00] | <edbob[m]> | i use the diff approach for my app. currently do not allow post-adding comments but do show username and IP / timestamp |
| [12:14:16] | <mstenta[m]> | diff helps some... but not with source/purpose |
| [12:14:29] | <mstenta[m]> | kind of like code comments |
| [12:14:29] | <edbob[m]> | ACTION uploaded an image: (226KiB) < https://matrix.org/oftc/media/v1/media/download/ARpS3XGS5pTl4S25vyPkqrRj... > |
| [12:14:32] | <mstenta[m]> | the "why" not just the "what" |
| [12:14:52] | <mstenta[m]> | neat! |
| [12:15:10] | <mstenta[m]> | i'm also thinking in the context of larger farmOS deployments with lots of users changing things |
| [12:15:32] | <mstenta[m]> | revisions record who did it, but the "why" is optional |
| [12:15:59] | <edbob[m]> | yeah, i don't disagree with the goal. i just think if you require user to add comment for "everything" you will wind up with lots of unhelpful comments ("asdf" etc.) |
| [12:16:20] | * temphbo[m] has joined #farmos |
| [12:16:39] | <mstenta[m]> | I agree |
| [12:17:35] | <mstenta[m]> | This is also something we don't need to be opinionated on at the farmOS level... |
| [12:17:53] | <edbob[m]> | possibly "require" comments selectively and within the UI layer, not schema. e.g. comment is required to edit an asset but not adding a log |
| [12:17:58] | <mstenta[m]> | It would be a trivially simple module to make that field required, which can then be installed on sites that want to enforce it |
| [12:18:21] | <mstenta[m]> | that's a good point regarding the distinction between adding/editing also... |
| [12:18:32] | <mstenta[m]> | don't need to explain why you're adding something |
| [12:18:47] | <mstenta[m]> | but knowing why something changed later can be |
| [12:18:54] | <mstenta[m]> | (helpful) |
| [12:51:35] | <edbob[m]> | something else to consider maybe - as a user if i'm entering some "comment" i might expect and/or prefer that to be part of the asset/log notes field, as opposed to be tucked away in a revision history? |
| [14:08:51] | <symbioquine[m]> | <edbob[m]> "something else to consider maybe..." <- I think this is a bit like the difference between a commit message and a comment in the code... |
| [14:09:51] | <symbioquine[m]> | The revision message shouldn't be necessary to understand the current state, but might be necessary if somebody is troubleshooting why something is how it is. |
| [14:10:09] | <mstenta[m]> | It's the difference between "what changed on the farm" and "what changed on this record" |
| [14:10:50] | <symbioquine[m]> | So most state changes with the real world should be captured by logs. |
| [14:12:02] | <symbioquine[m]> | That's why archived shouldn't serve double-duty to indicate an animal's death - it should only represent that the animal record isn't relevant in farmOS. |
| [14:12:38] | <symbioquine[m]> | * isn't relevant for display in farmOS. |
| [14:19:52] | <mstenta[m]> | Yea let's start thinking ahead to 5.x on that... (merge wotnak's asset termination module?) |
| [14:21:02] | <mstenta[m]> | Maybe worth reviewing how we handle the other end too (birth, seeding, purchase, etc) |
| [14:21:40] | <mstenta[m]> | All of this feels relevant to the timeline visualization work too! 😄 |
| [14:22:18] | <mstenta[m]> | (Can happen independently though) |
