-
Notifications
You must be signed in to change notification settings - Fork 17
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
implement ODIM BUFR readers #101
Comments
@jfigui Thanks for bringing this to attention. wradlib used to read BUFR back in the old days, but dropped support because of all kind of issues. The bufr related python ecosystem evolved much since then, so this might not be an issue any more. If you can point to some resources on how to read french bufr data that would be great. Also docs on how to handle tables etc. would be nice to have. |
you probably know that but there are resources linked to OPERA Bufr here: In particular: https://www.eumetnet.eu/wp-content/uploads/2017/03/bufr_3.2.zip I can probably send you some examples of polar volume bufr files as well if needed. |
Yeah, but good it's now linked here. I've thought there would be some low hanging fruit with new packages like pdbufr or even directly with eccodes. The code on that eumetnet-page is rather old, unfortunately. It would be great if you could provide some bufr polar volumes. Do they need special tables or can they be read with the standard tables? |
I think French data need special tables. What I positively know is that eccodes cannot open the polar volume bufr data directly (I tried). I have always tried to stay away from BUFR files so I am definitely not an expert but I will ask for support at MF. |
I attach a copy of the tables that are used at Météo-France |
and here there is an example of so called PAM file:
|
here there is an example of so called PAG file, these files are sent to the OPERA data center:
|
One thing to keep in mind is that as far as I understood those files are not a single bufr file with multiple fields but a concatenation of bufr files. To be able to decode them properly you have to first cut the file and then read the bufr. |
I feel like I'm remembering now, why we've dropped bufr in wradlib 😬 |
I can fully understand your decision! |
If at first you don't succeed... |
I am wondering if this might be of use here |
Last time I checked trollbufr was not able to decode the Météo France BUFR. Among other things it was not prepared to read BUFR version 2 or 3 but it can be starting point. |
There's also pybufrkit, which might be worth a test. |
Hey everyone, have we had any success in this field ? I recently received a load of bufr radar files from météofrance, and I'm having little to no success in reading them with pybufrkit or even the opera bufr linux software listed in one of the comments up there. For me it is quite important and necessary to read these files and I use a python environment, if someone could give me any clues of how to move forward, I'll gladly be implementing a reader to use in an xarray environment. If someone advanced on this we could work together. I've attached a data sample and the tables they sent me. Thanks in advance! |
No, there haven't been any advances here. The major pain point is, and this is a show stopper, that the provided tables are in some ".csv" format. Please ask your table provider to provide the tables in ECMWF |
I am having a similar problem with some sample BUFR files I had from Météo-France. |
@Francesco-Uboldi Are your MF tables the same as linked above by @jfigui and @rzambranap? And would you join a team to implement an |
I have version 279 instead of 281... I will try the 281 from @rzambranap . |
@Francesco-Uboldi As I see the situation it all depends on the tables. We would need those tables in the format accepted by |
Hey everyone, I wasn't able to implement something on Python, but I was
able to sort it out via Python using the subprocess library, calling the
installed BUFR software locally. Two caveats: I couldn't launch it on VMs,
and there was something about 32 vs 64-bit architecture that somehow worked
on my PC but not on my office's servers. I can send you the tables
Météo-France sent to me and the functions I did in Python calling
subprocess and everything, but it's not up to the standards you might be
accustomed to...
…On Wed, Dec 13, 2023 at 10:06 AM Kai Mühlbauer ***@***.***> wrote:
@Francesco-Uboldi <https://github.com/Francesco-Uboldi> As I see the
situation it all depends on the tables. We would need those tables in the
format accepted by eccodes. Or there would need to be some transformation
tool to convert the tables. It's a pity that BUFR data is so unaccessible.
—
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AO6FHGG2GQ5OLQG2IZX2B3LYJFVYTAVCNFSM6AAAAAAWDTIYCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTGUZDCOBWHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Rodrigo Zambrana
|
At the last OPERA ET meeting it emerged that there is a real interest for xradar to have and ODIM BUFR reader, in particular to read the French radar data.
I am fully aware that that is not an easy task but considering that there are plans to open the OPERA data archive and that, particularly at the early stages of the OPERA program, many files are in BUFR format this would be very welcomed by the European radar community.
The text was updated successfully, but these errors were encountered: