Add GNSSRO bufr2ioda and json files

[XuanliLi-NOAA]

Description

Add JSON and bufr2ioda python scripts for GNSSRO data. Each GNSSRO mission has a separate ioda obs file.

Companion PRs

N/A

Issues

Refs #750

Automated CI tests to run in Global Workflow

• atm_jjob
• C96C48_ufs_hybatmDA
• C96C48_hybatmaerosnowDA
• C48mx500_3DVarAOWCDA
• C48mx500_hybAOWCDA
• C96C48_hybatmDA

[CoryMartin-NOAA]

Should these go in here or in spoc? @emilyhcliu what are your thoughts?

[emilyhcliu]

@CoryMartin-NOAA
The json and Python scripts in this PR are written in bufr-query low-level Python API.
These are good to use with the current setup in GDASApp. So, they should be checked in here in GDASApp so Xuanli can keep track of changes and repeat her tests.

In the meanwhile, @nicholasesposito will create these low-level Pythons into one Python script with high-level API and mapping files. These will be checked into SPOC.

Once we have most of the Python Script, mapping files in SPOC, we will work on GDASApp to use them from SPOC.

[CoryMartin-NOAA]

ok sounds good thanks @emilyhcliu I just wanted to double check

[CoryMartin-NOAA]

a few minor comments, and I didn't closely look at the converters but assume they have been thoroughly tested

[emilyhcliu]

@XuanliLi-NOAA one question.
Is it possible to write one Python to convert all platforms?
GPSRO data is in one subset. It should be possible to write one Python to handle all platforms.
Are these platforms using the same BUFR table?

No worries, what you have in this PR is OK. But. we should try to create one Python script with high-level Python API for GPSRO.
@nicholasesposito will work with you on this.

[XuanliLi-NOAA]

@emilyhcliu , it would be great to have one Python script to convert all platforms. Yes, let's do that with the with high-level Python API.

[emilyhcliu]

@emilyhcliu , it would be great to have one Python script to convert all platforms. Yes, let's do that with the with high-level Python API.

Do all GPSRO platform use the same bufr table?

[XuanliLi-NOAA]

@emilyhcliu, yes, for the test date 00z 2024-02-19, they use the same bufr table. But after June 2024, we have new EUMETSAT Spire data, this has an additional BUFR mnemonic "SASBID". Should we consider that in the high level python API?

@XuanliLi-NOAA Yes, we should include the new one. It is good that all platforms share the same bufr table mnemonics. We can have one mapping file to handle all of them. So, the one Python script with high-level API should be doable for GPSRO.
Thanks for the information.

@emilyhcliu Sounds good, thank you for confirming that.

[nicholasesposito]

Recommend changing the global attributes, but @emilyhcliu should comment on that. The rest looked fine with the exception of I think changing the data_format description.

[XuanliLi-NOAA]

@emilyhcliu and @nicholasesposito data_provider has been corrected in the json files to reflect the actual originating center. data_format has been changed to dataOriginalFormatSpec in the python scripts. I'm not sure if we should replace subsets with platforms, as subsets is a bufr message for the name of the subset.

[nicholasesposito]

I think just clean up some of the comments unless they are needed. Otherwise no glaring issues from me. Looks very complicated so thank you for taking the time to do all this!

[XuanliLi-NOAA]

@nicholasesposito @emilyhcliu Thank you so much, Nick. I cleaned up the python scripts and also uncommented mefr1 to maintain consistency with the other variables.

[nicholasesposito]

Approved.