| [20:06:38] | <symbioquine[m]> | <mstenta[m]> "symbioquine: I started playing..." <- Very cool. I'll look forward to seeing how you're approaching it! |
| [09:14:21] | <symbioquine[m]> | <mstenta[m]> "symbioquine: I started playing..." <- Also, I don't know if you've seen this: https://github.com/symbioquine/farmOS_wfs/blob/a6b269f6bcc0de4611050f1e1... |
| [09:14:28] | <symbioquine[m]> | Might be similar to what you're doing... |
| [09:17:10] | <mstenta[m]> | Oh neat! |
| [09:18:19] | <symbioquine[m]> | That makes it so when you zoom in QGIS (or similar) can ask for just the assets which will be onscreen |
| [09:18:33] | <mstenta[m]> | ah that's nice |
| [09:19:46] | <symbioquine[m]> | If you set a minimum zoom level and a few query filters on the layers you can make it so it never issues "get all assets" queries |
| [09:20:13] | <mstenta[m]> | this is the basic query i was experimenting with: https://github.com/mstenta/farmOS/blob/10c10309f4f97dc1809dac73d9b24b886... |
| [09:20:24] | <mstenta[m]> | (super simple, just a proof of concept still) |
| [09:20:26] | <symbioquine[m]> | i.e. shows the property boundary and landmark assets at any zoom level, but doesn't show beds, plantings, etc until you're zoomed in enough that it will be a subset of the assets. |
| [09:20:59] | <mstenta[m]> | that query requires postgis |
| [09:21:39] | <mstenta[m]> | but I'm curious if we could do something similar with other dbs |
| [09:21:45] | <mstenta[m]> | or postgres w/out postgis |
| [09:22:37] | <mstenta[m]> | right now this query takes ANY wkt |
| [09:22:45] | <mstenta[m]> | it might make sense to limit it to a point |
| [09:23:10] | <mstenta[m]> | if we did that, then we could potentially use the bounding box fields in the db table to do a more rough intersection without any geometry functions |
| [09:23:17] | <mstenta[m]> | (similar to what you have) |
| [09:23:52] | <symbioquine[m]> | Or you can generate a bounding box, query the features, and do a final filter step in PHP |
| [09:24:04] | <symbioquine[m]> | To still end up with a strict intersection |
| [09:24:08] | <mstenta[m]> | yea perhaps! |
| [09:24:50] | <mstenta[m]> | i'd like to wrap this in a Views argument handler, so we can add it to any View as a contextual filter basically |
| [09:25:05] | <mstenta[m]> | i'm imagining showing a list of logs filtered by intersecting wkt as a first step |
| [09:25:19] | <mstenta[m]> | assets would be easy too |
| [09:25:46] | <mstenta[m]> | (geometry vs intrinsic_geometry fields in different database tables, so two different Views) |
| [09:26:13] | <symbioquine[m]> | Hmmm |
| [09:28:29] | <symbioquine[m]> | Couldn't it work like the [AssetOrLocationArgument](https://github.com/farmOS/farmOS/blob/c9770ca6ca7a572adb28a514e0cda8480b...) to do both in the same view? |
| [09:29:46] | <mstenta[m]> | Well... one is a query of assets and one is a query of logs |
| [09:30:01] | <mstenta[m]> | AssetOrLocationArgument is only used in a query of logs |
| [09:30:21] | <mstenta[m]> | (logs that reference and asset OR logs that reference a location) |
| [09:30:54] | <mstenta[m]> | for this report, we may want "logs that have a geometry that intersects this point" and "assets that have an intrinsic geometry that intersects this point" |
| [09:31:08] | <mstenta[m]> | SELECT * FROM log vs SELECT * FROM asset |
| [09:31:35] | <mstenta[m]> | But that won't be too hard... we can just embed two views in the report |
| [09:31:47] | <mstenta[m]> | Or provide a radio button to select which you want |
| [09:32:07] | <mstenta[m]> | Still thinking through how it should work from a UX perspective :-) |
| [09:32:30] | <symbioquine[m]> | I thought you were saying that it fixed assets and non-fixed assets wouldn't be query-able (by geometry intersection) in the same view |
| [09:32:34] | <mstenta[m]> | Another thing on my mind: query performance, do we need to add a geometry index, etc |
| [09:32:53] | <symbioquine[m]> | s/it// |
| [09:32:57] | <mstenta[m]> | Oh maybe I misunderstood |
| [09:33:30] | <mstenta[m]> | Right... I do think we would need to limit to fixed assets for the asset view |
| [09:34:31] | <mstenta[m]> | Although might be able to do a sub-select to get each asset's most recent movement log geometry... but that gets hairy. probably easier to start simple. |
| [09:35:59] | <symbioquine[m]> | mstenta[m]: I think that's what I'm doing here: https://github.com/symbioquine/farmOS_wfs/blob/a6b269f6bcc0de4611050f1e1... |
| [09:36:32] | <mstenta[m]> | oh cool - maybe we could reuse that |
| [09:37:03] | <symbioquine[m]> | Agree on starting simple though as long as the UX makes sense and it doesn't preclude doing the more complete implementation later. |
| [09:37:08] | <mstenta[m]> | i've been burned by complicated queries (and specifically cross-db-comaptibility) in the past so i tend to avoid thinking about things like this haha |
| [10:49:25] | * OctavioMartnDuarte[m] has joined #farmos |
| [10:49:25] | <OctavioMartnDuarte[m]> | Hello! I'm having an issue with the new JSON schema for boolean stuff, I though I could get some help from mstenta or paul121 . |
| [10:49:45] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: The new schema sets the type as "boolean", but it has a custom definition asking for 0/1 values. |
| [10:49:46] | <mstenta[m]> | Sure Octavio Martín Duarte what's up? |
| [10:50:09] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: This seems to contradict the official definition in the JSON schema documentation. |
| [10:50:09] | <OctavioMartnDuarte[m]> | https://json-schema.org/understanding-json-schema/reference/boolean |
| [10:50:16] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: Which asks for either "true" or "false" as values. |
| [10:50:18] | <mstenta[m]> | OctavioMartnDuarte[m]: Ah I see |
| [10:50:33] | <OctavioMartnDuarte[m]> | mstenta[m]: The result of this is I get a schema that has 0 possible valid entries. |
| [10:50:37] | <mstenta[m]> | OctavioMartnDuarte[m]: I think I know why that would happen |
| [10:51:03] | <mstenta[m]> | mstenta[m]: I need to refresh on where that code is... |
| [10:51:21] | <mstenta[m]> | mstenta[m]: But I bet it is just simply showing the allowed values of the database *internally* |
| [10:51:25] | <mstenta[m]> | mstenta[m]: which is 0 or 1 |
| [10:51:35] | <mstenta[m]> | mstenta[m]: And not translating it to what JSON would expect |
| [10:51:45] | <OctavioMartnDuarte[m]> | mstenta[m]: That could make sense. |
| [10:52:13] | <mstenta[m]> | OctavioMartnDuarte[m]: In all other cases, that's how it works, so I wouldn't be surprised (just showing internal allowed values and not translating) |
| [10:52:26] | <OctavioMartnDuarte[m]> | mstenta[m]: But the JSON schema, as written (unless as it tends to happen I'm making a mistake), is contradictory. |
| [10:52:30] | <mstenta[m]> | OctavioMartnDuarte[m]: I imagine it would require some special logic for that translation |
| [10:52:57] | <mstenta[m]> | mstenta[m]: Right, it should say `true` and `false` as allowed values you mean? |
| [10:53:50] | <OctavioMartnDuarte[m]> | mstenta[m]: It could either only read `type: boolean` , which implies `true`/`false` or (exclusive or, xor) have the `oneOf` asking for either 0 or 1. |
| [10:53:56] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: As I get it, at least. Perhaps I'm getting it wron. |
| [10:53:57] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: *g |
| [10:54:09] | <mstenta[m]> | OctavioMartnDuarte[m]: OK good to know |
| [10:54:17] | <mstenta[m]> | mstenta[m]: Let's see... who is the developer to blame for this code.... |
| [10:54:27] | <mstenta[m]> | mstenta[m]: Oh right. It's me. 😅 |
| [10:54:29] | <mstenta[m]> | mstenta[m]: https://www.drupal.org/project/jsonapi_schema/issues/3397275 |
| [10:54:51] | <mstenta[m]> | mstenta[m]: I will have to modify that merge request to include special logic for boolean fields |
| [10:55:08] | <OctavioMartnDuarte[m]> | mstenta[m]: I can have a special version just on our end and downstream from us. |
| [10:55:17] | <mstenta[m]> | OctavioMartnDuarte[m]: And then we will have to update the patch that is applied in farmOS |
| [10:55:18] | <OctavioMartnDuarte[m]> | mstenta[m]: but if I'm getting it properly, it might be worth fixing on your end. |
| [10:55:28] | <mstenta[m]> | OctavioMartnDuarte[m]: Which means this won't be fixed until the next release of farmOS at the earliest |
| [10:55:47] | <mstenta[m]> | mstenta[m]: So if you are able to work around it yourself in the meantime, that might be worth doing |
| [10:55:56] | <mstenta[m]> | mstenta[m]: But I will definitely get this fixed upstream too |
| [10:55:59] | <OctavioMartnDuarte[m]> | mstenta[m]: Ok. We can keep working, we have the exact feature we need, which replaces the schema for a certain field across the whole schemata set. |
| [10:56:08] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: Great, thanks a lot. |
| [10:56:29] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: I'll check it a little more, but the documentation from their site seems to back my interpretation. |
| [10:56:51] | <OctavioMartnDuarte[m]> | OctavioMartnDuarte[m]: gbathree: this thread might be of your interest. |
| [10:57:36] | <mstenta[m]> | OctavioMartnDuarte[m]: > It could either only read type: boolean , which implies true/false or (exclusive or, xor) have the oneOf asking for either 0 or 1. |
| [10:57:36] | <mstenta[m]> | Which one do you think I should aim for? |
| [10:57:44] | <mstenta[m]> | mstenta[m]: Is one "more correct"? |
| [10:58:16] | <mstenta[m]> | mstenta[m]: The first option might be easier (omit `oneOf`) |
| [10:59:07] | <OctavioMartnDuarte[m]> | mstenta[m]: Yes, I'm partial towards just having `type: boolean` . It is cleaner and more intuitive. |
| [10:59:07] | <OctavioMartnDuarte[m]> | But you might have special requierements. |
| [10:59:07] | <OctavioMartnDuarte[m]> | I can propose several examples and attach valid and rejected entries for each one, if that's useful. |
| [11:00:15] | <mstenta[m]> | OctavioMartnDuarte[m]: I'll try for that first. |
| [11:05:05] | <OctavioMartnDuarte[m]> | mstenta[m]: Let me know if I can help in any way. |
| [11:08:03] | <mstenta[m]> | OctavioMartnDuarte[m]: Thanks for bringing it to my attention! |
| [11:10:42] | <OctavioMartnDuarte[m]> | mstenta[m]: Thanks for answering so fast! |
| [12:58:56] | * jsoons[m] has quit (Quit: Client limit exceeded: 20000) |
| [13:33:07] | <mstenta[m]> | <OctavioMartnDuarte[m]> "Thanks for answering so fast!..." <- Updated the `jsonapi_schema` module patch: https://www.drupal.org/project/jsonapi_schema/issues/3397275#comment-155... |
| [13:33:17] | <mstenta[m]> | mstenta[m]: I'll open a farmOS PR to use the new patch next. |
| [13:39:24] | <OctavioMartnDuarte[m]> | <mstenta[m]> "I'll open a farmOS PR to use the..." <- Awesome. Thanks. |
| [13:39:28] | <mstenta[m]> | <mstenta[m]> "I'll open a farmOS PR to use the..." <- https://github.com/farmOS/farmOS/pull/819 |
| [14:40:20] | <mstenta[m]> | symbioquine: we discussed the "ontology uri" ideas again on the dev call yesterday, and I think we're going to settle on `external_uri`. That seems to be where the most consensus is. If you have any strong opinions otherwise feel free to chime in on the issue! Otherwise I think we'll end up with that. :-) |
| [14:41:34] | <mstenta[m]> | We got input from a few others on the call including @julietnpn:matrix.org and jgaehring |
| [14:42:03] | <mstenta[m]> | jgaehring actually suggested "definition uri" also :-) |
| [14:42:36] | <mstenta[m]> | after some discussion it felt like everyone was satisfied with "external uri" |
| [14:43:31] | <mstenta[m]> | another point that was made is that this still leaves open the possibility to add more specific field(s) in the future... such as a structured ontology reference field that has sub-values for data type etc |
| [14:45:42] | <mstenta[m]> | the last remaining bit is adding uri validation |
| [16:42:41] | <shplorf[m]> | <shplorf[m]> "Makes sense, thanks for the..." <- OK, so I got my backup/restore process working.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/iIBFBIyzcGBegIFs...) |
| [16:48:22] | <shplorf[m]> | <shplorf[m]> "OK, so I got my backup/restore..." <- I realize now that the cron.daily script won't actually be run in a container so I'll just mount it to `local/bin` like the restore script and have an external cron job run it. |
| [16:49:08] | <shplorf[m]> | s/`/`/usr// |
| [16:52:22] | <shplorf[m]> | ACTION posted a file: (44KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/ONPFRkXhKrtJRVTZ... > |
| [16:53:05] | <shplorf[m]> | shplorf[m]: ^ Here's the output of my DB restore command, it has a bunch of errors like |
| [16:53:05] | <shplorf[m]> | > ERROR: table "asset__is_castrated" does not exist |
| [16:53:05] | <shplorf[m]> | Is this expected? |
| [16:53:09] | <mstenta[m]> | update: uri validation is done, PR is ready for final review |
| [16:53:31] | <shplorf[m]> | * ^ Here's the output of my DB restore command, it has a bunch of errors like |
| [16:53:31] | <shplorf[m]> | > ERROR: table "asset\_\_is\_castrated" does not exist |
| [16:53:31] | <shplorf[m]> | Is this expected? |
| [16:53:32] | <mstenta[m]> | shplorf[m]: no that means it didn't work i think |
| [16:53:44] | <shplorf[m]> | * ^ Here's the output of my DB restore command, it has a bunch of errors like |
| [16:53:44] | <shplorf[m]> | > ERROR: table "asset\_\_is\_castrated" does not exist |
| [16:53:44] | <shplorf[m]> | Is this expected? |
| [16:53:48] | <mstenta[m]> | mstenta[m]: sorry can't review in detail right now, and i'll probably forget about this thread 😅 |
| [16:53:52] | <mstenta[m]> | mstenta[m]: might be worth a forum topic? |
| [16:54:23] | <mstenta[m]> | mstenta[m]: > Are there any issues with doing this while FarmOS is running? |
| [16:54:23] | <mstenta[m]> | Don't think so. If you want to be extra safe, Drupal has a "maintenance mode" which would prevent users from making any changes |
| [16:54:29] | <mstenta[m]> | mstenta[m]: So you could toggle that on/off if you want |
| [16:54:43] | <mstenta[m]> | mstenta[m]: https://drupal.stackexchange.com/questions/100771/how-do-i-turn-off-main... |
| [16:57:09] | <shplorf[m]> | mstenta[m]: OK, I can write it up in the forum. Def no expectation of any sort of timely responses here or there.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/bdQSfKoZGLuSvaKT...) |
| [16:57:49] | <mstenta[m]> | shplorf[m]: > ERROR: table "asset__is_castrated" does not exist |
| [16:57:49] | <mstenta[m]> | this would worry me |
| [17:00:19] | <shplorf[m]> | mstenta[m]: When I enter the DB credentials initially, where does that get saved? |
| [17:00:41] | <mstenta[m]> | shplorf[m]: `sites/default/settings.php` |