Precision and location type

[japonicus]

Although the warehouse has a core 'precision' attribute for locations, this isn't always used consistently and isn't applied to square-based grid-references. I think the issue is becoming increasingly important due to the prevalence of GPS based recording. There are also longstanding problems with recorders using square grid-references to refer to less precise centroid points. It would be useful to support precision and reference type consistently in the warehouse and on iRecord.

Currently I think that there is no way to indicate whether a locality specified as grid-reference describes a precise square or a centroid. I'd like there to be a separate attribute for this (rather than conflating with the separate concept of spatial reference system).

I think that it should be possible to specify e.g. an eight or ten-figure OS grid-reference and indicate that this is describes a centroid rather than a square. This should influence the way that the location is mapped in iRecord (as a square or as a circle) and also be reflected in textual form, e.g.

'55.592N, 3.184W ± 8m' or 'NT2613273851 ± 8m'

whereas 'NT26137385' refers exactly to the bounds of a 10m square.

This also ties in with discussion about grid-reference display (e.g. https://github.com/BiologicalRecordsCentre/iRecord/issues/213 ) because it ought to be possible to display an OS grid-reference instead of a lat/lng while still indicating that a centroid is intended.

136 covers the case where several reports on the warehouse substitute an arbitrary precision (100m) for lat/lng based localities rather than making use of the precision attribute.

To encourage users to properly take account of the precision of GPS readings, we ought to make it easy for precision to be recorded properly and to make as clear as possible that a centre point without a precision value is unsatisfactory.

Unfortunately it's also not uncommon for users to provide a 100m grid-reference that actually refers to a less precise centroid site.

In practice, I doubt that casual users of iRecord will often fill in precision on a general purpose recording form, but the option should be available. GPS'ed records from mobile apps should always provide precision and this information should be reflected in the detailed and summary reports of records.

[johnvanbreda]

I think there are potentially 2 new fields to add to the forms for data entry of a spatial reference:

• Precision (numeric). This is already used by the app to store GPS precision but it could also be needed for data entered online. It could apply equally to point and square based references though is more common for the former.
• Qualifier - a drop down with options such as "Centroid of survey area" and "Precise square surveyed". This probably needs @kitenetter to confirm and set priority level.

[japonicus]

https://github.com/BiologicalRecordsCentre/BSBI-Card-and-PlantPortal/issues/86 relates to the display of centroid precisions on maps.

https://github.com/NERC-CEH/irecord-app/issues/154 suggests that GPS derived locations should be stored as precise gridref centroids with a precision. If implemented that might substantially increase the proportion of centroid data with meaningful error radii - so the presentational issues with map and data table display of centroids may become increasingly important.

[kitenetter]

For precision I think we definitely should store that information where it has been generated by the app. Grid references already contain intrinsic precision information, assuming that the recorder has chosen the most appropriate grid ref for the type of recording they are doing.

So a qualifier giving information about how a recorder intends their chosen grid reference to be interpreted would in theory be useful, but I'm very wary of adding it to our standard recording forms. Partly for the usual reason that every time we add complexity to the standard forms we are potentially also adding barriers to participation, and partly because I think it is difficult to provide an explanation of how such a qualifier should be used that will be understandable by and relevant to a large proportion of recorders.

To me, the qualifier concept is something that should be used for particular recording projects where recorders are provided with guidance on how they should use it, and where the people using the data have a need to distinguish how the grid refs have been used. Personally I think it would be very difficult to implement it for the standard forms - the risks are that we would add complexity, that we are asking recorders to spend time completing an additional attribute that might not be needed by the people using the data, and that we might replace the current ambiguity associated with grid refs with an ambiguity associated with how recorders interpret the qualifier.

@japonicus let me know if I'm missing anything here - what difficulties does the lack of a grid reference qualifier cause for you?

[japonicus]

I think that the concepts of georeference type (gridsquare or centroid) and precision are useful and ought to be standardised as core fields (rather than as optional attributes) but that this detail doesn't need to be exposed to the end user in all cases.

For the general purpose data entry form if someone types in a low precision grid-reference then their intent is usually clear (a square, with the precision defined by the square dimension).

It's problematic if someone manually types-in an 8 or 10-figure ref from a hand-held GPS. That may be the reading they took when they started walking (i.e. actually a centroid with a 2km radius) or a far more accurate reading taken at the site of the occurrence. {there is still widespread misunderstanding about this - I regularly receive recent records from experienced recorders who have given no thought to what precision ought to apply to their 8-fig gridrefs}

It shouldn't be permissible to enter lat/lng refs without a precision - doing so turns interpretation of the location into guess-work.

My preferred format for the general purpose form would be:

(replacing the unnecessary co-ordinate system menu with a square/centroid choice)

If a user explicitly picks 'centroid' or enters a lat/lng then I'd display an otherwise hidden precision menu.

For the most common use-case (a grid-square) this adds no complexity.

I think that precision needs to be a core attribute rather than the current situation where gps-precision recorded by the app is ignored in many circumstances (e.g. as far as I can tell get_sref_precision() doesn't use it, so the app's gps precision is not exposed in exported result sets.)

[kitenetter]

@japonicus in your final screenshot-type example above, is the scenario this: a recorder has gone to a location, used a GPS to get a 1-metre grid ref, and has then typed in that 1-metre grid ref to iRecord? And if so, is the "32m" precision a measurement taken from the GPS?

I suppose the question I'm asking is what is meant by "centroid" in this context? Is it always associated with GPS data, or are you also including the case when someone specifies a 10m or 100m square that is in the centre of a larger site of habitat patch?

And I wonder how often that scenario occurs? My perception is that (if using the website) most people click on the map to set a grid ref, but presumably you are seeing significant numbers of records with grid refs or lat/long coords manually typed in?

[japonicus]

I was using centroid in quite a broad sense, so it could in principle be a 100m ref specified but actually a larger site intended (though that's not a sensible thing to do).

The 32m example would probably represent an error value read from a gps.

I don't know how widespread use/misuse of centroids is with iRecord data. More generally with data BSBI receives the largest problem is with the use of 'site centroids' where the radius is unspecified but can be anything from 100m to 10km - I would guess that that is less likely to be an issue with casual iRecord records.

I should think that entering precise grid-refs from GPS devices might be relatively common on iRecord and that these records may often be specified too precisely.

For 'map clicks' the design of the map selection hopefully guides people to picking an appropriate size square. In that case, explicitly specifying precision shouldn't impinge - the selection would be a square and the precision field would be hidden. (a purist might argue that map-clicks ought to generate centroids, but that might be counter-productive)

One case where the current user interface encourages over-precision is the gps button on the form. If I was near the survey site with my computer (e.g. at home and noting an occurrence in the garden) then it could be very tempting to click the button, have an over-precise 8-fig square ref auto-filled which doesn't actually directly correspond to the site - that would be a case where providing a centroid would be more correct.

I think it would be good to have as much commonality as possible when editing records entered using the general purpose web form and records entered using an app. The app records should definitely retain precision and expose that to the user when they view or edit the record online and, to me, it follows that the general purpose record form ought to have equivalent options and user-interface.

Getting the balance right between complexity and 'correctness' is fraught - the whole precision issue is possibly much more relevant to surveys of static occurrences (e.g. plants) than it is to e.g. insects or birds.

[japonicus]

A further simplification for common use would be to hide the square/centroid option altogether if the reference entered is less precise than 10m.

[sacrevert]

@kitenetter @johnvanbreda Any idea what the status of this is? Perhaps it has been dealt with elsewhere? If not, how are we prioritising it?