We have been struggling trying to implement some workflows consisting of a Postgis DB, QGIS, QfieldCloud and Qfield. A very standard architecture.
We need to collect lots of data from more than a dozen of forms. The type of form to be used must be chosen from a dropdown menu in the beginning, same as the Unit type (metric, imperial, and more).
Summary, we need Qfield to show a main page with the form type options (dropdown), then a second page with the chosen form.
From my understanding, this would all be configured in the QGIS properties for each layer. You can use the “Drag and Drop Designer” option, found in the Attributes Form tab of the layer properties to create a form with tabs/sections that are enabled based on other field choices. you can define dropdown lists, etc. and lock the datatype and ranges for fields.
If there are any other methods, I’d be interested to hear!
I was wondering if it would be possible to apply a more centralized architecture, when is just one QGIS layer connected to only one POSTGIS table other than a Drag and Drop Designer approach?
Maintenance wise, a form with dynamic widget configurations by attribute connected to the back end would be more effective, specially considering dozens of forms as a choice.
I am simply a user like you, I am not familiar with other methods to set up the attribute form on QField. But I hope others might have some input here that reveals a simpler method
This may also be of use - XLSForm based project creation? I am not familiar with it’s usage or if it does what you are looking for, but it might be applicable.
just thinking, but QGIS allows to store pretty much an entire project inside a geopackage. Since forms are pretty much just part of a project’s configuration, and a geopackage is pretty much just a SQLite database, maybe there is the potential to directly store different and/or programmatically set forms directly on your postgis db (with some kind of custom manager to handle this). I haven’t heard of storing qgis projects on postgis, but it doesn’t sound too far fetched.
Could you give some more detail on your setup? You mention a dozen forms and a distinction between Unit type. At the same time it seems you store all data in one single table?
What kind of ‘objects’ are being surveyed? Does each object have values from attributes from different forms? I mean, form 1 supplies the color and size of the object, while form 2 supplies the age and other attributes of an object? Does each object have values in different Units? Or does an object only receive values from one specific form and are objects surveyed with form 1 stored a separate objects to objects surveyed with form 2?
Storing everything in one single table is an option, but not necessarily a good option.
That aside, what you could do is add the table multiple times in you project in QGIS, create a form for each ‘duplicate layer’ and rename each layer. The user then has to select the correct layer to edit and will get the corresponding form. Since these layers are copies of the same source table, all edits in every layer end up in the same source table.
You can add a source table many times manually, or use the ‘duplicate layer’ functionality in QGIS (right click the layer in the Browser panel), this will also duplicate the styling and thus the form, which might be useful if you can reuse part of your form.
My team is using a similar setup (postGIS backend, QGIS/QField frontend) and that stack has quite a lot of potential. @hadallen mentioned above that you can control visibility of tabs/sections/group boxes based on other fields. Which is pretty much the way to go.
I would like to add that there are options on the backend as well: I rarely connect my layers to tables directly, but create views in postgres. Even if these views are just a direct query of a table, they offer extra features which are very useful. Just some examples:
you can define combinations of boolean fields
filtering the data, based on user choice
maintenance: if a field (name|logic) changes in the backend, you can temporarily redirect
update rules: you can distribute data to multiple tables, or run functions to check user input, …
Some time ago, I attempted to dynamically create QGIS layers via pyQGIS; those were determination keys, decision trees, which are too complex to design by hand and irregularly change by expert decision. The attempt was not too successful, and for the main part of my project not needed, so I never ended up realizing it. But if you want to go “all in”, you could use a python script to spin up all those complicated forms.
There are more options, actual GUI design is possible by providing a “ui file” for QGIS if the “Drag & Drop Designer” is insufficient for your purpose. I guess that directly connects to the Qt internals, but have never tried myself; plus these might not translate well to QField.
It’s super nice to see the community stepping up with great advise!
@australgis , going by your “show a main page with a drop-down form type then a second page with the chosen form”, I would go with expression-based tab visibility setup. Your first tab contains a single drop down combo box, which will then drive the visibility of a second tab within your overall set of tabs.
Beyond trying to leverage the power of the forms themselves, there are two other avenues to explore:
You can ‘abuse’ map themes by adding multiple styles to your layer. Each style will have its own feature form configuration. That’s powerful but it can get out of sync quickly when the manager of the project forgets about it.
You can explore a project plugin to customize QField’s UI/UX, including adding a panel that would drive feature form selection.
by adding multiple styles to your layer. Each style will have its own feature form configuration. That’s powerful but it can get out of sync quickly when the manager of the project forgets about it.