> Some formats have a pretty good easy way of telling which way to go about > upperleft or center pixel coordinate. But that is not the case with > "flexible" formats like the ones above.
The CF conventions apply here. Also that http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html says is "If bounds are not provided, an application might reasonably assume the gridpoints to be at the centers of the cells, but we do not require that in this standard." And that's what GDAL does. It assumes that the values of the lat, lon variables are center of cells coordinates, hence the half pixel shift to go back to GDAL topleft corner convention > What is interesting in that case is that one can say that according to the > documentation the driver is correct. The -180,80 coordinate is in the > center of the pixel. But when putting that date to real use, that seems to > be incorrect. The products are not self consistent if you consider the crs:GeoTransform property, the documentation of the product and the actual values of the lon, lat arrays ncdump shows: lon = 120960 ; crs:GeoTransform = "-180.0000000000 0.0029761905 0.0 80.0000000000 0.0 -0.0029761905" ; lon = -180, -179.997023809524, ... , 179.994047620685, 179.997023811161 Normally in GDAL, the GeoTransform origin is the topleft corner, not the pixel center. I think clarificiation should be sought after the data producer to find: - what is the intended registration of their product ? - and that they fix either their GeoTransform or their lon, lat arrays to be consistent. > The half pixel shift grows as you go > east. I don't get this. The spacing of values in the lon array seems constant, so the shift if any should also be constant. > If I have some time, I will try to run the NetCDF driver in step-by-step > debugging mode to see exactly how the crs:GeoTransform is (mis)handled. The logic of the driver is to use the GeoTransform if it can derive one from the lon, lat variables. See https://github.com/OSGeo/gdal/blob/master/gdal/frmts/netcdf/netcdfdataset.cpp#L3776 Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
