I'm really surprised not to find this as a feature request on the forum - so maybe it has been shot down in flames a long time ago... Apologies to all those who sigh at this naive suggestion...
What is the general goal of the feature?
To plot previously collected data as an overlay on a map (an adapted geopoint widget?) with two potential options:
View the existing data as markers (e.g. with balloons for related attribute data) to see how the current position relates to these data points and allow a new point to be recorded
select an existing item and store one of the values (e.g. 'ID') as a variable for use within the form
This could be used to display other geopoints collected on the same form (e.g. with repeat groups) or using a csv file that has coordinates in columns
What are some example use cases for this feature?
I think this would be useful for any repeat survey where the data collector wants to see whether they are in the right place or make sure that they are not collecting duplicate data.
With option 2 it would be a great way of selecting the previous data point instead of a 'select_one' that has to describe the previously collected data. If the data point has a KEY value it could be combined with pulldata() functions to populate other fields in the repeat...
This would integrate data collection with spatial data so that things can be done on a single app (rather than, for example, swapping between apps to look at previous data) - this is what I do, and it looks like others have been doing it too e.g. WAStD mentioned by @Florian_May
I am not seeking to be able to prevent duplication by different collectors, which I recognise to be a different ball-game altogether.
What can you contribute to making this feature a reality?
I am well known for breaking things, so I'd be happy to keep trying to break this feature during the testing phase if it was taken on
ODK Collect operator needs to navigate back to a point collected earlier
on same device,
on other device, already uploaded,
on other device, not yet uploaded because we're sitting on a remote island on Western Australia's northern coast way out of mobile reception
This problem seems like it will be addressed by ODK 2 / ODK Survey / two-way server communication to ODK sync-endpoint, but I haven't yet read up enough.
Our current solution is to publish ODK Aggregate to Google Fusion Tables, style them up a bit, and share the link with those who need to see previous data in real-time. The ingest into our data warehouse (WAStD) and following reporting via RMarkdown workbooks (shared through a combination of CKAN and Google Drive) decouples data collection from "re-visiting" use cases, but is not as close to real-time as GFT.
So, the hard question is: Do we need to upgrade ODK Collect, or will ODK 2 solve the problem?
I've had a look at ODK 2 but as far as I went it appeared that I would need a whole new way of looking at the world, and much better control of the data collectors' phones (multiple apps to install and set up). That doesn't work with the kind of resources I've got or the folk who are collecting data with me, some of whom can barely understand the concept of smart phones (although they are experts in their own fields). Not to mention a programming environment to learn - it would be exciting if it were my day-job, but ODK is a means to an end for me (no disrespect to all the proper developers!).
I suspect a lot of current ODK users / developers might be in a similar position - and the data requirements of ODK 2 probably have cost implications for Google Appspot installations of Aggregate.
Your set up sounds impressive, especially looking at real-time type stuff. My idea of remote is Scottish Mountains - no reception there either, but we're not so time critical as for your data. I'm looking at monthly or less frequent updates and I reckon that there might be a need to visit 'civilisation' in between so the duplication can probably be avoided over a cup of tea, or a dram.
@seewhy I want to make sure that you are aware of the existing offline map feature described in the documentation. Currently, only raster mbtiles are supported so only your first suggestion is supported and somewhat imperfectly. You'd build a layer based on your previous data collection efforts and then put that on the devices. You can use PNG tiles with transparency to allow a basemap of your choice to show through.
Geo: Using the Mapbox SDK for Android is a first step towards selecting features from a layer so you may want to check that thread out. It's more broadly about adding support for vector layers, the Mapbox library is just a suggestion of how that would happen. In particular, if you have feedback on what format you would like to define your layers in, that would be really useful.
