NETCDF: SRS for geolocation array is hardcoded (?)

[mdsumner]

What is the bug?

This NetCDF has a spherical longlat crs in "crs_wkt", but I believe the NetCDF driver hardcodes WGS84 as the geolocation SRS:

gdalinfo /vsicurl/https://github.com/rgdal-dev/rasterwise/raw/master/data-raw/spherical.nc

...
Geolocation:
  SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]
  X

Steps to reproduce the issue

I believe it is hardcoded here:

gdal/frmts/netcdf/netcdfdataset.cpp

Line 4805 in 35c4345

"SRS", SRS_WKT_WGS84_LAT_LONG, "GEOLOCATION");

I think the SRS for Geolocation for this file should be

"GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"unknown\",6378137,0]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Longitude\",EAST],AXIS[\"Latitude\",NORTH]]"

The file spherical.nc creation is listed here: https://gist.github.com/mdsumner/d81abf97de98aaccff7269a7d2a5ebf5

Versions and provenance

linux build at d67906c

[mdsumner]

excellent, thanks Even - confirmed this works as expected now.

Can we have geolocation arrays that are in arbitrary CRS? My initial test ends up with a EPSG:9122 overriding my 'crs_wkt' , I'll check more carefully - but is arbitrary CRS here expected to work? (I guess that's what "its geographic part" means? We are only using the datum? and the arrays must be longlat?)

[rouault]

EPSG:9122

You likely mistyped the code: there's no such EPSG CRS. With your test case, I believe the reported GEOLOCATION.SRS with my fix was your crs_wkt, isn't it?

but is arbitrary CRS here expected to work? (I guess that's what "its geographic part" means? We are only using the datum? and the arrays must be longlat?)

For some reason, GDAL requires variables to be identified as longitude / latitude to decide to use them as a geolocation array (I guess in theory this could be something else, but that would require we don't misrecognize non-geo coordinate variables... hence probably that restriction, as this is the most common use case). Hence I've decided to extract the geographic CRS from the full CRS, in the situation where the raster would for example be in a projected CRS, with associated long / lat variables. But I'm realizing now that in that situation we wouldn't expose a geolocation array at all, so this extraction of the geogrpahic CRS from the full CRS might not be needed after all. I don't think it hurts though.. Not sure... All those coordinate variables potential coexisting together in the same file is a headache...

[mdsumner]

Indeed I'm having trouble crafting files that isolate the behaviour I want.

This issue is fixed.

Your fix is right in the case I reported, I'm just trying a new thing which probably doesn't exist in the real world, and I've noticed some behaviours by GDAL that I didn't expect and need to spend more time on, and think about your comments here more too. 👌