satpy_cf_nc reader fails to read area written by cf writer for projections not supported by CF conventions #2226
Comments
|
If I try |
|
If I try the built-in area |
|
Temporarily replacing |
|
That grid mapping variable looks like it is missing a lot of parameters it is supposed to have. |
|
Right, when I try to use |
|
Before saving to netcdf, what do |
For For |
|
Is all this extra information actually necessary, though? Isn't that redundant compared to a WKT that should fully describe the area? also contains only one key in the grid mapping dict. |
|
Interesting. That definitely seems like a bug in pyproj or maybe something explicitly not supported, but the proj dict for that worldeqc30km is nothing special. |
|
@snowman2 I can't seem to get pyproj CRS to give me a full grid mapping for the |
|
Yep, that's it @gerritholl. https://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/apf.html https://github.com/pyproj4/pyproj/blob/main/pyproj/crs/_cf1x8.py So the question is: Should the CF->AreaDefinition conversion in pyresample accept this and fallback to use the crs_wkt? Or should the CF writer in Satpy fail if it detects that the CRS is not CF (1.7?) compliant? |
@gerritholl the question is what is CF compliant and what do we support? I think @snowman2 has argued with the CF folks for a while now that WKT is how they should be describing their CRSes and not having to manually add new projections with new parameter/attribute names for each new revision of the CF standard (we don't need yet another way of describing CRSes, PROJ has enough as it is). I think the pyresample library could be updated to accept/understand this case and return an AreaDefinition with a CRS purely from the crs_wkt information. |
It would seem that the grid mapping returned by pyproj is not CF-compliant for CRS 4087, which is why the round-trip fails between the For other CRSes, such as CRS 4326, pyproj does return a grid mapping including other keys. |
It does a best effort. If the CF grid mapping does not exist, the |
|
The incomplete CF grid mapping is not the full story. Even if the CF grid mapping has more attributes, satpy may fail to read it. Example with EPSG 4326: |
|
For EPSG 4326 the problem is different. The |
|
Digging into this some more, it seems that EPSG 4087 (equirectangular cylindrical projection) isn't supported by the CF Conventions, and therefore, writing a CF conform file with this projection is not possible. https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#appendix-grid-mappings |
|
Should the cf writer raise a warning or an exception when the user attempts to write data that cannot be written in a CF-conform way? |
|
I'd say warning if we don't want any new keyword arguments. We shouldn't stop anyone from producing a file unless they have a keyword argument to allow a less-strict CF check. There is a https://satpy.readthedocs.io/en/stable/_modules/satpy/writers/cf_writer.html#area2cf |
gerritholl
changed the title
Describe the bug
I'm writing a data variable to a NetCDF file using the cf writer, then reading it with the satpy_cf_nc reader. Upon reading, no area information is available.
To Reproduce
Expected behavior
I expect all area/geolocation information to be retained.
Actual results
The writtes has written a NetCDF file that contains a data variable
wcm40kmwith an attributecrs_kwtthat contains area metadata, but thesatpy_cf_ncreader does not appear to find this. Full output from the MCVE:Headers of the NetCDF file:
Environment Info:
The text was updated successfully, but these errors were encountered: