Ticket #2654 (closed defect: fixed)

Opened 3 years ago

Last modified 11 months ago

[PATCH] Fix flipped latitude with NetCDF CF-1 files

Reported by: ekato Owned by: warmerdam
Priority: high Milestone: 1.6.4
Component: GDAL_Raster Version: 1.6.2
Severity: major Keywords: netcdf
Cc: neteler, dnadeau, mdsumner, kyle

Description

Maybe related to JoseM's comment in #2584, I've experienced getting upside-down image with NetCDF driver. So I've created a simple patch to flip latitude for CF-1.0 files.

In netCDFDataset::SetProjection?(), I assume the files with following attributes as CF-1.0 files.

  • have valid nVarDimXID and nVarDimYID
  • poDS->papszDimName[poDS->nDimYid] starts with "lat"
  • pdfYCoord[0] < pdfYCoord[ydim-1]

Attachments

netcdf-y-flip.patch Download (2.3 KB) - added by ekato 3 years ago.
Revised one which also works with files created by GMT's grdraster
netcdf-y-flip-rev.patch Download (2.7 KB) - added by ekato 3 years ago.
Real revised patch which also works with GMT's grdraster
netcdf-y-flip-rev2.patch Download (3.3 KB) - added by tbouffon 2 years ago.
Added support of more GMT-generated files
file.gmt Download (1.2 KB) - added by tbouffon 2 years ago.
file.xyz Download (37.5 KB) - added by tbouffon 2 years ago.
netcdf-y-flip-rev3.patch Download (3.4 KB) - added by tbouffon 2 years ago.

Change History

Changed 3 years ago by ekato

Revised one which also works with files created by GMT's grdraster

  Changed 3 years ago by neteler

  • cc neteler added

  Changed 3 years ago by rouault

  • keywords netcdf added
  • component changed from default to GDAL_Raster
  • summary changed from Fix flipped latitude with NetCDF CF-1 files to [PATCH] Fix flipped latitude with NetCDF CF-1 files

  Changed 3 years ago by dylan

Any word when/if this can be merged into GDAL proper? It would save considerable time when working with NetCDF, by removing 2 steps involved in manually flipping the grid with a combination of gdal_translate and gdalwarp.

Thanks for the patch!

  Changed 3 years ago by warmerdam

  • cc warmerdam added
  • owner changed from warmerdam to dnadeau

This seems pretty similar to #2584 - are they related? Reassigning to Denis, our netcdf guru.

Changed 3 years ago by ekato

Real revised patch which also works with GMT's grdraster

  Changed 2 years ago by tbouffon

  • priority changed from normal to high
  • version changed from 1.5.3 to 1.6.2
  • severity changed from normal to major
  • milestone set to 1.6.3

Hi, The patch did not work for me. Files created with xyz2grd (GMT 4.2.1) had y as poDS->papszDimName[poDS->nDimYid]. So I used GMT Metada to detect Latitude, and added a warning.

I haven't tested it a lot yet.

Changed 2 years ago by tbouffon

Added support of more GMT-generated files

  Changed 2 years ago by mdsumner

  • cc mdsumner added

FWIW we've been using netcdf-y-flip-rev.patch successfully. The third one does not work at all, but I haven't explored why.

  Changed 2 years ago by warmerdam

  • cc dnadeau added; warmerdam removed
  • owner changed from dnadeau to warmerdam

I'll take a crack at reviewing the patches and applying one. I would like a test file - mdsumner its going to try and find one.

  Changed 2 years ago by warmerdam

  • status changed from new to closed
  • resolution set to fixed

Based on a review of the code, and mdsumner's feedback I'm reasonable confident with netcdf-y-flip-rev.patch from ekato. There seem to be doubts still about the rev2 patches efforts with additional GMT files so I'm skipping it - it might be appropriate to file that in a new ticket which includes a reference to a file or files demonstrating the problem the patch solves.

I would add I'm interested in very small netcdf files demonstrating the issues in question that can be added to the autosuite. mdsumner provide me a test file, but it is large, and it isn't known if it is suitable for redistribution.

Patch applied in trunk (r18151,r18153), and 1.6 branch (r18152).

  Changed 2 years ago by tbouffon

Hi, indeed there is a problem with my rev2 patch. I thought I had posted the new version. I and a few of my colleagues have been working with the version I'm posting without any problem for one month now. I'm joining a set of files as an example : file.xyz is an ascii file containing gridded data file.gmt is generated with :

xyz2grd file.xyz -R0/10/0/10 -I1 -Gfile.gmt -fg

the version with rev.patch still flipped the raster, as the metada where not matching the criteria. But rev2.patch segfaults when the lat long name is empty. So I worked it around by setting a new string. I'm leaving the french comments in the patch to avoid any typo.

Is my answer fast enough or should I open a new ticket ?

Changed 2 years ago by tbouffon

Changed 2 years ago by tbouffon

Changed 2 years ago by tbouffon

  Changed 2 years ago by rouault

  • status changed from closed to reopened
  • resolution fixed deleted

Re-opening as the netcdf-y-flip-rev3.patch was added after the commits

  Changed 2 years ago by kyle

  • cc kyle added

  Changed 22 months ago by kyle

Has anyone tested the third revision of this patch?

  Changed 21 months ago by kyle

Is there a reference for the bottom-first convention? I didn't see it in cf-1.4 docs. Is it always true?

  Changed 20 months ago by etiennesky

This problem is still found in the stable version 1.7.2. Can I test the first and 3rd patch in 1.7.2 stable or trunk?

I'd like to help fix this problem.

  Changed 20 months ago by etiennesky

Sorry looks like it's been fixed, it works correctly in stable 1.7.2.

follow-up: ↓ 17   Changed 20 months ago by kyle

I can't say that this is fixed completely in 1.7.2, as I still run into datasets that open upside down occasionally. I am still working on this one though...

in reply to: ↑ 16 ; follow-up: ↓ 18   Changed 19 months ago by JeffBullard

Replying to kyle:

I can't say that this is fixed completely in 1.7.2, as I still run into datasets that open upside down occasionally. I am still working on this one though...

This problem is still not fixed (for me) in 1.7.2, although the problem could be with NOAA's degrib utility. This problem is reproducible: Download a grib file from NOAA's NOMAD server. Convert to NetCDF format using NOAA's 'degrib' utility Convert the NetCDF to GeoTiff? with gdalwarp. The resulting GeoTiff? is upside down, every time.

I have been dealing with this problem for the past four years and my 'workaround solution' is to gdal_translate -a_ullr the NetCDF corner coordinates (flip them upside down) before converting to Geotiff.

in reply to: ↑ 17 ; follow-up: ↓ 19   Changed 19 months ago by tbouffon

Replying to JeffBullard:

Replying to kyle: This problem is still not fixed (for me) in 1.7.2, although the problem could be with NOAA's degrib utility. This problem is reproducible: Download a grib file from NOAA's NOMAD server. Convert to NetCDF format using NOAA's 'degrib' utility Convert the NetCDF to GeoTiff? with gdalwarp. The resulting GeoTiff? is upside down, every time. I have been dealing with this problem for the past four years and my 'workaround solution' is to gdal_translate -a_ullr the NetCDF corner coordinates (flip them upside down) before converting to Geotiff.

Hi, did you try one of the patches above ? As long as the degrib utility writes latitude as y-coord name in the metadata, they should work.

in reply to: ↑ 18 ; follow-up: ↓ 20   Changed 19 months ago by JeffBullard

Replying to tbouffon:

Replying to JeffBullard:

Replying to kyle: This problem is still not fixed (for me) in 1.7.2, although the problem could be with NOAA's degrib utility. This problem is reproducible: Download a grib file from NOAA's NOMAD server. Convert to NetCDF format using NOAA's 'degrib' utility Convert the NetCDF to GeoTiff? with gdalwarp. The resulting GeoTiff? is upside down, every time. I have been dealing with this problem for the past four years and my 'workaround solution' is to gdal_translate -a_ullr the NetCDF corner coordinates (flip them upside down) before converting to Geotiff.

Hi, did you try one of the patches above ? As long as the degrib utility writes latitude as y-coord name in the metadata, they should work.

After more testing, I think the problem is with the degrib utility from NOAA. I downloaded software from NCAR to convert my GRIB data to NetCDF then converted to GeoTiff? with GDAL 1.7.2. The image was NOT upside-down. NCAR utility with GDAL gives me correct output. NOAA utility with GDAL gives me upside-down.

in reply to: ↑ 19   Changed 19 months ago by kyle

Replying to JeffBullard:

Replying to tbouffon:

Replying to JeffBullard:

Replying to kyle: This problem is still not fixed (for me) in 1.7.2, although the problem could be with NOAA's degrib utility. This problem is reproducible: Download a grib file from NOAA's NOMAD server. Convert to NetCDF format using NOAA's 'degrib' utility Convert the NetCDF to GeoTiff? with gdalwarp. The resulting GeoTiff? is upside down, every time. I have been dealing with this problem for the past four years and my 'workaround solution' is to gdal_translate -a_ullr the NetCDF corner coordinates (flip them upside down) before converting to Geotiff.

Hi, did you try one of the patches above ? As long as the degrib utility writes latitude as y-coord name in the metadata, they should work.

After more testing, I think the problem is with the degrib utility from NOAA. I downloaded software from NCAR to convert my GRIB data to NetCDF then converted to GeoTiff? with GDAL 1.7.2. The image was NOT upside-down. NCAR utility with GDAL gives me correct output. NOAA utility with GDAL gives me upside-down.

Jeff, Can you test your file with Ivan's changes in r20006? Let me know if that does anything to help with your problem.

  Changed 19 months ago by kyle

Ivan's correction fixed the files I was having issues with.

  Changed 11 months ago by tbouffon

Ivan's correction also fixes the problems with the file.gmt attached above.

  Changed 11 months ago by kyle

  • status changed from reopened to closed
  • resolution set to fixed

I am closing this for now, if anyone finds another instance, please reopen. Thanks Ivan

Note: See TracTickets for help on using tickets.