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

new Table B descriptor for "Satellite sub-identifier" #118

Closed
jbathegit opened this issue May 5, 2022 · 4 comments · Fixed by #121
Closed

new Table B descriptor for "Satellite sub-identifier" #118

jbathegit opened this issue May 5, 2022 · 4 comments · Fixed by #121
Assignees
Labels
Milestone

Comments

@jbathegit
Copy link
Contributor

jbathegit commented May 5, 2022

Summary and purpose

This issue proposes a new Table B descriptor for "Satellite sub-identifier"

Stakeholders

This would be of interest and potential use by any commercial or non-commercial providers of satellite data, as an additional way to define and classify the data within their BUFR reports.

As already discussed with @SimonElliottEUM, this would also be of interest to the CGMS, who may in turn want to consider the use of this new value within WIGOS Station Identifiers (WSIs) for satellite reports.

Discussion

One of the commercial providers for satellite radio occultation has requested a new "Satellite sub-identifier" descriptor in BUFR. As envisioned, this would have a numerical value between 1 and 65534 (i.e. 16 bits wide) and which any satellite data provider (commercial or non-commercial) could then use to differentiate between multiple satellites under a single "Satellite identifier" value from the 0-01-007 table. So you could basically define up to 65534 subentries for each corresponding 0-01-007 entry, and at least for the commercial RO data this would allow a better way for each vendor to categorize reports from among all of the different nanosatellites within their own constellations. It would be up to each vendor to internally keep track of which number corresponded to which individual satellite in their constellation, but this would be a preferable way to be able to backtrack vs. the current situation where each vendor has a combination of a small number of 0-01-007 and 0-02-019 entries for this same purpose.

We could do this without impacting the BUFR Table D sequence 3-10-026 which is currently used to report RO data, because any vendors who wanted to report this additional information could do so by simply adding this new descriptor to their BUFR messages immediately preceding the main 3-10-026 descriptor, which itself would remain unchanged. Again, I'm thinking this new descriptor would be completely optional, but potentially useful supplementary information if anyone wanted to use it, including for other types of satellite reports besides just RO data.

Detailed proposal

Add new descriptor to Class 1 of BUFR Table B:

FXY Element name Unit Scale Reference value Bit width
0-01-016 Satellite sub-identifier Numeric 0 0 16
@jbathegit jbathegit added this to the FT2022-2 milestone May 5, 2022
@SimonElliottEUM
Copy link
Contributor

@jbathegit thanks for taking the time to discuss this with me. As we noted, there may also be the possibility to use the Issue Number of the WIGOS station ID for this purpose. We are discussing this in the framework of the CGMS Task Group on Satellite Data and Codes, and also in TT-WSI.
This has no detrimental bearing upon the proposal here, which I support.

@jbathegit jbathegit self-assigned this May 6, 2022
@marijanacrepulja marijanacrepulja added this to Submitted in BUFR4 Amendments via automation May 17, 2022
@amilan17 amilan17 moved this from Submitted to In discussion in BUFR4 Amendments May 18, 2022
@amilan17
Copy link
Member

amilan17 commented May 18, 2022

presented at https://github.com/wmo-im/CCT/wiki/Teleconference-18-and-19.5.2022

  1. @jbathegit update branch
  2. no need for note
  3. no need to validate with sample data

@amilan17 amilan17 moved this from In discussion to In Validation in BUFR4 Amendments May 18, 2022
jbathegit added a commit that referenced this issue May 20, 2022
@jbathegit
Copy link
Contributor Author

jbathegit commented May 20, 2022

@amilan17 @marijanacrepulja

The branch has been updated.

@marijanacrepulja
Copy link
Contributor

@jbathegit thank you.
@amilan17 I have moved the issue to the validated status.

@marijanacrepulja marijanacrepulja moved this from In Validation to Validated in BUFR4 Amendments May 26, 2022
@amilan17 amilan17 linked a pull request May 27, 2022 that will close this issue
@amilan17 amilan17 moved this from Validated to Ready for FT Approval Procedure in BUFR4 Amendments May 27, 2022
amilan17 pushed a commit that referenced this issue May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
BUFR4 Amendments
Ready for FT Approval Procedure
Development

Successfully merging a pull request may close this issue.

4 participants