We have just noticed what appears to be a very serious bug in the NBN exporter add in.

Having sent in our latest submission recently, Lynne Healy returned a short list of records from one of the datasets for which the grid reference precision value did not match the actual precision of the grid reference. Close  inspection revealed that the grid reference as exported included spaces so instead of SU2456 it had SU 24 56. This is not in itself a problem with the addin, rather some of our data has invalid dates which Recorder has somehow allowed and revalidation has never identified. As it happens the records were all historic data imported in bulk from our old Recorder 3.3. It would appear that Rec6 validation was not working very well when this data went in. That again is not the bug though.

I have not checked all the faulty records yet, but one in particular drew my attention when I inspected it in recorder because the sample spatial reference was in fact correct, but the survey event spatial reference had spaces in. There is the bug. It would appear that the NBN exporter has taken the grid reference for the record from survey event not sample. Now the sample spatial reference must always be the occurrence spatial reference (by definition) but there is no reason why survey event and sample should have the same grid reference of necessity.

It seems likely then (unless I am missing something) that the exporter always takes the survey event grid reference to use as occurrence grid reference. In most cases this will make no difference, but in many (potentially thousands) of instances the data being submitted to the gateway may have incorrect spatial references. Anyone who puts data on the gateway (via the exporter addin)  where there are multiple samples within an event should probably check whether this affects them.

During the same process Lynne also identified a small number of records (again imported from Rec3.3) where the value in vague date start was in fact larger than that in vague date end. Recorder 6 reports these dates (possibly correctly, but equally possibly incorrectly) without noticing the error. I guess this means that there is an assumption in the coding that this will never occur. In addition revalidating the data has never identified that these records were problematic. So there is also a bug in the validation routines because they clearly do not check that vague date start, vague date end and vague date type are consistent.

An example of this is a record which R6 reports as having the date "Winter 1996", where VDS is 01/12/1996, VDE is 28/02/1996 and VDT is "P" (=season). Apart from highlighting the error and the bug this also begs the question what exactly is meant by Winter 1996? Is is winter 1995-6, or winter 1996-7. My inclination is to assume the former, since most of that winter is in 1996, but what does Recorder assume?