Closed erget closed 4 years ago
Hi Daniel - a reminder that Y > 191 means a descriptor is local, so your proposed new FXY numbers 0-21-192, 0-22-192 and 3-40-192, 3-40-193, ..., 3-40-198 all need to be adjusted to put them into the WMO standard range where Y <= 191.
Hi Jeff, yes, you're right - the thought here was that there might be number clashes so we'd discuss the sequences and then when they're ok have the Secretariat assign the final numbers.
It was a cunning plan on my part. It doesn't matter which numbers we get - I though it might be helpful to have them assigned by the Secretariat
Hi Daniel, Many thanks for BUFR templates.
Could we not include satellite name in the name of the BUFR template since the same template will be used for other altimeters.
Would't it better if the following elements are moved from the "3-40-197 “Sentinel-6 Michael Freilich 1 Hz C and Ku band values" part to the "3-40-194 “Sentinel-6 Michael Freilich radiometer values" part: 0-25-164 Radiometer wet tropospheric correction 0-13-090 Radiometer water vapour content 0-13-091 Radiometer liquid content
In 3-40-195 why do we have twice
0-01-030 Numerical model identifier
0-10-085 Mean sea-surface height
In 3-40-194, could we use delayed replication. That is in case that we can re use it in the future.
If element "0-21-122 Attenuation correction on sigma-0 (from tb)" is new, can we change sigma-0 to backscatter coefficient to be consistent with the other elements like: "0-21-183 Specific band corrected ocean backscatter coefficient"
Hi @marijanacrepulja , I've answered your questions point-by-point below:
Could we not include satellite name in the name of the BUFR template since the same template will be used for other altimeters.
This is fine, I have updated the sequence names accordingly.
Would't it better if the following elements are moved from the "3-40-197 “Sentinel-6 Michael Freilich 1 Hz C and Ku band values" part to the "3-40-194 “Sentinel-6 Michael Freilich radiometer values"...
Those descriptors are proposed for 3-40-197 because the retrieved values use the radiometer brightness temperatures and the altimeter's Sigma0, so they should remain in that sequence.
...why do we have twice 0-01-030 ... 0-10-085
The product will contain 2 MSS models in the product, this is to allow describing both of them.
In 3-40-194, could we use delayed replication
Yes, I have updated the sequence accordingly.
If element "0-21-122 Attenuation correction on sigma-0 (from tb)" is new, can we change sigma-0 to backscatter coefficient to be consistent with the other elements like: "0-21-183 Specific band corrected ocean backscatter coefficient"
0-21-122 already exists, we would prefer to reuse it.
@erget Hi, Daniel, I changed the FXY number of Corrected OCOG* backscatter coefficient (negative reference) from 0-21-192 to 0-21-189 and changed the FXY number of Specific band significant wave height (negative reference) from 0-22-192 to 0-22-179. And, I also changed from 340192 to 340018, 340193 to 340019, 340194 to 340020, 340195 to 340021, 340196 to 340022, 340197 to 340023, 340198 to 340024. More information about the CREX_Unit, CREX_Scale, CREX_DataWidth_Char, Status are needed. A branch for this issue is created. Please check it. Many thanks.
@chenxiaoxia2019 I note the following changes:
and have updated the proposal accordingly.
I'm a bit confused about the CREX information - this is satellite data and thus we don't intend to disseminate it in CREX. What do you require exactly?
@chenxiaoxia2019 I have reviewed the proposed changes in the associated PR. I didn't review every file but rather BUFR_TableD_en_40.csv
and txt/BUFRCREX_TableB_en.txt
but of course the changes in those files will need to extend to the other ones as well.
@chenxiaoxia2019 I note also that there is a number clash in these tables - #10 already uses 3-40-018. I propose giving the IKFS-2 sequence described in that issue to use 3-40-023 but I leave it to you to make the final decision that will not produce a number clash.
For now, I'm producing sample data as described in this proposal, i.e. #10 and #15 are both using different definitions for 3-40-018.
I've uploaded sample data - *.nc
is the native file, *.bin
is the same translated into BUFR.
@chenxiaoxia2019 BUFR_TableD_en_40.csv still contains entries that need to be updated, please see below 40,Additional satellite report sequences,340018,(Altimeter product),,340193,Uuu,,,Operational 40,Additional satellite report sequences,340018,(Altimeter product),,340194,Vvv,,,Operational 40,Additional satellite report sequences,340018,(Altimeter product),,340195,www,,,Operational 40,Additional satellite report sequences,340018,(Altimeter product),,340196,Xxx,,,Operational
I've corrected the issues found on the associated branch; it looks fine to me now.
@erget I also found that lines below need to be updated 40,Additional satellite report sequences,340022,(Altimeter main values),,340023,Yyy,,,Operational 40,Additional satellite report sequences,340022,(Altimeter main values),,340023,Yyy,,,Operational 40,Additional satellite report sequences,340022,(Altimeter main values),,340023,Yyy,,,Operational 40,Additional satellite report sequences,340022,(Altimeter main values),,340024,Zzz,,,Operational
replace 3-40-018 with 3-40-xxx before validation of samples
I have renamed 3-40-018 to 3-40-019, giving precedence to #10.
Hi @marijanacrepulja I've uploaded new sample data, can you please re-confirm?
Hi @erget, please see attached output of decoded sample. I have used table D from branch but haven't been able to check values, as there is no file to show what the decoded values should be.
I have now noticed with real numeration assigned, that template 3-40-023 “Altimeter main values” contains repetition of 3-40-24 three times. Could you please explain the reason.
I have request from our Research Department if could be possible to include 20-Hz wind speed values (21 of them). Many thanks
@marijanacrepulja thank you very much!
The repetition of 3-40-024 is due to the use of 3 different algorithms: SAR, LRM & PLRM. This was agreed (prior to my involvement!) with colleagues from ECMWF, I believe in R&D, but I'm not sure who was involved.
Also, although we have space in the sequence for including 20-Hz wind speed values, these are not present in the original product - Sentinel-6 doesn't produce them. That's why you don't see them in these BUFR messages.
Is there anything else we should discuss or can we consider the product validated?
@erget I believe we can consider the product validated. Thank you for the feedback.
Perfect, thank you, then I am marking this template as validated.
SUMMARY: Add entry to Table B Class 21, add entry to Table B Class 22 and add entries to Table D Category 40.
Approved by FT 2020-2.
Branch
https://github.com/wmo-im/BUFR4/tree/issue-15
Summary and purpose
This document proposes new BUFR entries in order to represent altimeter data from Sentinel-6 Michael Freilich.
Action proposed
The meeting is requested to approve the contents for inclusion within the next update to the WMO Manual on Codes.
Discussions
Sentinel-6 Michael Freilich is due to be launched in the autumn of 2020. In order to ensure the standardized exchange of data from the radiometer mission, a number of BUFR table entries have been developed and are proposed here for adoption.
Detailed proposal
Add the following sequence 3-40-019 “Altimeter product” to BUFR Table D/01:
Add the following sequence 3-40-020 “Satellite general values” to BUFR Table D/01:
Add the following sequence 3-40-021 “General radiometer values” to BUFR Table D/01:
Add the following sequence 3-40-022 “Altimeter model values” to BUFR Table D/01:
Add the following sequence 3-40-023 “Altimeter main values” to BUFR Table D/01:
Add the following sequence 3-40-024 “1 Hz C and Ku band values” to BUFR Table D/01:
Add the following sequence 3-40-025 “20 Hz C and Ku band values” to BUFR Table D/01:
Add the following elements to BUFR Table B/40:
Notes: