Tests failing after build with GDAL 3.5.0

[runette]

The NetCDF tests are failing after MDAL is built using GDAL 3.5.0 in Conda-Forge.

The results can be seen here
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=515809&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d&l=2279

[runette]

Looks like this command is producing a different result with GDAL3.5

MDAL/tests/test_gdal_netcdf.cpp

Line 155 in bff65e8

MDAL_M_extent( m, &minX, &maxX, &minY, &maxY );

[runette]

From Changelog for GDAL3.5

netCDF driver:

• handle 'crs_wkt' attribute
  *always use WKT when found, without comparing with CF params (#4725)
• limit SetFromUserInput() use to non file input
• disable filename recoding to ANSI on Windows for netCDF >= 4.8
• add WRITE_GDAL_VERSION and WRITE_GDAL_HISTORY creation option
• add a VARIABLES_AS_BANDS=YES/NO open option
• allow update mode of raster datasets
• implement SetMetadataItem()/SetMetadata()
• avoid warnings when CreateCopy() a non-georeferenced dataset, and opening a 1x1 non-georeferenced dataset
• add a IGNORE_XY_AXIS_NAME_CHECKS=YES open option (QGIS 3.22 wrongly displays raster qgis/QGIS#47158)
• recognize x/y axis from GMT generated files as geospatial axis (#5291, QGIS 3.22 wrongly displays raster qgis/QGIS#47158, Bug importing .grd (netcdf) DEM files qgis/QGIS#45704)
• read CF attributes giving CRS component names (#5493)
• add support for writing/reading geolocation array without a grid_mapping variable

I am wondering about the CRS changes ...

[runette]

Yep - under GDAL3.5 gdalinfo on nonConstitentDataset.nc reports

Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,   15.0)
Upper Right (   25.0,    0.0)
Lower Right (   25.0,   15.0)
Center      (   12.5,    7.5)

whilst under GDAL3.4 it reported

Corner Coordinates:
Upper Left  (  351958.200, 6690978.800) (  1d36' 8.33"W, 47d13'40.07"N)
Lower Left  (  351958.200, 6690971.300) (  1d36' 8.31"W, 47d13'39.83"N)
Upper Right (  351970.700, 6690978.800) (  1d36' 7.73"W, 47d13'40.09"N)
Lower Right (  351970.700, 6690971.300) (  1d36' 7.71"W, 47d13'39.85"N)
Center      (  351964.450, 6690975.050) (  1d36' 8.02"W, 47d13'39.96"N)

@PeterPetrik - don't know how you want to deal with this. The change comes from OSGeo/gdal#4734 and it does not look like there is a config item to revert to legacy beahviour

[PeterPetrik]

I think we may need if-else in your code to work with pre 3.5 and post 3.5 GDAL releases differently

MDAL_M_extent should probably report the same for both versions

[runette]

@PeterPetrik I must admit I have a slightly different opinion - in my mind the statement of compliance should be "MDAL gives the same result as GDAL". If the GDAL result (and thus the QGIS) result changes between major versions then so should the MDAL result and at least then the results in a given environment are consistent.

I think that any other approach just creates an ongoing problem of consistency and support. There will be issues for ever asking why GDAL and MDAL say different things in certain circumstances. There will also be not inconsiderable work to out how to make the GDAL 3.5 results look like GDAL 3.4 results (or vice versa).

I would say that it is the TEST that should be changed to be based upon the GDAL version.

However - ultimately it is your call.

[PeterPetrik]

I am easy both ways, both have some positives and negatives.

@vcloarec what do you think?

[vcloarec]

I would agree with @runette , I think it is better to have a consistent behavior with GDAL than with old version of MDAL.
That is quite similar with #391.

Here, I am wondering about the meaning of the new extent here...

[runette]

Here, I am wondering about the meaning of the new extent here...

I was too - it looks like 3.5 is in some sort of local projected CRS while 3.4 is picking up some sort of UTM-like projected CRS but the units of the 3.5 local CRS are exactly half the size of the units of the 3.4 CRS ...

I am guessing that the WKT in the file has a different CRS to the CF Params??

which is another reason for not trying to reverse engineer

[runette]

Joy of joys. This behaviour seems to revert in GDAL 3.6! I will try to push a PR that disables this test just for GDAL 3.5