[gdal-dev] Changes to NetCDF driver between 3.2 and 3.4 ?
Even Rouault
even.rouault at spatialys.com
Fri Oct 7 05:31:31 PDT 2022
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 extra checks. See https://gdal.org/drivers/raster/netcdf.html
To have GDAL properly recognize the X/longitude & Y/latitude axis as
such, the
https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html
should be followed. So have long_name, standard_name and units set on
the variables associated with the dimensions such as
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:standard_name = "latitude" ;
float lon(lon) ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:standard_name = "longitude" ;
or
double y(y);
y:units = "km";
y:long_name = "y coordinate of projection";
y:standard_name = "projection_y_coordinate";
double x(x);
x:units = "km";
x:long_name = "x coordinate of projection";
x:standard_name = "projection_x_coordinate";
Even
Le 07/10/2022 à 14:03, Micha Silver a écrit :
>
> 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
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221007/f26eeead/attachment-0001.htm>
More information about the gdal-dev
mailing list