Add level-1 readers for the arctic weather satelliter data

[adybbroe]

This PR adds a reader for the ESA Arctic Weather Satellite (AWS) l1b format, as well as the corresponding EUMETSAT AWS Level-1b format. The latter to become the EPS-Sterna level-1b file format.

The ESA AWS file format is not documented anywhere but is netCDF and supposed to follow the EPS-SG MWS level-1b format. See https://www.eumetsat.int/media/44139

Here a draft version of the EPS-Sterna level-1b file format, as od December 2024:

EPS-Sterna Level 1B Product Format Specification (PFS) v1C [Approved].docx

ESA has also developed a level-1c processor, mapping the data for all four channels groups (feed horns) to one of the groups, default is the 183 GHz group. This PR also includes a first reader for this L1c file format. The ESA L1c file format is neither documented, but it is following the L1b format closely.

This PR was started autumn 2023 where the ESA AWS level-1b file format had not matured. Now, the format is supposed to be the final, and we have used first real data processed and delivered to us (SMHI among other partners in the MWS/AWS SAG and EUMETSAT) in November 2024.

• Closes #xxxx
• Tests added
• Fully documented
• Add your name to AUTHORS.md if not there already

[adybbroe]

Here is a view of channel 1 remapped to a near-ided perspective projection over northern Europe:

[codecov]

Codecov Report

Attention: Patch coverage is 99.51691% with 2 lines in your changes missing coverage. Please review.

Project coverage is 96.12%. Comparing base (23fcf3c) to head (0b9760c).
Report is 41 commits behind head on main.

Files with missing lines	Patch %	Lines
satpy/readers/mwr_l1b.py	98.88%	1 Missing ⚠️
satpy/readers/mwr_l1c.py	96.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2565      +/-   ##
==========================================
+ Coverage   96.01%   96.12%   +0.11%     
==========================================
  Files         380      383       +3     
  Lines       55445    55577     +132     
==========================================
+ Hits        53234    53424     +190     
+ Misses       2211     2153      -58     

Flag	Coverage Δ
behaviourtests	3.91% <0.00%> (-0.01%)	⬇️
unittests	96.22% <99.51%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mraspaud]

Just two comments for now.

[coveralls]

Pull Request Test Coverage Report for Build 12748975290

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 416 of 418 (99.52%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.03%) to 96.231%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
satpy/readers/mwr_l1b.py	90	91	98.9%
satpy/readers/mwr_l1c.py	25	26	96.15%

Totals
Change from base Build 12299617024:	0.03%
Covered Lines:	53672
Relevant Lines:	55774

---

💛 - Coveralls

[adybbroe]

Looks very nice, many thanks!

[adybbroe]

So, just a comment/observation. The AWS testdata file delivered August 2023 has the datasets structured a bit odd and different from most other satellite datasets (e.g. the EPS-SG MWS testdata which format it is supposed to follow).

Here a phrase communicated to ESA abouth this layout issue:

"The ordering of the dimensions is unexpected, e.g. for “aws_toa_brightness_temperature” we have (19, 145, 4991) which is (n_channels, n_fovs, n_scans). But in netCDF the first dimension is always the one that varies the most slowly. For MWS the order is reversed, i.e. (n_scans, n_fovs, n_channels)."

This ordering currently has the unfortunate consequence that the optimal radius of influence used for remapping cannot be determined. The method geocentric_resolution in the CoordinateDefinition class in the geometry.py module of Pyresample assumes the first dimension is the scanlines, but here it is the pixel number across scan instead, so the points found are the points close to nadir of the first scanline (instead of the outer most edge of the scan in the middle of the swath). In the testdata set delivered the first 10-20 scanlines or so are missing-data in the geolocation (for some strange reason).

I am preparing a PR for Pyresample on this.

Until now one has to provide a reasonable value (say 40000) for radius_of_influence parameter explicitly in the resample call on the scene object.

When doing this one may be able create an image like the below using code similar to this (I have here skipped the decoration/coast overlay part for simplification):

scn = Scene(filenames=FILENAMES, reader='aws_l1b_nc')
composite_name = 'mw183_humidity_surface'
scn.load([composite_name])

local = scn.resample(AREAID, radius_of_influence=40000)
local.show(composite_name)

[pnuu]

Some comments inline. I'd like some clarifiactions, but in general LGTM!

[adybbroe]

I somehow thought we had merged this long ago?
But, it makes sense not to merge it now, as we will have new test data from ESA in about a month, where the issues with the format that we raised with the, should be solved. Then we can update the reader for the new format.
So, we can wait another month or two perhaps, or what do you say @mraspaud and @pnuu ?

Sorry for not coming back to your comments/questions earlier!

[mraspaud]

Any news on the new test dataset?

[pnuu]

In addition to the unresolved points, there was some kind of misunderstanding with the datetime imports, fixes suggested. Also the file patterns need some fixing.

[adybbroe]

In addition to the unresolved points, there was some kind of misunderstanding with the datetime imports, fixes suggested. Also the file patterns need some fixing.

Yeah, don't know what I did, sorry. Now fixed.

[djhoese]

This is a microwave instrument right? Do we need to define a "base" sensor type for "microwave" making this sensor_name: microwave/mwr? Or does this work as-is and we won't worry about a shared set of "microwave" composites? If this isn't microwave, then this should probably be sensor_name: visir/mwr, right?

[adybbroe]

Yes, you are right. I think it sounds right to have a "microwave" group here. I was, however, not sure how this works. But I try add it now.... Just need to do some system, testing...

[adybbroe]

Looks okay I believe.