-
Notifications
You must be signed in to change notification settings - Fork 27
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
Allow "radian" as a possible value for the X/Y dimension units. #122
Comments
magau
added a commit
to magau/adaguc-server
that referenced
this issue
Dec 20, 2019
maartenplieger
added a commit
that referenced
this issue
Jan 14, 2020
Allow "radian" as a possible value for the X/Y dimension units. #122
belentorrente
pushed a commit
that referenced
this issue
Jul 6, 2022
belentorrente
pushed a commit
that referenced
this issue
Jul 6, 2022
Allow "radian" as a possible value for the X/Y dimension units. #122
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
adaguc-server/CCDFDataModel/CProj4ToCF.cpp
Line 52 in 9d4dd62
According with the Unidata udunits documentation for naming units, the value "rad" is used as a radiation unit for "absorbed dose".
Thus the value "rad" for radian unit shouldn't be used. Instead, the correct value should be "radian".
As one can see in the following doc:
https://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt
Besides, the GDAL and the netcdf-java libraries are already supporting the "radian" units for the "geostationary" projection coordinates. This would make the things easier for the data providers that are using the "geostationary" projection, in order to build their netCDF files compatible with the most of the softwares. Including yours...
In order to solve this issue I'd suggest the value "radian" to be added as a possible value for the X/Y axis/coordinates unit. (The value "rad" also should be allowed, to keep retro-compatibility...)
Regards João
The text was updated successfully, but these errors were encountered: