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, <[email protected]> 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: [email protected] > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
