optional usage of PostGIS in farmOS (decide when install)
with PostGIS, additional (spatial) functions can be integrated (optional)
For the QGIS interaction, from my perspective it would make sense to abstract the the interface (e.g. using the farmOS API - extension, adding a WFS API to farmos - which could be build e.g. by GeoServer).
Keep in mind that the WFS spec has been recently updated: http://docs.opengeospatial.org/DRAFTS/17-069.html .
The direct interaction of two components via the database API is probably critical, especially when both components have write access and can create mess within the DB.
I think of use cases for QGIS, such as:
static analysis of data
data preparation (field boundary generalization, adjustments, …)
data conversions or preparation of imports
So, using standard interfaces for data transfer between the systems and/or using the plugin option to interact with the farmOS api might be a good option (https://plugins.qgis.org/plugins/).
I believe that’s roughly what @mstenta was describing when he mentioned progressive enhancement.
It doesn’t look like that’s a final version. Even once it’s adopted by OGC it’ll probably take a while for major GIS software applications to fully support it.
I would guess it would be wiser to implement one of the previous WFS specs unless there’s something particularly compelling in the WFS 3.* specs for these use-case(s).
I think @paul121 said he had experimented with a QGIS plugin in conjunction with farmOS.py a long time back.
My assessment more recently is that implementing a standard geospatial API like WFS is a much better value proposition because it could be used in other GIS applications, not just QGIS.
If your farmOS instance is still using EPSG:4326, then I think farm-os-area-feature-proxy would probably still work for you without changes even if your maps in QGIS are EPSG:3763. My understanding is that QGIS will automatically reproject the features into the default CRS of the map - though it might ask you to select a conversion strategy when you add the layer. See 6.1. Lesson: Reprojecting and Transforming Data — QGIS Documentation documentation
Thanks for the followup, @Symbioquine -and to your question,
… I can only say that i never changed the CRS default in farmOS, because i don’t actually know how! So if EPSG:4326 by default, then that’s what it is.
So this means i could at least try farm-os-area-feature-proxy, if i were able to access it through Farmier, where my instance is hosted. Might that be possible, @mstenta ?
I haven’t tested it with Farmier instances, but in theory it should work since it only interacts with farmOS via the API.
The recommended way to install farm-os-area-feature-proxy is via docker. It should also be hosted in such a way that it is accessed via an https endpoint since it handles farmOS credentials in order to access the API on the calling user’s behalf. Thus hosting farm-os-area-feature-proxy generally requires similar technical skills to hosting a farmOS instance - with the exception that farm-os-area-feature-proxy doesn’t persist any data (beyond caching) so some of the operational details like backups wouldn’t be needed.
I’m happy to answer more questions or help troubleshoot any issues, but it might make sense to move questions that are concretely about farm-os-area-feature-proxy (as opposed to the general concept of a WFS interface layer for farmOS being an alternative to direct PostGIS access) into their own thread.
At this point, i must invoke my usual IABASF (I Am But A Simple Farmer copout and ask: what’s the simplest way forward here? I’m using hosted instances of both PostGIS and farmOS, because i’m really not up to maintaining either of those stacks myself. Yet i am most comfortable managing my farm’s Area definitions in QGIS on my (Mac) desktop, and would be very happy if that data could be mirrored out to both PostGIS (got that part working already) and farmOS. If that is indeed possible -or will be soon- i would love to know how!
Probably the simplest and most immediate path forward is to continue managing your area definitions as you have been and manually synchronizing them with farmOS via WKT or KML.
Mid-term, there is a possibility that farm-os-area-feature-proxy could be modified such that it could be hosted generically and used for multiple farmOS instances. Two changes would be needed for that;
Use oauth2 instead of password authentication on behalf of clients
Allow specifying the farmOS instance as part of the request - url/parameter/etc
I’d be happy to help with those modifications, but prioritizing it would be contingent on sufficient interest and an agreement about how it would be hosted since hosting isn’t free and there is extra effort involved in keeping such hosting updated/secure/etc.
A much better strategy in my opinion would be to skip that mid-term and work on building a WFS module for farmOS 2.x. That would allow for designing the capability from the ground-up to build-in the kind of progressive enhancement that this thread alludes to. In theory, WFS capabilities could also serve as a building block for some of farmOS 2.x’s own features since OpenLayers (the library powering farmOS-map) supports WFS too.
If this will enable both (a) the sort of progressive enhancements to farmOS that @mstenta was talking about above, and (b) enabling farmOS to function as a Geometry Server to apps like QGIS (as you seemed to be suggesting, @Symbioquine ) then that sounds pretty exciting to me!
So what would it take to make this happen, i wonder?
We could potentially dust that off, update/rework it for Drupal 9, and then start a farm_wfs module to integrate it in farmOS. This could be done experimentally in contrib-land perhaps, and then we could decide whether or not to pull it into farmOS core.
Nice to have some prior art to work from, i guess…
Would this imply staging the app online in a way that ordinary users (i.e. non-developers) of the software could test its functions? If so, i’d be happy to serve as a tester.
This being something (a web service, if i understand correctly what WFS is, essentially) that only makes sense if there’s a substantial subscriber base, it would be good to know how many would be willing to use the service, and what they might be willing to pay for the privilege. Would it be possible to describe the functions of the service in such a way as to attract crowdfunding for its development?
I’m planning to start experimenting with a WFS module and see how far I get - though the learning curve will be pretty high since I was only just getting my feet under me with Drupal 7 module development.
I’ve released v0.0.1 of farmOS_wfs for farmOS 7.x-1.x. Currently it just supports read-only access to the farmOS areas, but I hope to add transaction (write) support soon. I also plan to add usage/development documentation in the near future.
I originally started experimenting with developing it against farmOS 2.x, but ran into a roadblock in that the area primitives don’t seem to be present yet in 2.x. I’ll try to follow along with the 2.x development and port what I’ve implemented over to 2.x as that becomes possible - and time-allowing of course.
That was only true for farm-os-area-feature-proxy. The contrib module strategy means it effectively runs in the same web container as farmOS, thus the hosting is pretty much taken care of as long as you can get the module installed in farmOS.
At this point that would probably mean waiting for a stable release of farmOS_wfs and negotiating with @mstenta about whether it is something that could be offered in your Farmier instance.
until the farmOS 2.x area/location changes are pushed and ready to build against
FYI my location branch(es) are pretty stable! I’m doing more migration testing before merging into 2.x, but feel free to check out my 2.x-location branch to start developing/testing against!
copout and ask: what’s the simplest way forward here? I’m using hosted instances of both PostGIS and farmOS, because i’m really not up to maintaining either of those stacks myself. Yet i am most comfortable managing my farm’s Area definitions in QGIS on my (Mac) desktop, and would be very happy if that data could be mirrored out to both PostGIS (got that part working already) and farmOS. If that is indeed possible -or will be soon- i would love to know how!
