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

Roger André randre at gmail.com
Tue Apr 27 12:37:49 EDT 2010


>From my experience working with NetCDF files in GDAL, your best option is to
write your own tools to work between NetCDF and other raster formats.
Specifically, I would use the API to read the NetCDF, and explicitly define
the georeferencing of your output file using whatever logic you know to be
correct for your input data.  All of the variables in the NetCDF file are
accessible via GDAL, but in my experience the built-in utilities do not
always use them in the way you want.  I too believe this is a failure of the
NetCDF format, and not in GDAL.

Best of luck,

Roger
--

On Mon, Apr 5, 2010 at 11:26 PM, Michael Sumner <mdsumner at gmail.com> wrote:

> 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
> >
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100427/55925344/attachment.html


More information about the gdal-dev mailing list