Half a pixel shift on the x-axis for Metop GAC data.

[mraspaud]

Disclaimer: this is probably not an issue in pygac, but because it involves pygac and because of a lack of other place, I would like to have the discussion here.

@helgaweb has brought to my attention four passes from metops A and B where there is a consistent shift in x-direction. Since these are considered KLM satellites, there is no correction applied to the navigation by pygac (or satpy for that matter), so we are wondering where this can come from. @sfinkens @carloshorn any ideas? Attaching some images so you can see.

[mraspaud]

For the record, these were generated using pygac output form clara a2, but I downloaded one of the original gac files from NOAA class, plotted it with satpy and pygac, and could not see any difference.

[helgaweb]

Thanks @mraspaud Here are further impressions - a visual comparison of LAC L1c data by the University of Bern and PyGAC CLARA-A2 data.

[sfinkens]

Oh, that's nasty. I have no idea what the reason might be. But somebody mentioned in a meeting just now that the LAC -> GAC averaging for METOP might not be done onboard but in the ground segment. And maybe the methods differ.

[helgaweb]

@abhaydd Please also have a look.

[mraspaud]

@sfinkens Yes, that was one of my hypothesis, that the navigation doesn't match the aggregation in the same manner as it does on NOAA GAC.

[helgaweb]

@sfinkens Yes, I looked into that. And have notes & plots on this. Even though it was new for me that the onground resampling should take place at NOAA facilities and not EUMETSAT processing facilities.

[abhaydd]

Thanks @helgaweb for informing about this anomaly. I think we need to have credible/reliable information on how the processing of GAC differs between NOAA and EUMETSAT facilities (may be it doesn't). We should probably raise this point in tomorrows FCDR meeting.

[helgaweb]

@abhaydd Yes indeed, sofar its an open issues and only hypothesis. I made a few tests, but didn't had proper access for test data. And as said I went into the documentation...but this is also not reliable.

[mraspaud]

I was just talking to @abhaydd and he was wondering if the gac aggregation scheme wasn't causing the problem. He seems to remember that 4pixels are aggregated and the lon/lat is taken from the 5th pixel. @helgaweb could you check where a given lon/lat in a GAC pass is located in the corresponding LAC pass, columnwise ?

[abhaydd]

Do we have any statistic w.r.t. how frequently such a shift occurs? Is it a systematic feature or have we just checked few scenes? Thanks.

[helgaweb]

@mraspaud It's supposed to be the same lon/lat info columnwise. But that's one of the things, why I was asking for this data earlier. So yes.

@abhaydd Few scenes were checked visually. The analysis of the relative geometric accuracy of LAC/GAC contains a much larger sample. But of course, there could be other error sources involved (even after the extensive testing).

[mraspaud]

@helgaweb did you have time to look further at this?

[helgaweb]

@mraspaud Yes I had. I compiled information from the KlM User's Guide and analysed few scenes (FRAC, LHRR, HRPT, in comparison to GAC from UniBe and NSS. Sorry for the slow response here. I will reach out soon.

[mraspaud]

@helgaweb any news on this? we were talking about this again...

[helgaweb]

@mraspaud I stopped working on that same time ago. I think I shared the latest plots with @abhaydd and you in dec 2020? I did a lot of literature search -> you find this in my CMSAF final report. I can send it to you via email? Let me know how I can support this...

[mraspaud]

getting your report would be great. I can then document here.