Birdtrack: handling of spatial information

[kitenetter]

Changes to be made to the handling of output grid references:

1. For all records arriving from Birdtrack with lat/long point locations an output grid ref will be assigned that is the 1 km square containing the point; any associated uncertainty measure will be provided in the Occurrence comment (see table below).
2. For all records arriving from Birdtrack with a grid ref, the grid ref will be copied to the output grid ref, without any transformation based on uncertainty values (see table below).
3. The “input spatial reference” data should be displayed as a location attribute in the record details pane on the verification page, alongside the current “Grid ref” (which is the output grid ref).
4. The changes to the handling of grid refs will be applied to all Birdtrack records, retrospectively as well as going forwards. Where retrospective changes are made, the verification status will be reset to “Pending” where these conditions apply:
   • Output_map_reference recalculates to a more precise value; OR
   • Output_map_reference recalculates to a value of the same precision AND Status is “Not Accepted”; OR
   • Output_map_reference recalculates to a less precise value; OR
   • existing status is Plausible

See issue #1598 for changes to mapped records.

@DavidHepper

[johnvanbreda]

I've had a look at the existing data that we've imported so far. Note that ALL of the records have been imported with a GPS lat long as the input spatial reference (the optional gridReference import field has never been used). Around 80% of the records have a coordinate imprecision value and a similar percentage have a site grid reference in a custom attribute (this is not the same as the record being located at that site grid reference - there is always a separate point for the record).

A few questions:

1. Where we have a site grid ref (the majority) I am assuming the 3rd row in the table above indicates that we should use this BTO assigned grid reference for the output grid ref. However, I can see from the data and API results that the site grid ref is often a 10km grid square. In these cases would it be better to create a 1km grid square for output (i.e. only use the site grid ref if 1km or better?).
2. Should the new rules apply to all BirdTrack records, or only Odonata as before?
3. Should we re-run the previous imports so that records that were skipped under the old rules are no-longer skipped?
4. Where we are forcing the output grid reference display label to a different value than Indicia would normally use, presumably it's OK for the stored geometry data to still reflect the GPS lat long coordinate + imprecision value (the output ref will also be displayed when viewing the record as per #1598)?

[johnvanbreda]

@kitenetter tagging you in case you missed this, as David mentioned it was a high priority issue at the BRC meeting.

[DavidHepper]

John, here are my answers to your questions above:

1. Yes, only use the site grid ref if 1 km or better.
2. Refer to @kitenetter .
3. Large numbers of records have been imported and are languishing, unverified, pending recomputation of an acceptable output map ref. Therefore I suggest not trying to rescue dropped records (which might be hard and is unlikely to add much to the occupancy data) but only recomputing those previously imported (and, or course, all received in the future). This process should ignore the verification status: where a new, more precise, output map ref is computed it should change the record status back to Pending.
4. The principle is that the verifier (and later the retriever) should be shown a clearly a representation of the output map ref that should be approved and that will ultimately go to NBN Atlas as the best geolocation, not a pinpoint and radius that is then thrown away. Does that answer this question?

[DavidHepper]

@kitenetter , @DavidRoy Another 10 weeks have passed. There are now 22,000 unverified Odonata records from BirdTrack clogging up the system, around 80% of which have only 10 km output grid references after the full uncertainty is applied. I really would prefer not to ask you to delete all BirdTrack Odonata imports, cancel the direct imports and go back to letting BTO send unverified records to dilute the quality of NBN Atlas but this issue is now over two years old and this particular ticket documents a course of action agreed six months ago. Is there anything more I can do to escalate?

[sacrevert]

Regarding (2) above @johnvanbreda , my preference is for these changes to not be applied to any plant data at this point. Some vc plant recorders have rejected some 10 km records, but equally do not want records assigned to 1 km sites that they were not necessarily recorded in.