-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUFRCREX CodeFlag 33: disconnect between EUMETSAT ROMSAF documentation and WMO documentation re: 0-33-039 flag table #54
Comments
Hi @jbathegit , I got the information from my colleague, that these entries are in use at DWD since 2012 (at least bit 8). I.e. they are defined long before 2012. As these entries are needed, I would suggest to propose them for FT-2020-2. What do you think about it? Best regards, |
Or is it too late to include them in FT-2021-1 (maybe discuss during tomorrow's call?) I know @SimonElliottEUM already said that he'd try to get in touch with the ROM SAF folks to figure out where the communications broke down and try to figure out a way forward, but clearly these entries are already in use by DWD and UCAR so maybe that's all water under the bridge at this point. And they're only code table entries anyway, so at this point would there really be any harm in just including them in next May's FT-2021-1 package? @jitsukoh and others in @wmo-im/tt-tdcf , any thoughts? |
@SibylleK @jbathegit as I told Jeff, I am working on this with the ROM SAF. I was in touch with the ROM SAF Manager yesterday as well as members of its Steering Group. My hope is that they will let me push through the request to add these entries via our well established process. BTW, they are flag table entries rather than code table entries so we need to i) be sparing in their allocation and ij) consider carefully which bit is assigned to which flag based upon how often the values change. |
If the finalized proposal can be submitted to today's meeting and we can get the confirmation from the relevant group by Jan 15, I would say we can include this to FT2021-1, but if we need discussion to finalize the proposal from now, I would put it in FT2021-2 because I don't want to make a poor decision because we don't have enough time. |
@jitsukoh I would wait for FT2021-2. This will allow time to consult the CGMS TFSDC. For the satellite domain, they are the subject matter experts, and we have included their consultation in the process up to now. |
As the entries are used operationally since many years (they are defined by ROM SAF 2007 and 2008) they should not be questioned and included in the flag table as they are. |
@SibylleK we would not be changing the definition because they have not yet been defined. In any case I think we should follow the agreed process and seek confirmation from the CGMS TFSDC before rushing to the earlier FT process. |
Updates made per the discussion in #54
@jitsukoh - I confirmed that this is ready -- do you want to check it too? |
@amilan17 thanks, please go ahead. |
Branch
https://github.com/wmo-im/BUFR4/tree/issue54
Final Proposal
Add quality flags to Flag Table 33
whereas the WMO table for 0-33-039 has these bits listed as "Reserved".
Original proposal
@wmo-im/tt-tdcf
I received a sample RO (radio occultation) message from one of our providers which has bit 10 set within the flag table for 0-33-039 (Quality flags for RO data). This is part of the standard 3-10-026 Table D sequence for RO data.
The provider stated that he was following documentation at https://www.romsaf.org/romsaf_bufr.pdf; specifically, the listed flag table for 0-33-039 shown on page 28. The problem is that bits 8, 9 and 10 from this table were apparently never officially proposed and approved at the WMO level by our team or one of its predecessors. Here are the meanings of these 3 additional bits as shown in the ROMSAF table:
whereas the WMO table for 0-33-039 has these bits listed as "Reserved".
I realize the WMO table is always the official one and takes precedence, but I'm curious if anyone recalls any history behind this or when/why there was an apparent communications disconnect between the ROMSAF group and WMO. The ROMSAF program appears to be affiliated with EUMETSAT, so I'd be particularly interested to hear whether @SimonElliottEUM or @erget may know anything about this?
Thanks and best regards,
-Jeff
The text was updated successfully, but these errors were encountered: