[gdal-dev] Changes to NetCDF driver between 3.2 and 3.4 ?

Paul Harwood runette at gmail.com
Fri Oct 7 05:29:43 PDT 2022


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 <tsvibar at 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 at RMS:Kinneret$ gdalinfo --version
> GDAL 3.2.2, released 2021/03/05
> micha at 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 at RMS:Kinneret$ conda activate geo
> (geo) micha at RMS:Kinneret$ gdalinfo --version
> GDAL 3.5.2, released 2022/09/02
> (geo) micha at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221007/88634dff/attachment.htm>


More information about the gdal-dev mailing list