Cheetah 2025

Compensating through internet the data not transmitted via satellite on the Eumetcast Africa service due to the limitation in bandwidth

On the EUMETCast Africa service every hour EUMETSAT transmits about 600MB of MTG images. Not all the channels and not all the data are transmitted for every slot in order to not saturate the available bandwidth.
As a result, most images have areas where data is either unavailable or only available at a significantly lower resolution than what could potentially be available with the MTG.

For the MTG imagery CHEETAH tries to mask these issues in the following ways:

1. Low Res Data Fill (LRDF)

By transmitting a low reso globe at 6km resolution for those channels for which data is not transmitted in some areas, TECNAVIA is able to complete all MTG images received by satellite with images at low resolution received from the internet.

Take for example the Cloud Phase image at 1Km/pixel resolution. This image takes up 20MB of space in transmission, but it is geographically incomplete.

1km/pix res (20MB)	6km/pix res (0.5MB) LRDF Chettah Low Res Data Fill	Appearance when combined

By downloading a low res Data Fill version of this product at 6km/pixel resolution then TECNAVIA is able to cover the whole globe and grasp an overall glance. We do not feel that data is missing and the size of this image would require only an extra 500kB per downloaded fill image which is only 5% more than the original full resolution transmitted image.

The end result is that at the appearance all the data is there, only when zooming in can the resolution lack be noticed because in some areas there is only lower resolution data. The image below demonstrates this situation:

This functionality can technically be implemented in three different ways:

1.1 LRDF from EumetView (operational at PUMA sites for RGB Cloudphase and night Microphisics)

This functionality was implemented on the PUMA stations directly using the Eumetview. The limitation is that not all channels are available on Eumetview at the moment. For Cloud Phase and Night Microphisics this works well.

For the normal channels, only VIS 0.6 has a need of being implemented, but it does not work well because the calibration within Eumetview is different from the one on the PUMA stations.

Additionally the images downloaded from EumetView cannot be filtered out of the areas where we already have data available. So there is no data optimisation by masking the unnecessary areas.

1.2 LRDF from TECNAVIA / EWC (needs approval by EUMESAT and AUC)

In TECNAVIA and as a backup server at EWC (European Weather Cloud), TECNAVIA is able to receive all the EUMETCast Terrestrial service and can create exactly the images masked in the areas needed for any channels.
By doing so, the PUMA stations can download only LRDF (low resolution Data Fill) images data for all the channels that are transmitted in an incomplete manner over the satellite.

1.3 LRDF directly from the Satellite (must be decided by EUMETSAT and RAIDEG Group)

With the agreement of the RAIDEG group and of EUMETSAT, the products described in the previous points could automatically be transmitted as separate images from EUMESAT itself. TECNAVIA could use a channel to transmit this data to the C Band users so that all the images will appear complete.

This would require less than 5% of transmitted bandwidth for MTG data.

2. High Res Local Data (HRLD)

Most of the images transmitted over the EUMETCast Africa are 3km resolution data, exactly like the MTG. This means that even if the satellite spacial resolution is available, unfortunately, because of the limited bandwidth this data is not disseminated over the EUMETCast Africa service.

In order to receive it you need to implement the EUMETCAST Terrestrial and/or Terrestrial HR.This requires high connectivity and often a waist of resources (bandwidth and processing power).

ROI of high resolution data	Left side high resolution data sharper image, right side normal resolution out of focus

One solution to overcome this is to download from Internet the high resolution images of only the area of interest and typically the Local or the Regional area necessary by the local user. We will call this ROI (Region of Interest).

The required bandwidth depends on the size of the ROI and by the number of channels requested. Each receiving station will define a different ROI. This means that the only way to distribute this is through internet and from a server that allows the download of only the tiles and channels requested by the installation.

This video shows the service live

2.1 HRLD from TECNAVIA / EWC (needs aproval by EUMETCast and AUC)

In TECNAVIA and as a backup server at EWC (European Weather Cloud) all the data from the Terrestrial service (Normal and HR) can be acquired in order to create for every channel tiles data that can be independently from each other be downloaded from the internet. The resolution of the tiles would be at the maximum resolution available for the channel.

Because it is not allowed to redistribute the data freely through independent sources that are not controlled by the EKU key and because the objective is to reduce the size of the images as much as possible, Tecnavia will developed a compression schema where the tiles do not contain the original pixel count but only the delta (offset) from the transmitted value through the satellite.
These tiles are 512×512 in size and contain the difference between the transmitted 3km/pixel resolution data and the 1km/pixel data. This means that in order to use the data you need to add the delta value of each pixel to the original value of the 3km/pixel resolution data transmitted though the EumetCast Africa.

We will call this WMST channel as Cheetah Tiled Delta Distribution (TDD).

This procedure generates image files that are in the average 30% smaller than if we were to provide the original data with the advantage that no additional encryption mechanism is necessary to protect the data from users that are not allowed to read it.

As a reference to calculate the amount of data to be downloaded, consider that each tile will have a size of approximately 65kB per tile of 512×512 and per channel.

If we consider a ROI of 3 x 3 tiles, for every channel and received slot the PUMA stations will require 585kB of data for every image. In a real case situation you should consider at least having the 2 channels (IR,VIS) received at full resolution every 10 minutes which means that each hour a station would require to download only 7MB.

2.2 HRLD from EumDAC (could be made operational, but occupies 15 x bandwidth)

The required full resolution of a ROI can otherwise be downloaded from a process that makes the request to the EUMDAC service available at EUMETSAT. The amount of data and bandwidth required would be higher because the whole data is being transmitted instead of the delta.

Additionally, the data on the EUMDAC server is not available at near real time, but only after a delay of over 10 minutes after the data has been transmitted to ground to the real near time stations.
Unfortunately, from our tests the EUMDAC is only able to return the data in NetCdf floating for a ROI which makes the file 9 times bigger than an equivalent file in NetCdf returning raw counts.

Taking the same example of before with two channels every 10 minutes for a ROI 1500pixel by 1500 pixels the amount of data to be transfered per hour would be around 110 MB much more than 15 times the 2.1 option.

3 Locally generated RGB

Similar problem as above, you have it when RGB images are generated locally. Here the situation is more subdole, because not always you notice that data is missing in some channels and therefore you are getting wrong coloring and classifications that could lead to wrong classifications.

Over the ocean there is wrong colouring (at 3km/pix resolution)	How it should look (at higher resolution)

This problem cannot be resolved using the Eumetview because the data is not available. The only viable solution ist to be able to download the low res data from Tecnavia / EWC like discribed above in point 1.2

4 METAR, SIGMET and SYNOP data from MDD is incomplete

The MDD service of the EumetCast Africa is incomplete and missing many data elsewhere available on the GTS. Therefore as it is people cannot make use of such data. In the PUMA systems we added the ability of downloading this data from the internet.
From the pictures you can see the difference of stations of the data received from the satellite compared to the data took from the internet.

Satellite MDD received data (Metar and Sigmet)	Internet downloaded data (Metar and Sigmet)

The data is downloaded from the Tecnavia servers in order to minimize the amount of data downloaded the system will only request the data not yet dowloaded from the previous requested timestamp.

This video shows the service live.