Cloud Top Temp from Eumetsat

How do I...?
Post Reply
User avatar
mkorotkin
Posts: 2
Joined: Tue Aug 25, 2020 11:09 pm

Cloud Top Temp from Eumetsat

Post by mkorotkin »

I have Eumetstat files that I have loaded into Mcidas V. I have added them properly through the ADDE Dataset and when it lists the fields for my specific file I can see the various types including Raw, Radiance, Reflectivity, Brightness. When I click on the Brightness field to pull up Cloud Top Temps through the probe the values are not realistic as the surface shows over 600 which I'm assuming is in Kelvin.

I'm hoping I'm just displaying the data incorrectly or is this an issue with the satellite data itself?

Any advice would be appreciated. I'm attaching a sample folder with the satellite image files. I was using ir108 for the cloud top temps.

Thank you!
Attachments
Screen Shot 2020-09-01 at 10.34.44 AM.png
MSG2-SEVI-MSG15-0100-NA-20120824155740.898000000Z-20120824155752-1418442.zip
(1.68 MiB) Downloaded 110 times
User avatar
bobc
Posts: 988
Joined: Mon Nov 15, 2010 5:57 pm

Re: Cloud Top Temp from Eumetsat

Post by bobc »

Hello,

It looks like you're doing things correctly. This is actually a data problem with AREA files created by EUMETSAT. We explored this a while back and our findings are in (inquiry 1878). It turns out that EUMETSAT is running an old version of the McIDAS-X software to produce these AREA files, which we believe is at least part of the problem.

There are two workarounds you can do to get EUMETSAT data working in McIDAS-V.

  1. You could use the AREA files from EUMETSAT, but you'll have to create individual directories (and local datasets) for each band. I tried this out by creating a directory containing only the Mcidas*IR108 file and I created a local dataset pointing to it. Loading the single timestep through the Absolute times tab in the Data Sources tab of the Data Explorer, I get the expected calibrations in the Field Selector. I selected 10.8um > Temperature and the values in the display make sense (roughly 215K to 305K). Note that I didn't try this with every band, just the 10.8um that you mentioned you were using.
  2. Assuming you ordered this data from the Eumetsat EO Portal, there's another format you can order called "HRIT data sets in tar file". This format should work for you if you choose the "MSG HRV" or "MSG HRIT FD" local server formats when creating your local dataset in McIDAS-V. This is described briefly in the Local ADDE Data Manger page of the User's Guide.

Please let me know if you have any further questions, or if neither of the workarounds work for you.

Thanks,
Bob Carp
McIDAS User Services
User avatar
mkorotkin
Posts: 2
Joined: Tue Aug 25, 2020 11:09 pm

Re: Cloud Top Temp from Eumetsat

Post by mkorotkin »

Thank you Bob. That definitely did the trick. It appears as though the probe tool only works correctly when the image is displayed in the native projection. This native projection is definitely not the one that works with export to Google Earth. I found that the one that actually looked normal was Africa. I found this quite odd but I'm assuming that's just how it is with some of these formats.
User avatar
bobc
Posts: 988
Joined: Mon Nov 15, 2010 5:57 pm

Re: Cloud Top Temp from Eumetsat

Post by bobc »

Hello,

I'm glad you were able to get your data to display. When you say "the probe tool only works correctly when the image is displayed in the native projection" are you referring to the middle mouse button probe? I'm seeing this work on my laptop using the 10.8um>Temp AREA file you sent in your original post. I tried World and Africa for projections. What projections did you try where you saw the probing problem?

You're correct that many projections can't export an image to Google Earth (kml/kmz) format. The only projections that work are lat/lon or rectilinear projections. You probably already saw this, but the Movie Capture Controls page of the User's Guide includes this:

McIDAS-V can also write out an image and the corresponding Google Earth KML or KMZ file. For this to be correct, the projection must be a Lat/Lon geographic projection (i.e., rectilinear) and in an overhead view. Some of the default projections that are Lat/Lon include World, Africa, Asia, Australia, and the individual state projections (US->States->...). You can also create your own Lat/Lon projection using the Projection Manager. The simplest way to get a correct projection is to select the Projections->Use Displayed Area menu item in the Main Display window. If you specify a .kml file, McIDAS-V will generate an image with the same file prefix and the kml file that refers to the image. If you specify a .kmz file (which is a zip format) it will contain the image and the kml file.

I tried this out with your data by setting the projection to World, zooming in on the data, and capturing a kmz image which I was able to successfully load into Google Earth. Note that everything in the display (e.g. map lines, layer labels, and logo) will be included in the image.

Also, a random tip: When I displayed the original image the map lines were broken/dashed. You can fix this by clicking on the blue "Default Background Maps" in the Legend of the Main Display and enabling the "Fast Rendering" checkbox for all of the visible maps. This will make the map lines more connected with the data in its native projection. If you change to World after this, you'll likely have to disable fast rendering for the maps to remove horizontal lines. This is further described on the Map Controls page of the User's Guide.

Thanks,
Bob
Post Reply