2020-12-28 01:30

Update sensor min/max wavelengths in the reader YAML files

I noticed that for many of the sensors the minimum and maximum wavelengths given in the reader YAML file for a given channel are inconsistent: wavelength: [min_wvl, central_wvl, max_wvl] These values appear to have been taken from various sources with differing standards. In this PR I'm attempting to standardise things by setting the min and max wavelengths to a fixed spectral response function value.

For a range of SRFS and paired wavelengths, sorted by ascending wavelength, I define: The minimum wavelength as the first time the instrument SRF is > 0.15 The maximum wavelength as the last time the instrument SRF is > 0.15

In all cases I take the SRFs from the NWP-SAF / RTTOV webpages.

Currently this is a work in progress. Below is a list of readers I've checked / updated: - [x] abi_l1b - [x] abi_l1b_scmi - [x] abi_l2_nc - [ ] acspo - [x] agri_l1 - [x] ahi_hrit - [x] ahi_hsd - [x] ahi_l1b_gridded_bin - [x] ami_l1b - [x] amsr2_l1b - [x] amsr2_l2 - [x] avhrr_l1b_aapp - [x] avhrr_l1b_eps - [x] avhrr_l1b_gaclac - [x] avhrr_l1b_hrpt - [x] caliop_l2_cloud - [x] clavrx - [x] cmsaf-claas2_l2_nc - [ ] electrol_hrit - [ ] fci_l1c_fdhsi - [ ] fci_l2_nc - [x] generic_image - [x] geocat - [x] ghrsst_l3c_sst - [x] glm_l2 - [ ] goes-imager_hrit - [ ] goes-imager_nc - [x] gpm_imerg - [x] grib - [x] hsaf_grib - [x] hy2_scat_l2b_h5 - [x] iasi_l2 - [x] iasi_l2_so2_bufr - [ ] jami_hrit - [x] li_l2 - [x] maia - [ ] mersi2_l1b - [x] mimicTPW2_comp - [x] modis_l1b - [x] modis_l2 - [x] msi_safe - [ ] mtsat2-imager_hrit - [x] nucaps - [x] nwcsaf-geo - [x] nwcsaf-msg2013-hdf5 - [x] nwcsaf-pps_nc - [x] olci_l1b - [x] olci_l2 - [x] omps_edr - [x] safe_sar_l2_ocn - [x] sar-c_safe - [x] scatsat1_l2b - [x] seviri_l1b_hrit - [x] seviri_l1b_icare - [x] seviri_l1b_native - [x] seviri_l1b_nc - [x] seviri_l2_bufr - [x] seviri_l2_grib - [x] slstr_l1b - [x] slstr_l2 - [x] smos_l2_wind - [x] tropomi_l2 - [x] vaisala_gld360 - [ ] vii_l1b_nc - [x] vii_l2_nc - [x] viirs_compact - [x] viirs_edr_active_fires - [x] viirs_edr_flood - [x] viirs_l1b - [x] viirs_sdr - [ ] virr_l1b


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39629969 weixin_39629969 4月前

    Coverage Status

    Coverage remained the same at 90.565% when pulling 716bcbba8e7589dc9e6d9fbd5c394e099232a0e2 on simonrp84:channel_wvl_ranges into 12917ab19e2da0e238175f30d933fbc27f8919d8 on pytroll:master.

    点赞 评论 复制链接分享
  • weixin_39732027 weixin_39732027 4月前

    OSCAR is, on occasion, incorrect with the wavelength ranges.

    As an example, the range for VIIRS I5 band listed on OSCAR have lower/upper limits of 10.5 (srf=0.3) and 12.3 micron (srf=0.57). Cutting the channel with an SRF of 0.57 is not good, as it means there's still a heck of a lot of signal beyond what we've said is the upper limit for the channel. If we use 0.15 as the SRF threshold then the wavelength limits would be 10.436 and 12.751.

    But the main thing I'd like to achieve here is consistency. As shown above, VIIRS itself is not consistent at present (the SRF for the lower and upper limits differ) and other sensors use other SRF limits. This PR aims to harmonise the limits across all the sensors, thereby presenting a constant set of known, and traceable, values to the user.

    I agree that using data from the space agencies / sensor manufacturers / operators / etc would be ideal, and that is what the NWP-SAF dataset is doing: They have taken SRF data for each instrument from a reputable source (usually the satellite operator) and converted it into a single format. Furthermore, NWP-SAF is contracted for this by EUMETSAT and is part of the UK met office - so definitely a reputable source for this data.

    Oh, also, I'm happy to commit the script I use for downloading and processing these SRF datasets. That way the user could check and update the values themselves. If you think that'd be useful, where would be a good location for the script in the satpy repo?

    点赞 评论 复制链接分享
  • weixin_39963255 weixin_39963255 4月前

    Sounds good. Is it possible to write a script that lives in either pyspectral or satpy and uses the SRFs that live in pyspectral? It could then have an option to print out YAML formatted wavelength ranges that could be copied/pasted into the satpy yamls?

    点赞 评论 复制链接分享
  • weixin_39732027 weixin_39732027 4月前

    Yep, shouldn't be too much effort to update my existing script to do that. To my knowledge, pyspectral uses the NWPSAF SRFS anyway.

    点赞 评论 复制链接分享
  • weixin_39934613 weixin_39934613 4月前

    Great effort! I think this begs for a short chapter in the documentation explaining how these are computed.

    点赞 评论 复制链接分享
  • weixin_39945679 weixin_39945679 4月前

    Codecov Report

    Merging #1404 into master will not change coverage. The diff coverage is n/a.

    Impacted file tree graph

    @@           Coverage Diff           @@
    ##           master    #1404   +/-   ##
      Coverage   90.56%   90.56%           
      Files         228      228           
      Lines       33406    33406           
      Hits        30254    30254           
      Misses       3152     3152           

    Continue to review full report at Codecov.

    Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 12917ab...cac13c4. Read the comment docs.

    点赞 评论 复制链接分享
  • weixin_39963255 weixin_39963255 4月前

    I've always tried to take these values from the OSCAR website. Granted, I'm not sure OSCAR can be used as a source of truth.

    I'd prefer these values be taken from the space agency or whoever is in charge of the instrument. I'm not a scientist or engineer on these types of things so I'm also will to step aside and let others choose what is best. That said, it needs to be documented and reproducible by newcomers to Satpy.

    点赞 评论 复制链接分享