[gdal-dev] NetCDF and ESA Probav issue with corner coordimates

[Ivan Lucena]

Even,

That confirms my suspicious. The NetCDF driver is fine and there is nothing to be added or changed.

> 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
> ...
> I think clarification 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.

I completely agree with you. I will pass that information to the data provider costumer services.

Thanks,

Ivan

________________________________
From: Even Rouault <even.rouault at spatialys.com>
Sent: Sunday, November 3, 2019 4:45 PM
To: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Cc: Ivan Lucena <ivan.lucena at outlook.com>; Andrew C Aitchison <andrew at aitchison.me.uk>; Richard Duivenvoorde <rdmailings at duif.net>
Subject: Re: [gdal-dev] NetCDF and ESA Probav issue with corner coordimates

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191105/ea40adb9/attachment.html>