Hi @tomsmyth,
We are now generalizing the definition of sample places on the natural sites we manage in the long term (sometimes for the next 30 years for sites we do not own). Those places will be followed over the years or decades, in order to evaluate our conservation actions and improve it. It is that context that we are interested in "longitudinal data collection".
Our "need" is I think less complicated than for other thematics with big samples of people to follow.
In term of usage I imagine we could first compare the data we are collecting at the moment to the previous one :
- The most explicit example I have in mind is the one I exposed to Adam last year : Longitudinal data collection user stories - #4 by mathieubossaert : what were the species we inventory last time, in order to create a first list to check... what was the extend of this habitat on the ground (from a geo point of view).
- what was the coverage of the plant in this sample
- Another one concerns farmers who self evaluate their practices regarding water quality and biodiversity conservation. What was the value of the collected indicators on the same parcell one year ago.
As a "do-it-yourselfer" (in fact I am better blacksmith than woodworker but I really enjoy by the collaborative carpentry project so I also make some wood things....) I did imagine in the past to generate media csv files to upload to Collect from Aggregate's PostgreSQL database with cron tasks, then synchronize media files on the phone using sync tools.
External data functions would help to interact with those references values.
I plan to test such a first step this autumn to alert colleagues about salt marshes water level managment. The planned value varies every week or month and is define in the managment plan. The technicians want to be aware of the planned water level and to be alerted when the observed water level is not conform. They also want to know what was the water level at the same place last time to detect a possible problem.
The easy thing in that case is that the list of places already exists and do not evolve as the field sessions are done, so I can identify in a permanent way the followed entities.
I can "easily" imagine it for such a limited, non generic need.
As an "end-user" I also easily imagine application of longitudinal data collection capabilities combined to geo capabilities. And how it could help my colleagues in their field mission...
But I do confess it is harder for me to imagine a way to generalize it for more complex use cases, keeping things as simple as possible.
How to clearly identify followed entities and for each one, the previously input values for its different properties ? How to organize the data ? How to propagate it over the phones fleet ?
I understand and share your worry about how to keep ODK simple and in the same time make it evolve to allow more complex workflows.