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

Micha Silver Fri, 07 Oct 2022 07:27:25 -0700

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.set_spatial_dims(x_dim="x", y_dim="y", inplace=True
).rio.write_coordinate_system(inplace=True)

(DS is the xarray DataSet, and projected_epsg is the EPSG code for the CRS used here)

On 07/10/2022 15:31, Even Rouault wrote:

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@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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-- 
http://www.spatialys.com
My software is free, but my time generally not.

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

Reply via email to