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 correctly. I notice from the StackExchange post that you are defining the Spatial reference as UTM zone 36N (which is projected) but seem to be providing that individual coordinates as Lat Lng. I think the change in PR now means that GDAL is obeying the CRS you specified and trying to look at that data as being in UTM when it is not! It kind of makes sense of the messages you receive. On Fri, 7 Oct 2022 at 13:04, Micha Silver <tsvi...@gmail.com> wrote: > 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) it seems that the extents are lost, and the NetCDF > dimensions appear instead. This causes the resulting NetCDF to appear at > coords (0,0) - the wrong place - in QGIS (on a system with the newer GDAL). > > > Here is the output with my system installed GDAL: > > > micha@RMS:Kinneret$ gdalinfo --version > GDAL 3.2.2, released 2021/03/05 > micha@RMS:Kinneret$ gdalinfo NETCDF:"Kinneret_velocity.nc":v | grep -A 4 > Corner > Warning 1: dimension #2 (x) is not a Longitude/X dimension. > Warning 1: dimension #1 (y) is not a Latitude/Y dimension. > Warning 1: dimension #0 (z) is not a Time or Vertical dimension. > Corner Coordinates: > Upper Left ( 735758.000, 3644806.000) ( 35d31'15.70"E, 32d54'57.98"N) > Lower Left ( 735758.000, 3621606.000) ( 35d30'54.46"E, 32d42'25.30"N) > Upper Right ( 754558.000, 3644806.000) ( 35d43'18.74"E, 32d54'42.80"N) > > Lower Right ( 754558.000, 3621606.000) ( 35d42'55.82"E, 32d42'10.25"N) > > > However, in my conda environment, with a newer GDAL: > > > micha@RMS:Kinneret$ conda activate geo > (geo) micha@RMS:Kinneret$ gdalinfo --version > GDAL 3.5.2, released 2022/09/02 > (geo) micha@RMS:Kinneret$ gdalinfo NETCDF:"Kinneret_velocity.nc":v | > grep -A 4 Corner > Warning 1: dimension #2 (x) is not a Longitude/X dimension. > Warning 1: dimension #1 (y) is not a Latitude/Y dimension. > Warning 1: dimension #0 (z) is not a Time or Vertical dimension. > Corner Coordinates: > Upper Left ( 0.0, 0.0) > Lower Left ( 0.0, 58.0) > Upper Right ( 47.0, 0.0) > Lower Right ( 47.0, 58.0) > > What do I need to add to the xarray Dataset so that the newer GDAL gets > the correct extent? > > In both cases all the "grid_mapping" metadata entries point to > "spatial_ref", and the full spatial_ref details are available in the NetCDF > file. > > > (Note: double posted to GIS.stackexchange at > https://gis.stackexchange.com/questions/442323/changes-to-gdal-netcdf-driver-between-3-2-and-3-4 > ) > > > Thanks > > -- > Micha Silver > Ben Gurion Univ. > Sde Boker, Remote Sensing Lab > cell: +972-523-665918 > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev