Opened 13 years ago

Closed 11 years ago

#2846 closed defect (duplicate)

flipped NetCDF driver output

Reported by: lagerratrobe Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.5.2
Severity: normal Keywords: netcdf
Cc: ksshannon@…

Description


When converting CF convention NetCDF data using GDAL 1.5.2, released 2008/05/29, output GeoTIFF's are upside down. The NetCDF file which I am using to test can be downloaded from http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc.


The SUBDATASET of interest is the "tos" one, and when queried by gdalinfo it shows that it contains 24 bands, each of which varies by NETCDF_DIMENSION_time variable that increments by 15.


I am able to test that I can extract one of these bands with GDAL, and convert it to GeoTIFF with the following command:

gdal_translate -b 1 NETCDF:"tos_O1_2001-2002.nc":tos sea_temp_band_1.tif


However, as you can see from the screenshot that I've posted at http://2.bp.blogspot.com/_-yICqdt0mtY/SZxtI4yUHdI/AAAAAAAAA-I/z7W_O6qBXho/s1600-h/upside_down_netcdf.jpg, the data in the file appears to be upside down. Since this file is a sample from the Unidata web site, I'm reasonably confident that the file follows the CF convention. The georeferencing and pixel dimensions in the GeoTIFF seem to be reasonable, so it appears that the row-order is simply "flipped".

Change History (8)

comment:1 Changed 13 years ago by Even Rouault

This is probably a duplicate of #2654

comment:2 Changed 13 years ago by jluis

Also reported > 1 year before in http://trac.osgeo.org/gdal/ticket/1926

comment:3 in reply to:  2 ; Changed 13 years ago by lagerratrobe

Replying to jluis:

Also reported > 1 year before in http://trac.osgeo.org/gdal/ticket/1926

Agreed, this is probably related. I'm not sure what all the "south-up vs north-up" debate is about though. Since the actual georeferencing that's being reported is (now) correct, it seems to me that the reason for this is simple - NetCDFs/GMT files use the LL corner as the origin, gdal and other raster formats use the UL. Solution is to reverse the order in which input rows are written to the output file, as is done in Matt Perry's flip_raster.py tool. Is this spurious logic?

comment:4 in reply to:  3 ; Changed 13 years ago by jluis

Replying to lagerratrobe:

Solution is to reverse the order in which input rows are written to the output file, as is done in Matt Perry's flip_raster.py tool. Is this spurious logic?

I'm afraid that will not be enough. I have a gdalread MEX file which allows reading sub-regions of a file. That MEX has "counter measures" to work around this bug. One other thing I can see when I let the bug manifest is that a sub-region selected, for instance, in the northern hemisphere is extracted on the southern hemisphere (symmetrically to the equator). I believe the correct way to dealing with this issue is to make the driver aware if it is reading a bottom-up or a top-down file. Otherwise it will work only for one of the flavors, as it does now.

comment:5 in reply to:  4 Changed 13 years ago by lagerratrobe

Replying to jluis:

Would it be possible for you to post a sample NetCDF for which the current logic works properly? Using this, I could perhaps convince our meteorologists to write out NetCDFs in a different way, one which would render them compatible for use with gdal. To date, I have been unable to find any files that work, which makes it difficult for me to propose a change to them. Documentation only states that a "CF" convention NetCDF be used.

Replying to lagerratrobe:

I believe the correct way to dealing with this issue is to make the driver aware if it is reading a bottom-up or a top-down file. Otherwise it will work only for one of the flavors, as it does now.

comment:6 Changed 13 years ago by jluis

I'm sorry but I don't have any example. I'm a very GMT guy and, btw, what I said about the driver awareness on the way the file is written just reflects what GMT does internally. Maybe you should ask in the mailing list, but I don't think the solution is to convince your colleagues to change the way they write the netCDF files. The solution is to correct this bug, which unfortunately is taking way too long.

comment:7 Changed 11 years ago by Kyle Shannon

Keywords: netcdf added; NetCDF removed

comment:8 Changed 11 years ago by Kyle Shannon

Cc: ksshannon@… added
Resolution: duplicate
Status: newclosed

Frank, I am going to close this as a duplicate of #2654, and it is possible that Ivan's commit in r20006 fixed this. He closed a similar ticket (#3575) that was related to this ticket and #2654

Note: See TracTickets for help on using tickets.