Feature request: workaround regular gridded OISST NetCDF files with no SRS-info

[mdsumner]

These NetCDF files don't provide a compliant SRS, the OISST files have no “grid_mapping” variable, so GDAL can't auto-determine the coordinate system used by the sst, ice, anom, and err subdatasets.

https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/

I obtained an example file (and attached here) from this link

https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/202202/oisst-avhrr-v02r01.20220218.nc

oisst-avhrr-v02r01.20220218.nc.zip

That file is 1.5Mb, zipped only to get around the allowed GH extensions thing.

Steps to reproduce the problem.

gdalsrsinfo NETCDF:"oisst-avhrr-v02r01.20220218.nc":sst
ERROR 1: ERROR - failed to load SRS definition from NETCDF:oisst-avhrr-v02r01.20220218.nc:sst

system

Ubuntu 20
GDAL 3.6.0dev-298705c2af, released 2022/08/12 (debug build)

I assume GDAL could allow heuristics to provide a fall-back to "OGC:CRS84", because it's clearly basic longitude/latitude grid. I intended to PR this but I get lost in the size of the NetCDF driver, and this might be pretty easy with more experience 🙏

(I also have quite a few examples of similar sources that GDAL could augment by internal logic, so if this is of interest there's quite a range of similar examples for georeferencing and CRS that might fall into categories of similar kinds)

The motivation for us (for interested readers) is to remove augmenting-logic from within R, if GDAL auto-detects this case then we can simplify the code, alternatively we could:

• generate VRT strings to do it, but opening the source is expensive and the VRT text is large
• wrap in vrt://<dsn>?a_srs=OGC:CRS84, upcoming in GDAL 3.7.0

If the provided files were compliant

To demonstrate the fix required at the provider level, I created a new file.nc that adds the scalar ‘crs’ var with attributes, and this is pointed to by new attributes ‘coordinates’ and ‘grid_mapping’ from the 4D variables that use ‘lon’ and ‘lat’. (I'm not sure if my fix is exactly appropriate in terms of SRS details here)

The modification steps for the repaired file, and more details about communication with the provider are here:

https://github.com/mdsumner/fixoisst

[mdsumner]

here is a another example, again very clearly could detect and assume "OGC:CRS84"

gdalinfo NETCDF:"/vsicurl/https://rsg.pml.ac.uk/thredds/fileServer/cci/v6.0-release/geographic/daily/chlor_a/2021/ESACCI-OC-L3S-CHLOR_A-MERGED-1D_DAILY_4km_GEO_PML_OCx-20210101-fv6.0.nc":chlor_a -nomd
Driver: netCDF/Network Common Data Format
Files: /vsicurl/https://rsg.pml.ac.uk/thredds/fileServer/cci/v6.0-release/geographic/daily/chlor_a/2021/ESACCI-OC-L3S-CHLOR_A-MERGED-1D_DAILY_4km_GEO_PML_OCx-20210101-fv6.0.nc
Size is 8640, 4320
Origin = (-180.000000000000000,90.000000000000000)
Pixel Size = (0.041666666666667,-0.041666666666667)
Corner Coordinates:
Upper Left  (-180.0000000,  90.0000000)
Lower Left  (-180.0000000, -90.0000000)
Upper Right ( 180.0000000,  90.0000000)
Lower Right ( 180.0000000, -90.0000000)
Center      (  -0.0000000,   0.0000000)
Band 1 Block=270x270 Type=Float32, ColorInterp=Undefined
  NoData Value=9.96921e+36
  Unit Type: milligram m-3

[mdsumner]

I've implented this in https://github.com/mdsumner/gdal/tree/netcdf_6195_assume_longlat

• apply a user-settable option to allow the assumed interpretation GDAL_NETCDF_ASSUME_LONGLAT=YES/NO (default NO)
• investigate behaviour on many netcdfs
• CI tests

[mdsumner]

I'm so happy about this one, thanks so much! I learnt heaps, your review process is extremely helpful!

[rouault]

great to have you as the new maintainer of the netCDF driver ! (just kidding... or not ;-))

[mdsumner]

Definitely more contributions to come 😅