Check target/ra/dec values in raw headers for entire scan

[mattlebofsky]

Something that comes up from time to time is that rawspec picks the very first target name and ra and dec from the first data block and assumes that's gospel, when in fact there may be a reporting delay such that the first data block contains old values (i.e. from the previous target) and the real values don't appear in the raw data header blocks until N seconds into the scan.

I don't know what the algorithm would be for trusting which values are correct, but it would be nice if rawspec would simply fail out if the target/ra/dec changes in the raw headers during the course of a scan. Of course there may be tiny tiny changes in ra/dec normally so don't worry about those. But if the target name changes at all, or the ra/dec changes more than a beam width, rawspec should fail without doing anything.

[radonnachie]

Not to sound too idealistic, but isn't the preferable solution to mitigate the reporting delay?

Wouldn't rawspec failing on a change mean that you wouldn't be able to process the RAW files that had headers populated with significant reporting delays (such as in the case that gave rise to this issue)... in which case rawspec failing wouldn't be helpful, but inhibiting?

[radonnachie]

Perhaps it'd be preferable to have an argument that enables the reading of meta data from an offset RAW header, or even just the last header of the file (just a calculated fpeek()). That'd be quite possible I rate, and I think it should be an appropriate solution for delayed reporting?