id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 6759,gdal_translate from netcdf file shifted (gdal >= 1.10.1),jvh,warmerdam,"Using gdal_translate to convert to geotiff a netcdf file containing data on a UTM grid (attached), the output is shifted to the left by 360m. The enclosed netcdf file (created by gdalwarp itself) contains data on a UTM32 grid (in meters) with a grid spacing of 250m. The top left corner is at `Origin = (304250.000000000000000,5094750.000000000000000) `. Consistently the netcdf x-coordinates (gridcell centers) start from ` x = 304375`. Using {{{gdal_translate -of GTIFF DEM_250.nc DEM_250.tif}}} produces a file with the following `gdalinfo` header: {{{ Driver: GTiff/GeoTIFF Files: DEM_250.tif Size is 521, 572 Coordinate System is `' Origin = (303890.000000000000000,5094750.000000000000000) Pixel Size = (250.000000000000000,-250.000000000000000) }}} that is, the result is shifted to the left by exactly 360m. Actually already `gdalinfo` on the original netcdf file produces the same header. This happens for all recent gdal versions, starting from 1.10.1 (I also tested 1.11, 2.1.0, 2.1.1, 2.1.2). Tested both on different ubuntu distributions and on MacOSX 10.11 (homebrew). gdal <= 1.9.2 does *not* have the problem and produces an output file which has correctly {{{ Driver: netCDF/Network Common Data Format Files: DEM_250.nc Size is 521, 572 Coordinate System is `' Origin = (304250.000000000000000,5094750.000000000000000) Pixel Size = (250.000000000000000,-250.000000000000000) }}} If repeated `gdal_translate` are performed (netcdf-->gtiff-->netcdf etc) the output file is shifted to the left by 360m at each iteration. I tried also with a netcdf file with a different (500m) grid spacing and the resulting shift is still exactly 360m to the left. ",defect,closed,normal,2.1.3,default,unspecified,normal,fixed,,