Survey/ Trip / Env ID need to be auto-generated / populated on related forms

[ClaireLush]

If this is not possible, then trip / env id will need to be removed from the observations form

[ClaireLush]

How long would there normally be between setting up the survey and entering the trip details? QField does not create the track feature immediately, it has to add the first point before it saves.

[ClaireLush]

Test whether altering the layer to multipoint generates the survey id immediately

[MikeLush]

Claire has answered the questions we had about route tracking and is currently implementing the only solution available.

Sadly a multipoint layer does not help, as QField logs a new point feature regardless of whether the layer is point or multipoint. Claire is therefore using a point layer and a combination of device ID, date and route name (including direction?) to provide a unique survey ID that is shared by all points in the route layer. i.e. all points automatically added to the layer when route tracking is on will share this ID. The route name will need to be entered by the volunteer and will be mandatory, as without it we can't populate all associated records with the survey ID. Points can be strung together to make a line afterwards if required, based on shared survey ID (possibly ignoring the device ID part) and ordered using the fid (a unique sequential ID for each point).

This is based on the assumption that different route codes will be used for the same trip but in different directions (outbound/return). Please let us know if this won't work, but note that we will otherwise need to add the direction to the route ID, which will make it longer.

[MikeLush]

@Emmawilsonjncc @rking90 Claire's sunk a lot of time into trying to get the solution proposed above to work, but it just won't work. For whatever reason, no matter how it's configured, QField won't create the unique ID as proposed, which means it's impossible to link on this. We think this is a fault in QField, as the configuration works perfectly in QGIS.

We're therefore drawing a line under this, as we're not convinced it's ever going to work and could suck up even more time if we keep trying.

We've decided to implement a different solution. The survey will be defined by a start point (and maybe with an end point if this is helpful). Tracking will not be used, as we have issues if a line is used (it won't create the survey ID until there are two vertices, which introduces a delay) or points (each point is given a different ID, which then can't be used as a unique survey ID). We will use a GUID to define the survey ID, associated with the survey start point, that should (hopefully) be linked to from all child trip, environment and observation records.

We might be able to have a separate track layer that references the survey ID, but nothing to date has suggested that this is essential. For the time being we're not going to try, but it could be raised as a separate issue if required.

[Emmawilsonjncc]

@ClaireLush I think the 'survey' form (sorry, I'm not good with the technical terminology such a GUID...) works well. Could I suggest a few minor cosmetic fixes to this form:

• Change name of form from 'survey' to 'Start/Stop Survey' to make it clear to the user what this form is for
• Remove any '_' from fields within this form
• Can we add in brackets next to ‘survey route’ the required format users should follow? This would look something like (e.g. Ardrossan_Brodick)

[Emmawilsonjncc]

@ClaireLush Is this the best place to raise the issue of 'fid' fields being present at the top of the observation and env conditions form? What are these for and is the user supposed to see them?