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
Support GRIB2 DRS 42 #753
Comments
Also, it seems that this issue involves use of a Lambert Conformal Conic projected grid. Note that I posted an issue two years ago involving use of a Lambert Azimuthal Equal Area projected grid, although that manifested as an inability to even open the dataset. See #22. |
Usually a DRS isn't implemented due to lack of a sample file. That said, DRS 42 looks to be pretty complicated: https://library.wmo.int/doc_num.php?explnum_id=10722 (pdf page 132) Let me see if there is a java port of |
Oh, ugh. Looking at that PDF page. 😱 |
Ping! I just had another request for DRS 42 from a developer at ECMWF. |
Thanks for chasing this up. From cycle 48R1 ECMWF data by default will use CCSDS packing ( for gridded fields ) |
Ping! I just had yet another query about DRS 42 from someone trying to work with ECMWF data. |
@rschmunk it would be great to have this, but unfortunately our dev teams hands are really full right now, so unless we get some outside help on this issue, it's not going to make it to the top of the TODO list for a while. |
Unfortunately, as @lesserwhirls pointed out, this one looks like a hairball. Maybe some ECMWF person will get attached to the issue and write some code? |
GRIB2 DRS 42 support request + 1. |
Another GRIB2 DRS 42 support request here, thanks. |
@haileyajohnson, I hate to say it but I just heard from another user whose ability to view ECMWF data has been crippled because ECMWF is now shipping the product using data representation 42. Edit: This looks like the same or related product as what @shahramn mentioned on Feb. 20. |
So I 100% hear that this is becoming a major issue. The problems we previously listed though still remain. I think this is going to involve us doing some major work on compression in general in netcdf-java, which wouldn't be the worst thing. I don't know how long it would take to plan/design/develop though, so I guess my question is what is the impact to everyone +1ing this issue if it takes 3/6/9 months before we're able to ship this as a feature? |
GRIB2 DRS 42 support request + 1 |
You could always convert the CCSDS GRIB ( gridded ) fields back to Simple Packing. E.g.,
Of course it would be fantastic if Panoply could decode such GRIBs but this is a temporary solution |
Ive been using https://openjdk.org/jeps/434 "JEP 434: Foreign Function &
Memory API" in Java 20, and it works well and seems to solve most of the
problems with jni/jna. One could use it to wrap libaec.
…On Mon, Jul 31, 2023 at 6:58 AM shahramn ***@***.***> wrote:
You could always convert the CCSDS GRIB ( gridded ) fields back to Simple
Packing. E.g.,
via the ecCodes grib_set command-line tool
grib_set -r -w packingType=grid_ccsds -s packingType=grid_simple ccsds.grib grid_simple.grib
—
Reply to this email directly, view it on GitHub
<#753 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEVZQESMJ247YIDHRZO24TXS6TWNANCNFSM475YCZOQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Dear John, |
That's kinda the direction we're leaning, but currently netcdf-java is committed to supporting jdk-8. What we're considering is putting new features that require higher java versions in a different subproject, and encouraging people to use a later java version to get those features. |
GRIB2 DRS 42 support request + 1 |
Seems like for some, compiling libaec and running Java 20 might be worth it for getting access to DRS 42 from netcdf-java. What do you think, @DennisHeimbigner ? Im not seeing any java ports available. |
According to this page: https://gitlab.dkrz.de/k202009/libaec, So, it is barely possible that this could replace libaec. |
This seems to be a problem with 5.4-MAINT up to the current (7?) development branch.
A user sent me a GRIB2 file that netCDF-Java will open, but when one then tries to extract a variable, an "Unsupported DRS type = 42" exception is thrown by the
Grib2DataReader.factory
method. (But note that the same exception could be thrown byGrib2DataReader.getData
.)Comparison of the switch statements in these methods to ECMWF's data representation template list, several such templates are not handled. But for the moment, 42 is the one of concern.
A stack trace is appended (using 5.4-MAINT), but note that the line numbers in
Grib2Drs
andGrib2DataReader
are slightly off as I inserted some logging.A sample file that demonstrates the problem is here on Dropbox.
The user also comments that: "As far as I have understood, this file has been generated by using ECMWF's ECCODES library and it originates from MetCoOp (251) center."
--
The text was updated successfully, but these errors were encountered: