Opened 17 years ago

Last modified 17 years ago

#1505 closed defect

gdal_translate misinterprets netCDF dimensions and cellsize — at Initial Version

Reported by: mwtoews@… Owned by: warmerdam
Priority: normal Milestone: 1.4.1
Component: default Version: 1.4.0
Severity: minor Keywords:
Cc: warmerdam

Description

This issue was initially posted on the gdal-dev mailing list using GDAL 1.3.2 (see http://lists.maptools.org/pipermail/gdal-dev/2006-October/010393.html for original message and netCDF file attachment). I am experiencing the same behaviour in GDAL 1.4.0 under Cygwin WinXPSP2.

My netCDF file was generated using NCO (ncra), and now I need to convert the NetCDF file into a different format for GIS programs:
$ gdal_translate -of AAIGrid -sds test.nc test.asc
$ mv test.asc1 test.asc
No errors were generated during the conversion.

The header of the AAIGrid output is:
ncols        86
nrows        225
xllcorner    747700.000000000000
yllcorner    5441461.627906977199
dx           98.837209302326
dy           99.555555555556
NODATA_value  -9999

However, these headers should read:
ncols         86
nrows         225
xllcorner     747700
yllcorner     5441200
cellsize      100
NODATA_value  -9999

The dx/dy in the output of the file was incorrectly calculated as:
dx=cellsize*(ncol-1)/ncol
dy=cellsize*(nrow-1)/nrow

theses formulas are of course nonsense, but are apparently how they were calculated. This is also why dx != dy (because ncols != nrows), and why they are not correct, since they are multiplied by the ratio of base0/base1 representations of their dimension lengths.

My netCDF file (attached on original forum post -- link at top of bug report) should have a cellsize of exactly 100, since my data are spaced every 100 m in the x- and y-dims. This netCDF file was produced using a custom python script, which uses Scientific.IO.NetCDF for python 2.3. The file was later averaged, using 'ncra', which is part of NCO (command viewed in history' global attribute). My netCDF file is not perfect; I've recently discovered that my 'ydim' is 5463700, 5463600, ..., 5441300; or it is in reverse order (dy = -100). For netCDF files, this should not matter (although I'll admit that it is a bit sloppy); I've been able to use the file as normal with 'ncview' and NCO.

(As a caution, I have also seen some netCDF files which order their latitudes from North to South, which is also in reverse order; I'm not sure if this is tested, and corrected in GDAL, but I would highly advise it for netCDF files).

Change History (0)

Note: See TracTickets for help on using tickets.