Open kitenetter opened 4 years ago
DavidHepper
commented
4 years ago Please, please treat this issue with exceptional care. Although I'm personally relaxed about the side of a river on which a flying insect is seen, some of my verifiers get particularly twitchy about the subject. The introduction of ES Verify and previous tweaks to the handling of "boundary straddlers" have caused problems in the past, as documented in issues #157, #490 and #679.
kitenetter
commented
4 years ago @DavidHepper good point. What I'm proposing will not affect how iRecord currently handles the automatic assigning of records to VCs, but will add extra options for verifiers as to how those records get viewed in future. At the moment the pressure I'm getting is from verifiers who are very keen to be able to remove records from their grid that they do not believe are part of their vice-county. But I can imagine that in some cases there could be two verifers each wishing to 'claim' a record for their own VC, or alternatively some verifiers that prefer to see 'boundary straddlers' remaining linked to multiple VCs so that they can be taken into account on both sides of the border.
So I think the mechanism needs to allow verifiers to choose from a number of options for a particular record (or sample (or set of samples?)):
Option 3 is the current default state, and no action need be taken for the record to remain in that state.
Option 2 is what has been requested. The choice of VCs that records can be assigned to should be limited to those that overlap the grid reference.
The question is whether we need option 1 as well. The benefit is that it would allow county recorders to reduce the number of records in the system that have potentially confusing multiple VC links, and make the data easier to analyse follwing download. The downside is the potential for verifiers to be seen as claiming records for their own county when there is dispute over which county was actually meant, or where it is impossible to know which side of the border a flying insect actually was.
Views welcome!
kitenetter
commented
2 years ago Related to this issue (which targets verifiers) is whether we can implement a mechanism for the original recorder to specify the correct vice-county for records that overlap boundaries. This was discussed in #202 (now closed) and needs to be taken into account here.
We've discussed this issue before, e.g. #485, and it has been raised again. Vice-county-based verifiers are presented with all records whose grid refs overlap the VC, even by a small amount. Sometimes the county recorders know which is the correct county (e.g. from the location name, or from correspondence with the recorder), and they are sometimes faced with large numbers of records that get allocated to their county verification view but are known not to be from their county.
This causes problems:
Can we develop a mechanism for verifiers to be able to assign a record to one vice-county when it overlaps more than one boundary?
Does the vascular plant grid form https://www.brc.ac.uk/irecord/enter-vascular-plants (which allows recorders to specify a vice-county for overlapping grid refs) provide a model that could be adapted?
Once specified, the record should then be assigned to that vice-county, and no longer linked to multiple VCs, e.g. in downloads.
I've referred to vice-counties here, which is the issue that has been raised by verifiers, but there are a smaller number of verifiers who work on modern county or other boundaries, and in principle a similar issue could apply there. So this could grow to become a cumbersome problem to tackle, but sorting out vice-counties in the first instance would be a good step forward.