flipped NetCDF driver output

[lagerratrobe]

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".

[Even Rouault]

This is probably a duplicate of #2654

[jluis]

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

[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?

[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.

[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.

[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.

[Kyle Shannon]

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