Clarify to users how locations are handled when recording surveys

[kitenetter]

It appears that we somewhere between 3,000 and 6,000 app records that are mislocated, due to users not realising how the app deals with geolocations for individual records that are part of a survey. The most likely cause of this stems from users setting up a survey when out in the field, and then continuing to add further records when they have moved away from the survey area (e.g. upon returning home).

We need to make it clearer to users how the app is behaving when adding records to a survey. Suggestions:

1. Ensure that the default setting is for individual records not to be geolocated, i.e. the default position is that they all get linked to the location set up for the survey
2. Add an information box to the survey data entry page so that users are told something like "All records added to this survey will be assigned to the location that you have set up for the survey. If you want to assign precise locations to records within the survey, make sure that you switch on the option to "Geolocate survey entries". [Ideally users should be able to do this from the page itself, without having to go to the app settings.]
3. If the option to "Geolocate survey entries" has been switched on, the survey page should inform users "All records added to this survey will be given individual locations, e.g. based on the current GPS location for your device. If you want to add records after you have moved away from the survey area (e.g. after returning home) please switch off the option to "Geolocate survey entries".

Other possibilities we could consider: enabling some sort of calculated warning so that if a user is more than, say, 1 or 2 kms from their survey location they get a warning? Not sure how feasible that is.

Enable a map display so that users can see all the records from an individual survey before they upload them?

Other ideas welcome!

[kazlauskis]

Thanks, this could be clearer to the user, and I can do all those options. It would be easy for me to switch off the individual records geolocation default setting.

These misplaced 3-6k records are around 4-8% of the total survey uploads, and the remaining 92% of occurrences have accurate locations. It might be more beneficial to continue capturing precise individual record locations and address the problem of recording from home instead. So I particularly like your last two suggestions - detecting the distances and showing occurrences on the map. We do similar things in other apps: for the iRecord Butterflies app, we show warnings for out-of-UK records; for the ButterflyCount, a warning if the user records a very long walked distance during 15min counts. It would be easy to detect a large distance between the parent sample location and an occurrence and show a warning. Also, we could show all the occurrences on the parent sample map (we do this for the ButterflyCount app). It might be helpful to add this functionality to the map anyway because showing all occurrences of a survey would indicate if any are outside the parent grid square (i.e. monad) if users want to do grid recording.

[kazlauskis]

@kitenetter I have now done the calculated warning for species entries that are over 5km away from the survey location and also added species entries to the survey map. Does that look OK? Do you think this will be enough to clarify how the child sub-samples are located, or should I also implement your 1st suggestion - switch off GPS locations for list entries by default?

[kitenetter]

Hi @kazlauskis this issue has come up again, and apologies for not having responded to your comments above. The changes you've made are very welcome, but I don't think they go far enough.

The warning message about distant locations (screenshot below) is fine, but is easy to miss - I think it needs to be larger and/or outlined in red or something so that users cannot miss it before they upload their records. We really do need to prevent the mislocation errors before they get uploaded.

The distance of 5 km for the warning seems too large to me. I think there is an argument for setting the warning so that it appears for any record that is outside the square chosen for the main survey, but if that seems too restrictive then I would suggest a warning for anything that is over 1 km from the main location.

The display of the individual records as green dots on the map is also helpful but also easy to overlook. If I look at the map for the survey as a whole it zooms in on the survey grid ref and I cannot see any outlying records unless I zoom out. And if if I look at the map for an outlying record it zooms to that record so it is not very obvious how far the record is from the main survey location.

So I think we do need to turn off the individual record geolocation by default. Ideally it would be good to have a link on the survey data entry page that would enable the individual geolocation to be turned back on from within that page, instead of having to come out and go in to the settings to find it.

[japonicus]

Is it possible to estimate what proportion of the errors are due to people straying outside the survey bounds while surveying in the field v's spuriously GPS'ed entries added later at home?

Individual precise locations for each occurrence are valuable and are one of the major strengths of app-based recording, at least for taxon groups with fixed locations such as plants and fungi - perhaps less so for animals.

If many of the errors are due to straying in the field, then turning off GPS merely hides the problem and results in incorrectly located records that are difficult to detect later.

An alternative might be to make GPS tracking easy to toggle and to stop tracking following an unexpectedly large temporal/spatial jump between records - e.g. when someone drives home. (the prototype BSBI recording app turns off tracking if someone moves too quickly - because we anticipate that surveys are conducted on foot)

[kitenetter]

Thanks @japonicus

The serious errors that have been identified appear to relate to people adding data when at home or from widely differing localities. I take your point about the value of precise locations within a survey, and that we don't want to lose that functionality. But at the moment we are getting records verified in entirely the wrong locations.

Perhaps if we can make the warning message clearer we won't need to turn off the default geolocation.

We do need to enable people to add records to a field survey after they have returned home, so making it easier for the user to be aware of the geolocation setting and turn it off when required is definitely desirable.

[kazlauskis]

@kitenetter, would these changes help?

• [ ] Reduce 5km to 1km. The sub-sample distance is calculated from the parent survey location.
• [ ] Make the warning message stand out.
• [ ] Add a survey warning symbol to the pending surveys list page. This would make such records stand out from other pending records before upload.

Pending records in the app have two states, "Draft" and "Finished". Both can be modified before upload, so what if we turn off the automatic GPS for finished records? Essentially, users would compile their species lists in the field, press the Finish button in the header and then come back home, where they can add more species assigned to the survey location before the upload.

[kitenetter]

@kazlauskis I think your first two suggestions are definitely worth doing. I'm not sure I understand the third one - would the warning symbol be shown against all surveys, or just surveys that include some records more than 1 km from the parent location? But in any case I think it is worth trying.

I don't have any feel for whether recorders recognise the distinction between the "Draft" and "Finished" stages of a survey, so I'm not sure how well these states match to "in the field" and "back at home". I can see that turning off the auto GPS for finished surveys might be helpful, but it will depend on recorder behaviour. If it can be done in such a way that the recorder is clearly informed of what is happening, and can easily see how to switch the GPS back on if they need to, it might be worth trying but without some testing it's hard to predict whether recorders will find it helpful.

So I agree that we should implement your three tick-box options, and on balance I think we should try implementing the auto switch-off for "Finished" surveys, although it needs to be kept under review.

[kitenetter]

@kazlauskis I've just had another example of a user who is very upset that their records are located in the 'wrong place', due to having done data entry at home after starting a survey in the field. But in this case their field site is less than a kilometre from their home site. The difference in distance is not great, but the result is that records are being located in their garden when they intended them to be from a nearby natural habitat.

So although the measures we've discussed above are helpful, they wouldn't resolve things for this type of example. I think we really need to find a way of making it very obvious to the user, at the point of them entering an individual occurrence, whether or not it is being auto-located, and where the auto-location is in relation to the survey.

Whenever the user has the GPS switched on and is adding records to a survey, can we provide a clear warning to each individual record being added that says "This record is being added at your current GPS location - please edit the location if you have moved away from your survey area".

[kitenetter]

I also think that when someone starts a new survey on the app that we need to give them a very clear message about whether or not the GPS auto-location is switched on, with a reminder that records added after moving away will need a manual grid ref adding, and ideally give them the option of switching the GPS on or off at the point of data entry.

[kitenetter]

Apologies @kazlauskis - having done some more investigation it appears that the user mentioned in my previous two comments was NOT using the survey option, they were adding individual records, They were getting confused over the auto-location and user-specified location controls, and also over the field locking options.

It is of course possible that other users may be using the surveys and ending up with records that are near the survey location but not actually located correctly. And I still think it would be helpful for users to be given clearer information about whether their records are being auto-located or not at the point of data entry, if we can find a way of doing that.

[kazlauskis]

I agree, we can clarify how this works. I just don't want to affect the majority of the users if they don't have this problem. Most similar apps (like iNaturalist, iObs, eBird) will automatically geolocate users' records and will only show the resulting lat/long at the survey level without any warnings. The main reason is that these apps are designed for entering records in the field and most people will use a computer to enter records at home. Having said that, users can use the iRecord App at home a) for individual records they can lock their location to whatever place and the GPS won't be used b) for species list entries there is the app setting to disable the GPS for species and only use the survey location c) they can switch off the device location services to disable the GPS altogether. I suggest we add a help text section to the Help page to explain how the geolocation works.

Also, what if we also show a little location preview, something like this?

[mikeprince]

Sorry for being late to comment here, but I'm one of the people who raised this issue. I think you need to recognise that there are various use cases. The one of a recorder entering a species list after the event, e.g. when they return home, or at lunch, or in the car when it stops raining etc, is common. The value of precise individual located records for a survey list depends on the taxa as well as the type of survey, e.g. somewhat structured or completely casual. Of course, the consequence of mislocating records is significant: it's very easy for a verifier to miss, and I've no idea how difficult it is for you to batch correct incorrect records after the event.

I personally don't see the need for anything particularly clever, like showing a preview map of the location. I think a reminder when a user starts a species list survey if they have geolocation of individual records on would suffice, e.g. "Species records will be given a precise location based on your current GPS location. If you would rather just use the overall location of the survey, please click here/toggle/go to settings [whatever works best here!]". To avoid a reminder every time, there doesn't need to be a similar reminder if geolocation of individual records is off: this option is less "dangerous" as records will not be given incorrect locations, just ones that are less precise than they could be (which is often fine).

The comment that most similar apps geolocate individual records is not correct: eBird for one does not do this.

[sacrevert]

If this can be toggled by survey, I would prefer Martin's option 1 for the Plant Survey option, that is, that the record level geolocation defaults to off (in addition to warning messages etc.) Of course I agree that very precise records are useful, but this is less true for common plants, and I think the errors and user dissatisfaction outweighs the nicety of being able to say everything is located to GPS precision tbh.

[japonicus]

Could the problem be solved by disabling automatic GPS location assignment for records that are more than 1 or 2 km outside the survey area, and also displaying very prominent warnings on any record that has been GPS located within the out-of-survey buffer zone? Those mislocate records are important to flag anyway as it's very easy to set a defined survey area then accidently wander outside of it.

A more sophisticated option might be for the app to warn if GPS was on and the user was entering a series of records, but appeared to be excessively stationary (i.e. likely sitting at home or in the field but transcribing a paper list). This approach would work also for casual recording where a survey area had not been set.

I'd really like to ensure that GPS is on and used wherever possible. In a plant context, precise locations are critical for either rare or perniciously invasive plants, but I think will become more important even for common species. As app usage increases (and probably becomes the norm for much survey work) then precise geolocation of all records might allow for far more sophisticated estimation of survey effort and coverage; allow for tracking repeated survey routes (something that BSBI is beginning to consider); and, more generally, boost the credibility of records from unknown recorders. For less experienced (or non-local) recorders even understanding which taxa are of notable interest is not always obvious - so precisely locating every is a very useful practice.

[sacrevert]

Perhaps the simplest option is just to do what is already mentioned a few times above: just put the geolocate option on the front page of every survey (in addition to whatever warnings are deemed appropriate across or within survey types).

I think the other warnings will always lead to some errors remaining, as it won't be that unusual to have a lunch/dinner near to the survey site whereupon records are entered (I did this last Friday, which is what alerted me to this existing issue). And presumably tracking whether people are stationary is very variably efficient too (often the first however many minutes of grid square or site plant survey are spent near-stationary ticking off all the common taxa one can see without moving).