Changes between Initial Version and Version 1 of Ticket #186
- Timestamp:
- Aug 21, 2008, 3:56:18 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #186 – Description
initial v1 24 24 Andrew 25 25 }}} 26 27 {{{28 26 Hi Andrew 29 27 30 It's possible that there is a timing offset we missed in that flight - we obviously do our best to correct those but sometimes some slip through. In particular the scan position offset is easy to miss, because it can be corrected to look correct with the more common GPS timing offset. You know that already, I'm sure - sorry, I'm not trying to be patronising here. I'm actually still more inclined to blame incorrect boresight numbers - the pitch difference between what was used and what should have been was 0.48 degrees, which would have shifted the image along-track. It seems more likely to me that it would be a result of a known mistake that was made than that there was also an SCT offset present that was missed (not that I'm ruling that out, just that I'm inclined to go for the explanation that only requires one thing to go wrong). We're going to reprocess it anyway to fix the boresight, so we'll check the timing again in any case. 28 Well, this one seems a little embarrassing. A quick inspection of the processing scripts we used to process that flight (all of 102a, not just the first line) reveals that the wrong boresight correction numbers were used to process it - we used the numbers for day 166 onwards (which would be correct for the other Inverclyde flights, suggesting someone copy/pasted and then forgot to change the boresight numbers). To compound things, it looks like the Hawk flights will have the same problem - can you confirm that that is the case, just to confirm the diagnosis? 31 29 32 We do compare the final images to the vector data, and sometimes that does result in us going back and having another look at the timing. However, it's not uncommon for the vectors and the image to be a few pixels apart (often by differing amounts in different areas of the image), so it's possible for a mistake to get through that check. I think this is the first time we've had a user tell us that the timing was wrong, so it hasn't come up before, but I suspect our response would be (and is) "Sorry, we'll reprocess it for you" rather than advising the users to try and fix it themselves. As you say, the current azgcorr options don't really provide a facility for that, although I see from Bill's email that he's done some work in that direction already so possibly it'll be something that'll happen in future. 30 Apologies to Alasdair, we'll reprocess the data for him - could you ask him to please send our USB hard disk back, and then we'll send the reprocessed data back to him on that disk. Also, he is of course welcome to contact us directly with problems like this rather than interrupting you. ;-) 33 31 34 Ben 32 Thanks for bringing this to our attention 33 Ben 34 {{{ 35 35 36 }}} 36 37