Thanks
to all who took the time to answer.
Just to
close off this thread, here's the code that created a CF
compliant NetCDF that GDAL >3.4 could read:
DS.rio.write_crs(f'EPSG:{projected_epsg}',
inplace=True
).rio.se
Hi Micha,
I answered the question on stackex change. Essentially, you have to provide
the CF axis metadata now. This can be addressed in rioxarray using
rio.write_coordinate_system.
Hopefully this is helpful,
Alan
On Fri, Oct 7, 2022, 7:04 AM Micha Silver wrote:
> Hello:
>
> I'm using xarray a
Yes the netCDF driver in GDAL 3.4.2 is much stricter on what it assumes
to be axis compatible of a geotransform (there were false positives now).
You can set the GDAL_NETCDF_IGNORE_XY_AXIS_NAME_CHECKS configuration
option or IGNORE_XY_AXIS_NAME_CHECKS open option to YES to remove those
new ext
I might not be this but I remember coming across something similar in the
tests for MDAL and it came down to this PR (I think it was this one)
https://github.com/OSGeo/gdal/pull/5521
Basically - before GDAL was not reading all CRS metadata and after the
change it is reading the CRS data more corre
Hello:
I'm
using xarray and rioxarray in python to create a DataSet then
export to Netcdf. After saving, when I check the exported
files with gdalinfo using GDAL 3.2, I see the correct extent.
However, when using GDAL >=3.4 (i.e in a conda env)