Opened 17 years ago
Last modified 17 years ago
#1505 closed defect
gdal_translate misinterprets netCDF dimensions and cellsize — at Initial Version
Reported by: | 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).
Note:
See TracTickets
for help on using tickets.