| [03:15:24] | * heartburn has quit (Ping timeout: 255 seconds) |
| [03:17:30] | * heartburn has joined #farmos |
| [04:59:24] | <FarmerEd[m]> | ACTION uploaded an image: (302KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/dRxMikMHewo... > |
| [05:05:37] | <FarmerEd[m]> | > You might be taking this node-red stuff too far Farmer Ed 😆 |
| [05:05:37] | <FarmerEd[m]> | Only getting started 🤓 |
| [05:05:37] | <FarmerEd[m]> | Here is an App built with Node-Red, running locally on my phone so no need for a remote Node-Red server. This version is accessing the farmOS API in real time, but could easily be converted to an offline tool too. |
| [05:06:16] | <FarmerEd[m]> | It pulls the image from farmOS or uses a placeholder image if none were stored. |
| [06:41:51] | <mstenta[m]> | 🤯 |
| [06:42:12] | <mstenta[m]> | That's incredible! |
| [06:42:32] | <mstenta[m]> | Did you build the UI with Node Red too? |
| [06:43:12] | <FarmerEd[m]> | Yes, completely |
| [06:44:19] | <FarmerEd[m]> | It is possible to use additional Html, js, Vue etc. But that is just using the basic UI nodes. |
| [06:44:37] | <mstenta[m]> | > You might be taking this node-red stuff too far Farmer Ed 😆 |
| [06:44:37] | <mstenta[m]> | I take it all back! |
| [06:46:47] | <FarmerEd[m]> | 😃 |
| [10:03:17] | * farmBOT has joined #farmos |
| [12:07:39] | <paul121[m]> | <mstenta[m]> "paul121: I'm trying to get..." <- I believe we have configuration for this in our phpcs file. or when we run phpcs there is a flag to configure this IIRC |
| [12:09:43] | <mstenta[m]> | i figured it out... it was a mistake in my local env |
| [12:10:06] | <mstenta[m]> | (a very strange one too... not one that i would expect would cause this issue) |
| [12:10:55] | <mstenta[m]> | > I don't know _why_ exactly it wasn't working... but I found that I had both `web/profiles/farm` and `web/profiles/profiles/farm` (by accident) and deleting the latter made tests work again 🤷 |
| [12:15:22] | <paul121[m]> | <mstenta[m]> "I *think* we landed on defaultin..." <- 👍️ |
| [13:41:19] | <paul121[m]> | soooo a limitation of our current GeoJSON feature is that it is not paginated :-/ This shouldn't be an issue until an instance has many 100s of assets with geometries. But it's an issue for Rothamsted's Experiment plan which in can in some cases have this many assets |
| [13:41:47] | <paul121[m]> | As I understand WFS/OGC features API might have support for pagination or "offsets"... cc: symbioquine |
| [13:41:58] | <symbioquine[m]> | Yeah, I think so... |
| [13:42:04] | <symbioquine[m]> | It's been a while |
| [13:42:54] | <symbioquine[m]> | WFS definitely does, I just can't remember whether I implemented it yet or not :) |
| [13:43:49] | <paul121[m]> | cool! |
| [13:44:23] | <paul121[m]> | it would also be a question if Openlayers client can consume the pages |
| [13:44:32] | <symbioquine[m]> | I definitely implemented bounding box queries, so if you zoom in it would get just the features for the area you're viewing |
| [13:46:48] | <symbioquine[m]> | Oh, yeah I'm only advertising the BBOX filter capability: https://github.com/symbioquine/farmOS_wfs/blob/33e72466fb2a56f31bb1e494b... |
| [13:46:55] | <symbioquine[m]> | So I think that's the answer for now... |
| [13:48:06] | <paul121[m]> | I'm also curious if we could improve the speed of geojson requests. Right now it is computed from WKT each time it is requested, but really it should only need to be computed once, at the time the geometry is saved |
| [13:48:35] | <paul121[m]> | similar to how the bbox is computed and saved in the table as well |
| [13:49:42] | <mstenta[m]> | yea that seems like something the geofield modules should just do |
| [13:49:44] | <symbioquine[m]> | Oh, yeah I think pagination isn't really in the WFS 1.1.0 spec that I implemented, you'd need WFS 2.0 for that... |
| [13:49:55] | <symbioquine[m]> | But OpenLayers supports it in either: https://github.com/openlayers/openlayers/blob/3b5e95b6c1f790c24ad1d632b3... |
| [13:50:20] | <symbioquine[m]> | Since I guess some WFS implementations go off-spec and provide it with WFS 1.1.0 anyway. |
| [13:52:20] | <symbioquine[m]> | Happy to accept a PR for farmOS_wfs that does the same thing if it brings it in line with was QGIS and OpenLayers support when talking to a WFS 1.1.0 server... |
| [13:52:40] | <symbioquine[m]> | or possibly implementing WFS 2.0 in farmOS_wfs, but that would be a much larger change |
| [13:54:36] | <paul121[m]> | cool! I'm not sure which I would prioritize... both would be amazing haha |
| [13:56:02] | <symbioquine[m]> | Yeah, no pressure :) |
| [13:57:11] | <paul121[m]> | WFS 2.0 would be an amazing initiative. maybe something we could try to advocate funding for |
| [13:57:26] | <paul121[m]> | it seems it would be quite useful for integrating with all sorts of existing things |
| [13:58:13] | <symbioquine[m]> | There's also the newer "OGC Features API" |
| [13:58:19] | <paul121[m]> | righttt |
| [13:58:39] | <symbioquine[m]> | I was kinda letting the "dust settle" to see what would be better from a QGIS/OpenLayers support perspective. |
| [13:58:56] | <symbioquine[m]> | WFS 1.1.0 is perfectly functional for most things |
| [14:01:43] | <paul121[m]> | and there are major changes between all of these? not just additional features? |
| [14:02:07] | <symbioquine[m]> | yeah, to varying degrees I think |
| [14:02:19] | <symbioquine[m]> | Would need to do some careful reading of the specs to answer properly :) |
| [14:04:16] | <symbioquine[m]> | I can't remember which protocol versions it becomes a possibility in, but GeoJSON is a possible response format |
| [14:04:33] | <paul121[m]> | yeah. well I'd be curious to learn more! it would be great to eventually have a formal proposal/spec of what would be needed to implement the latest versions, prioritize features/filters, etc... |
| [14:04:36] | <paul121[m]> | oh cool |
| [14:04:37] | <symbioquine[m]> | https://gis.stackexchange.com/a/251743/64579 |
| [16:14:13] | <mstenta[m]> | > the automated tests really killed that dream 😜 |
| [16:14:14] | <mstenta[m]> | idle thought but... i wonder if there's any argument for packaging farmOS releases without test code? |
| [16:14:35] | <mstenta[m]> | i wonder what the size difference would be (and if it would matter) |
| [16:15:13] | <mstenta[m]> | might be a bit tricky to do, too... because tests are all nested in each module directory |
| [16:15:27] | <mstenta[m]> | but could probably figure out some way |
| [16:15:52] | <symbioquine[m]> | Or just calculate the code ratios in a way that ignores the tests |
| [16:16:08] | <mstenta[m]> | ah that's interesting too |
| [16:16:46] | <mstenta[m]> | fwiw i learned that GitHub looks at this file when calculating code ratios: https://github.com/farmOS/farmOS/blob/2.x/.gitattributes |
| [16:17:01] | <mstenta[m]> | I had to add that in order for YAML to get counted at all |
| [16:18:44] | <mstenta[m]> | https://github.com/github/linguist/blob/master/docs/overrides.md |
| [16:19:23] | <symbioquine[m]> | Cool! |
| [16:19:41] | <mstenta[m]> | maybe: */tests/*.php -linguist-detectable |
| [16:20:14] | <symbioquine[m]> | Could we just bump them into a new fake language "PHP Tests"? |
| [16:20:24] | <mstenta[m]> | huh |
| [16:20:25] | <symbioquine[m]> | So they still show up, but aren't mixed in with the regular PHP code? |
| [16:20:29] | <mstenta[m]> | interesting idea |
| [16:20:38] | <mstenta[m]> | or just "tests" |
| [16:21:16] | <mstenta[m]> | maybe i'll try a quick test on my fork |
| [16:30:06] | <mstenta[m]> | hmm i think it only works for languages defined in https://github.com/github/linguist/blob/master/lib/linguist/languages.yml |
| [16:36:24] | <mstenta[m]> | tried these - no effect:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/fdae12a7fa...) |
| [16:37:25] | <mstenta[m]> | hard to tell how the caching of it works... but i did try this initially and it did have an effect (but seemed to jump back and forth with refresh, probably diff load balancers or something)(: |
| [16:37:25] | <mstenta[m]> | `*.php -linguist-detectable` |
| [16:37:39] | <mstenta[m]> | oh well giving up :-) |
| [16:37:51] | <mstenta[m]> | timebox exceeded |
| [16:39:03] | <mstenta[m]> | > i wonder what the size difference would be (and if it would matter) |
| [16:39:03] | <mstenta[m]> | in either case, this was kind of a different question... whether or not there would be justification for offering slimmer packaged releases that don't include all the testing code |
| [16:39:28] | <mstenta[m]> | maybe nice on a raspberry pi... but i suppose even there storage is pretty cheap these days... |
| [16:39:59] | <mstenta[m]> | the tarball size of farmOS 2.0.0-beta8.1 is 81.3 MB |
| [16:40:20] | <mstenta[m]> | i bet the vendor code takes up the bulk of that, so excluding our test code probably wouldn't really make much difference |
