NetCDF/vrt: config assume longlat case "nearly" in bounds

[mdsumner]

this dsn sits slightly outside the bounds for GDAL_NETCDF_ASSUME_LONGLAT:

/vsicurl/https://dapds00.nci.org.au/thredds/fileServer/gb6/BRAN/BRAN2020/annual/ocean_mld_ann_2012.nc

and, modifying that with vrt: doesn't fix it because the behaviour is in the NetCDF driver not in VRT

gdalinfo --config GDAL_NETCDF_ASSUME_LONGLAT YES vrt:///vsicurl/https://dapds00.nci.org.au/thredds/fileServer/gb6/BRAN/BRAN2020/annual/ocean_mld_ann_2012.nc?a_ullr=0,75,360,-75
 -nomd

## no CRS!

This issue is a todo for @mdsumner

• [ ] consider a slight adjust to the strict -180,360 bounds for GDAL_NETCDF_ASSUME_LONGLAT
• [ ] make the VRT reader also understand the config for assuming longlat
• [ ] can we tweak the logic in the numeric arrays to determine when the intention was clearly to be a regular grid in 0,360? ote that the lat range is slightly off -75,75 too

[rouault]

and, modifying that with vrt: doesn't fix it because the behaviour is in the NetCDF driver not in VRT

This is also an option, so "?oo=ASSUME_LONGLAT=YES". But this won't help here with the logic in the netCDF driver.

You could modify the logic as below so that:

• if the user specifies ASSUME_LONGLAT=YES, you trust her without checking the bounds
• if she doesn't specify anything, you do bounds checking
• if she specifies ASSUME_LONGLAT=NO, you don't do it

const char* pszLongLat = CSLFetchNameValueDef(
                papszOpenOptions, "ASSUME_LONGLAT",
                CPLGetConfigOption("GDAL_NETCDF_ASSUME_LONGLAT", nullptr));
const bool bForcedLongLat = pszLongLat && CPLTestBool(pszLongLat);
const bool bDisallowedLongLat = pszLongLat && !CPLTestBool(pszLongLat);
 if (bForcedLongLat || (!bDisallowedLongLat && adfTempGeoTransform[0] >= -180 &&
                adfTempGeoTransform[0] < 360 &&
                (adfTempGeoTransform[0] +
                 adfTempGeoTransform[1] * poDS->GetRasterXSize()) <= 360 &&
                adfTempGeoTransform[3] <= 90 && adfTempGeoTransform[3] > -90 &&
                (adfTempGeoTransform[3] +
                 adfTempGeoTransform[5] * poDS->GetRasterYSize()) >= -90))

Adding some tolerance on the bounds checking seems reasonable too