Skip to content
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

Closed
jbathegit opened this issue Dec 4, 2020 · 9 comments
Assignees
Milestone

Comments

@jbathegit
Copy link
Contributor

jbathegit commented Dec 4, 2020

Branch

https://github.com/wmo-im/BUFR4/tree/issue54

Final Proposal

Add quality flags to Flag Table 33

Bit number Meaning
8 Open loop data included
9 Surface reflections detected
10 L2C GNSS signals used

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:

Bit number Meaning
8 Open loop data included
9 Surface reflections detected
10 L2C GNSS signals used

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

@SibylleK
Copy link
Contributor

SibylleK commented Dec 9, 2020

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,
Sibylle

@jbathegit
Copy link
Contributor Author

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?

@SimonElliottEUM
Copy link
Contributor

@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.

@jitsukoh
Copy link

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.

@SimonElliottEUM
Copy link
Contributor

@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.

@SibylleK
Copy link
Contributor

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.
Changes of these entries would most probably cause operational problems.

@jbathegit jbathegit changed the title disconnect between EUMETSAT ROMSAF documentation and WMO documentation re: 0-33-039 code table disconnect between EUMETSAT ROMSAF documentation and WMO documentation re: 0-33-039 flag table Dec 10, 2020
@SimonElliottEUM
Copy link
Contributor

@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.

@jbathegit jbathegit added this to the FT-2021-2 milestone Dec 10, 2020
@amilan17 amilan17 changed the title disconnect between EUMETSAT ROMSAF documentation and WMO documentation re: 0-33-039 flag table BUFRCREX CodeFlag 33: disconnect between EUMETSAT ROMSAF documentation and WMO documentation re: 0-33-039 flag table Apr 20, 2021
jbathegit added a commit that referenced this issue Apr 30, 2021
Updates made per the discussion in #54
@amilan17
Copy link
Member

@jitsukoh - I confirmed that this is ready -- do you want to check it too?

@jitsukoh
Copy link

@amilan17 thanks, please go ahead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants