[gdal-dev] regular grid longlat netcdf without crs meta

[Michael Sumner]

Thanks Even, that's excellent.

I agree about the providers, and I inform them (the OISST project replied
with a promise to fix in future. I wish they and many others would catch on
to how terrible NetCDF is for 2D regular grids and just use good geotiffs
but hoo boo whoa).

Extending GDAL has more positive impact (for me at least) as the heuristics
will catch many other products.

Best, Mike


On Tue, 15 Mar 2022, 22:38 Even Rouault, <even.rouault at spatialys.com> wrote:
>
> Michael,
>
> Le 15/03/2022 à 06:06, Michael Sumner a écrit :
>
> Hi,
>
> these files don't present to GDAL with a CRS, but it seems not out of
place to assume that they can use 'oSRS.SetWellKnownGeogCS("WGS84")', when
no other indication is found and there are dimensions 'lon,lat' or
'longitude,latitude'
>
>
https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/
>
> An example sds specifically:
>
> /vsicurl/NETCDF:"/vsicurl/
https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/202202/oisst-avhrr-v02r01.20220201.nc
":sst
>
> Would that be reasonable? Perhaps controlled by an env var? Is there an
established control for this I'm missing? (I'm not looking for '-a_srs' or
VRT, I want the auto-detection to work for these and many other similar
file sources without augmentation).
>
> I wouldn't expose WGS84 by default, because it might be another Earth
geographic CRS, or even a non-Earth geographic CRS.
>
> Potential solution:
>
> - add a GDAL_NETCDF_DEFAULT_GEOGRAPHIC_CRS configuration option (that
could be set to EPSG:4326 e.g) that would be used in the situation where
the netCDF CF attributes to define a geographic CRS, but without the actual
CRS definition, are not set.
>
> - or, more involved but more powerful, add a configuration file in data/
, let's say a netcdf_product_conf.json or whatever, where you would define
a set of product types, with matching global attributes and their values
and the corresponding CRS.
>
> e.g (not sure my set of "matching_attributes" is appropriate for your use
case)
>
> {
>     "product_type": {
>         "noaa_ncei_oisst": {  // the id of the product here is completely
arbitrary
>             "defining_global_attributes": {
>                 "title": "NOAA/NCEI 1/4 Degree Daily Optimum
Interpolation Sea Surface Temperature (OISST) Analysis, Version 2.1 -
Final",
>                 "geospatial_lat_units": "degrees_north",
>                 "geospatial_lon_units": "degrees_east"
>             },
>             "default_values": {
>                 "crs": "EPSG:4326"
>             }
>         }
>     }
>
> }
>
> - or, both the easiest and hardest one, convince the data producer to
just use the netCDF CF conventions to their full capabilities.
>
> Even
>
>
> (It's not out of the question that I could submit a PR for this, just
flagging discussion in case I'm missing something.)
>
> Thanks.
>
> Best, Mike
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220316/c530b208/attachment.html>