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,

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


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:

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,

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@...
 

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:

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,

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


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,

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

._,_._,_


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
Your Subscription | Contact Group Owner | Unsubscribe [fvalk@...]

_._,_._,_