MTG test data
fvalk@...
Listing the available composites for MTG I get:
'airmass' 'ash' 'cimss_cloud_type' 'cimss_cloud_type_raw' 'cloud_phase', 'cloud_phase_distinction' 'cloud_phase_distinction_raw' 'cloud_phase_raw' 'cloudtop' 'convection' 'day_microphysics' 'dust' 'fog' 'green_snow' 'ir_cloud_day' 'ir108_3d' 'natural_color' 'natural_color_raw' 'night_fog' 'night_microphysics' 'true_color_raw'
All of these I can generate without problem with the exception of cloud_phase and cloud_phase_distinction. The raw version is again produced without hindrance (see attached).
Am I right in assuming that for these two enhancements have not yet been defined? If so, they should not appear in the list of available composites I believe.
Ferdinand |
|
Ernst Lobsiger
Ferdinand,
as I suspected at the beginning some composites that use solar angles for corrections do not work. But they do work as raw composites (without solar corrections). I had an other problem with the test data not filling whole disk images at the limb. All falls into place if you read this thread: https://groups.google.com/g/pytroll/c/tw8-KbB0Cjo You probably did a print(scene.available_composite_names()). This method cannot know that the test data has empty solar data. It also depends on the reader, wether you get some extra composites that you cannot image with EUMETCast data. That's because some readers can read and understand datasets and resolutions that we do not get with EUMETCast. An extreme example is MODIS data. But also MetopB/C AVHRR data has 5 channels where 3a and 3b are mutually exclusive and switched by telecommands. Satpy thinks 3a and 3b are always there ... https://groups.google.com/g/pytroll/c/DjEzbFJhFkE Best regards, Ernst |
|
fvalk@...
Thanks Ernst.
Yes, I had read the EUM/MTG/TEN/22/1290888 document and understood from 4.2.7 that at the edge pixels would be empty; so I was prepared there. The list of possible composites I indeed got from the query you mentioned and I had incorrectly assumed that those had been confirmed to work with the test data. Your clarification explains my finding and it re-emphasizes that it is very instructive reading the communications in the pytroll group more consistently than I did.
Another thing I noticed is that the document states that the simulated VIS/NIR channels are at 11136x11136 pixels and the IR in 5568x5568 pixels. I have made some test runs at the 11k resolution but vis channels become quite pixelated. I suspect they used the regular resolution seviri and not the HRV one, because that latter has the higher resolution and should thus not cause pixelation.
In any case I’m glad I did the MTG exercise as I now feel much more confident for things to come.
Cheers, Ferdinand
From: MSG-1@groups.io On Behalf Of Ernst Lobsiger via groups.io
Sent: Thursday, 25 August, 2022 12:23 To: MSG-1@groups.io Subject: Re: [MSG-1] MTG test data
Ferdinand, |
|
R. Alblas
Ferdinand, I think the simple reason is that HRV doesn't cover the whole
disc. And it is 'just' test data anyway. The test data contains
pixel squares of 3x3 having the same value, although it seems that
satpy does some interpolation or something like that. But you can
still see the 3x3 squares if you zoom in far enough. Cheers, Rob.
On 25-08-2022 16:02,
fvalk@... wrote:
|
|
fvalk@...
Rob,
You are right. Partial coverage in high resolution would not really do for a full hemisphere simulation. At least it has been ‘proof of concept’.
Cheers, Ferdinand
From: MSG-1@groups.io On Behalf Of R. Alblas
Sent: Thursday, 25 August, 2022 14:27 To: MSG-1@groups.io Subject: Re: [MSG-1] MTG test data
Ferdinand, I think the simple reason is that HRV doesn't cover the whole disc. And it is 'just' test data anyway. The test data contains pixel squares of 3x3 having the same value, although it seems that satpy does some interpolation or something like that. But you can still see the 3x3 squares if you zoom in far enough. Cheers, Rob.
On 25-08-2022 16:02, fvalk@... wrote:
|
|
Ernst Lobsiger
Rob and Ferdinand,
I think all of the "features" and problems found are discribed/explained in the referenced document under: 4.2 Data Content Issues The only problem is that the document ist quite long and 4.2 ist at it's end :-\. But we can certainly admit that EUMETSAT has done a good job (data + documentation) to let us see what we have to expect rather soon. And it's good to know that the MTI satpy driver has mostly been written by someone working at EUMETSAT. Regards, Ernst |
|
fvalk@...
Ernst,
True, and appreciation towards Eumetsat is certainly opportune.
Ferdinand
From: MSG-1@groups.io On Behalf Of Ernst Lobsiger via groups.io
Sent: Thursday, 25 August, 2022 17:09 To: MSG-1@groups.io Subject: Re: [MSG-1] MTG test data
Rob and Ferdinand, Groups.io Links: You receive all messages sent to this group. View/Reply Online (#33299) | Reply To Group | Reply To Sender | Mute This Topic | New Topic _._,_._,_ |
|