[gdal-dev] NetCDF geotransform - pixel centre/upper-left issue

[Michael Sumner]

I believe that NetCDF generally uses cell centres to specify pixel
coordinates, and there is no way to specify cell corners except by
adding metadata about the actual dimensions boundaries (this is more
problematic again if coordinates are not regular since you cannot
assume a regular half cell).

My understanding is that GDAL assumes cell centres for NetCDF, and
from the data I've seen this is reasonable. The data model in NetCDF
is more general than GDAL in some ways and it's simply not possible to
answer this issue completely.  The unhappy news is that there is no
easy answer but IMO GDAL is not incorrect here.

In that example file the first longitude is 0 and all subsequent
values are regularly spaced from there up to one cell less than 360,
so the cell bounds at [0,360] are obvious - but this is not always the
case. The latitudes are not regular and what was intended cannot
always be determined in many cases (although in this file the
boundaries are fairly obviously at [-90,90] offset from the min/max
values of -87.8638  87.8638 )

For some more background there was a discussion about the possible
need for a distinction in NetCDF between cell and corner registration
here:

http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002721.html

In particular this statement is one confirmation I found of the lack
of cell/corner distinction apart from boundary metadata.

"Coordinate bounds allow edges to be explicit, and you could ask the
application developer to look
for those. When not specified, I put the edges halfway between the
coordinates."

Cheers, Mike.

On Tue, Apr 6, 2010 at 3:32 PM, Pinner, Luke
<Luke.Pinner at environment.gov.au> wrote:
> The NetCDF driver computes the pixel centre from lat/lon variables (see
> http://trac.osgeo.org/gdal/ticket/1506).
>
> Is this correct or should it compute pixel upper-left?
>
> Using the example NetCDF dataset attached to the above ticket
> (http://trac.osgeo.org/gdal/attachment/ticket/1506/out.nc), gdalinfo
> reports the min longitude value to be -1.40625 which is not a valid
> longitude (it's 1/2 a pixel less than 0 which is the min value in the
> NetCDF lon variable).
>
> gdalinfo out.nc
> $ gdalinfo -nomd out.nc
> Warning 1: Latitude grid not spaced evenly.
> Seting projection for grid spacing is within 0.1 degrees threshold.
>
> Driver: netCDF/Network Common Data Format
> Files: out.nc
> Size is 128, 64
> Coordinate System is `'
> Origin = (-1.406250000000000,89.258462312871046)
> Pixel Size = (2.812500000000000,-2.789326947277220)
> Corner Coordinates:
> Upper Left  (  -1.4062500,  89.2584623)
> Lower Left  (  -1.4062500, -89.2584623)
> Upper Right (     358.594,      89.258)
> Lower Right (     358.594,     -89.258)
> Center      ( 178.5937500,   0.0000000)
> Band 1 Block=128x1 Type=Float32, ColorInterp=Undefined
>  NoData Value=9.96920996838686905e+36
>
> Regards
> Luke
>
>
> ------
> If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
>
>
>
> Please consider the environment before printing this email.
>
> ------
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>