<div dir="ltr">Thanks Even, that's excellent.<br><br>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). <br><br>Extending GDAL has more positive impact (for me at least) as the heuristics will catch many other products. <br><br>Best, Mike<br><br><br>On Tue, 15 Mar 2022, 22:38 Even Rouault, <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> Michael,<br>><br>> Le 15/03/2022 à 06:06, Michael Sumner a écrit :<br>><br>> Hi, <br>><br>> 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'<br>><br>> <a href="https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/">https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/</a><br>><br>> An example sds specifically: <br>><br>> /vsicurl/NETCDF:"/vsicurl/<a href="https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/202202/oisst-avhrr-v02r01.20220201.nc">https://www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/202202/oisst-avhrr-v02r01.20220201.nc</a>":sst<br>><br>> 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).<br>><br>> I wouldn't expose WGS84 by default, because it might be another Earth geographic CRS, or even a non-Earth geographic CRS.<br>><br>> Potential solution:<br>><br>> - 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.<br>><br>> - 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.<br>><br>> e.g (not sure my set of "matching_attributes" is appropriate for your use case)<br>><br>> {<br>> "product_type": {<br>> "noaa_ncei_oisst": { // the id of the product here is completely arbitrary<br>> "defining_global_attributes": {<br>> "title": "NOAA/NCEI 1/4 Degree Daily Optimum Interpolation Sea Surface Temperature (OISST) Analysis, Version 2.1 - Final",<br>> "geospatial_lat_units": "degrees_north",<br>> "geospatial_lon_units": "degrees_east"<br>> },<br>> "default_values": {<br>> "crs": "EPSG:4326"<br>> }<br>> }<br>> }<br>><br>> }<br>><br>> - or, both the easiest and hardest one, convince the data producer to just use the netCDF CF conventions to their full capabilities.<br>><br>> Even<br>><br>><br>> (It's not out of the question that I could submit a PR for this, just flagging discussion in case I'm missing something.)<br>><br>> Thanks. <br>><br>> Best, Mike<br>><br>><br>> --<br>> Michael Sumner<br>> Software and Database Engineer<br>> Australian Antarctic Division<br>> Hobart, Australia<br>> e-mail: <a href="mailto:mdsumner@gmail.com">mdsumner@gmail.com</a><br>><br>> _______________________________________________<br>> gdal-dev mailing list<br>> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>><br>> -- <br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a><br>> My software is free, but my time generally not.
</div>