tags.json makes it hard to switch from one type of survey to another

[AndrewM-]

-I do several different types of survey. For each type of survey, I have developed a different tags.json file. To change survey type, I have to use the Files app on iOs to copy in the new tags.json and then rename the file from its version name (e.g. Flora_-30-y09-2024.json) to tags.json. I wish it was possible to change the tags.json on the fly. That would mean allowing the user to pick the json file that they wish to use, preferably without having to rename the file. I do vegetation surveys, infrastructure surveys, post-disaster surveys and so on, so the different survey types should not be pushed into a single tags.json file.

[moovida]

Regarding this, my future wish is to integrate the current centralized server backend into the G3WSuite and follow its concept of creating forms (QGIS) and loading projects. In that perspective I would also do something we had in geopaparazzi. Back tehn it was called profiles and once you logged into a project, you would have the UI dedicated to that project, i.e. only those tags supplied by that project.
That sounds like something that would work for you.
Right now we are looking for public admins that would partner up to sponsor this. In case you knew someone.

[AndrewM-]

Qfield uses the QGIS forms designer. The great advantage of Smash is that it does not use QGIS forms. QGIS forms are good but a project needs to be fairly mature before forms can be set up. I use Smash for data collection systems that are not mature and that need a lot of iterations to perfect. I think that the JSON forms approach of Smash is much better for iterating form content and design. Qfield has only two advantages over Smash. Firstly, I can populate a combo box with a list of scientific names by uploading the contents of a text file. There is often about 10 000 scientific names and I think it would be inefficient to add such a list to a JSON form. Secondly, Qfield has a larger map window, so I can see more context. KML files were used in my previous job at Vestas as a transfer format from the CAD people to the rest of the organisation. I would burn the KML data into image tiles in mbtiles format, as that would work well and was light enough that an old mobile phone could show all the layers (hundreds of them). However, I would sometimes get the vegetation clearing limits as a single layer KML file. Qfield is quite good for loading those KML files and checking the limits on the ground. Other than that use case, I stuck with Smash as my main need was to iterate form design rapidly.

[moovida]

Hi @AndrewM- , thanks a lot for sharing your experiences. It always helps.

Qfield uses the QGIS forms designer. The great advantage of Smash is that it does not use QGIS forms. QGIS forms are
good but a project needs to be fairly mature before forms can be set up. I use Smash for data collection systems that are
not mature and that need a lot of iterations to perfect. I think that the JSON forms approach of Smash is much better for
iterating form content and design.

Ok, just to make it cristal clear. SMASH forms are going to stay. They are solid and are also evolving due to projects that are sponsoring them (recently added dynamic combos fro urls for example and soon to come hopefully default fields copied from previous note, self iterating ids).
The idea would be to be able to 'also' make them with QGIS forms, which are converted only if you would use the g3wsuite to synch. But this is also a hope-for project :-)

Qfield has only two advantages over Smash. Firstly, I can populate a combo box with a list of scientific names by uploading
the contents of a text file. There is often about 10 000 scientific names and I think it would be inefficient to add such a list to
a JSON form.

How are you creating forms? Are you using the smash integrated form builder?
If yes, this is something you could open an issue on. Adding a file upload to the combo widgets should not be too much of a problem (at least the simple ones).

Secondly, Qfield has a larger map window, so I can see more context.

You mean that the two bars steal too much space?

KML files were used in my previous job at Vestas as a transfer format from the CAD people to the rest of the
organisation. I would burn the KML data into image tiles in mbtiles format, as that would work well and
was light enough that an old mobile phone could show all the layers (hundreds of them).
However, I would sometimes get the vegetation clearing limits
as a single layer KML file. Qfield is quite good for loading those KML files and checking the limits on the ground.

That is once more interesting. We have export to kmz but I never thought this could be of interest at data format. Feel free to open an issue also on that one. I will investigate how much work that might be. If we are lucky it is simple.

Other than that use case, I stuck with Smash as my main need was to iterate form design rapidly.

Great, thanks for these insights.

[AndrewM-]

@moovida Yes, the two bars take a lot of screen space and sometimes this is an issue. Qfield has floating buttons, which appear over the background image. I was flagging trees for trimming, if they were within the 'swept area' of wind turbine blades as the trucks went around corners. So I had to see enough forest to be able to find the correct trees to mark. I was using an iPhone 12. Qfield can also zoom in further than the levels of the mbtile set. So if I create a tile set from levels 12-17, in Smash if I zoom into level 18, the image disappears. In Qfield, the image is still visible and the interpolation is quite good.

I am not using the integrated form designer. I built my own form designer.

KML or KMZ, it does not matter as both formats are equivalent. The main issue that I had was separating the JSON form from the collected data. I can do this using Python. This allows the form design to be iterated in real time as there is no need to have a tabular data structure behind a JSON form. The need for a QGIS forms to be on a tabular data structure greatly limits there ability to be altered on the fly.

I think the big need is to be able to have form support for one-many relationships. QGIS has this but it is somehow back-to-front. I would create a parent, then create a lot of dependent children. From memory, in QGIS the child records are created first, then attached to a parent. The way it is done is very unintuitive to me. The common use case for one-many relationship is for vegetation plots. The plot data is the parent record, and the species in the plot are the child records. These are the approaches that companies I have worked with have used to address this issue:

• Trimble terraflex the plot data and use paper to collect the species list (later entered into a spreadsheet)
• Use Esri FieldMaps to collect plot data and then use a link to launch Survey123 to enter the species list
• Use a panasonic toughbook with a full copy of ms-excel to capture both the plot data and the species list.
  I should raise this as a separate request. All the solutions I have tried are clunky.

[moovida]

Ok, let's keep this discussion going (even if probably a few issues or the mailinglist would be necessary :-)

First, the fullscreen. Since yesterday I had to tweak something in the libs, I gave it a go to try the no bars version. I made it the as-simple-as-possible way, so the result is not ideal. But it might be better then now?

What do you think about this?

It would be necessary to rethink the icons though. I assume only making them round floating buttons would not be enough, right? What is your thought about this @AndrewM- ?

[AndrewM-]

I think that the full screen is a step in the right direction. The top bar is more intrusive than the bottom bar in Smash. I have attached some screenshots taken on my iPhone XR. Just a comment, I was recently working for a company that used both iPhones (13) and 10 inch Android pads in a protective case. Out of the ten people working there, nobody used the Android pads. The form factor was too big. I persevered for a bit with the pad, as my previous experience was that iPhones both drained the battery in about half a field day and over heated, sending the screen black. The newer iPhones do not seem to have those issues, which is probably why people have stopped using the pads and are using iPhones exclusively. Another reason might be that newer iPhones can redraw the display much faster. This is an issue when vector GIS layers such as contour lines are used, as these draw slowly and it can look like the pad has 'hanged'.

Note that Qfield is also not showing Open Street Maps as finely as Smash. I am of two minds. I can't read street names on the iPhone in Smash as they are too small, however I can see more area, which is good.

[moovida]

I made a couple of reviews and I think we are getting there. Moved the zooms at the side as in QField.
Then the layers to the left, gps to the right, and the survey tools in the middle. I quite like it like that. I also harmonized the icon coloring.

With gps logging:

Editing tools, now activable from the right drawer also:

And if you remove unsused tools from the settings, it empties even more:

Comments welcome.

[moovida]

Let me also try to address this (though it will make discussions hard to follow on this thread):

I think the big need is to be able to have form support for one-many relationships. QGIS has this but it is somehow back-to-front. I would create a parent, then create a lot of dependent children. From memory, in QGIS the child records are created first, then attached to a parent. The way it is done is very unintuitive to me. The common use case for one-many relationship is for vegetation plots. The plot data is the parent record, and the species in the plot are the child records.

I probably am not getting that right, but just to be sure: doesn't this get solved with connected combos?
Or does that miss one level? Can you elaborate?

[AndrewM-]

The new screenshots look good.

I never got the purpose of the connected combos and have never used them. I don't think that connected combos would do the trick either as child records can have several database fields. For example (Parent: plot id, plot length, plot compass direction, etc) and (Child: Plot id [hidden], Plant name, plant coverage, plant abundance, specimen collected [checkbox]). That is part of the NSW Biodiversity Assessment Method, so is prescriptive.