Opened 6 years ago

Last modified 6 years ago

#4512 reopened defect

netcdf files with longitude between 180 and 360 degrees are incorrectly projected

Reported by: etourigny Owned by: etourigny
Priority: normal Milestone:
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: netcdf, projection
Cc:

Description

Some netcdf files contain strictly positive values [0,360] which are not compatible with the way gdal/QGis treat longitude values - they do not wrap around the dateline. This also causes errors with gdalwarp and when combined with other datasets (with [-180,180] values), they are not aligned properly due to a 180 degree longitude shift.

Simple fix is to test for longitude variables (using CF metadata explained in CF sections 4.1 and 4.2) and convert any values in the [180,360] interval ti [-180,180] by subtracting 180 - in IReadBlock and also in SRS detection.

It would be better to address this in GDAL or PROJ, but this fix is much simpler and less involved.

Attachments (3)

tmp3.nc (199.7 KB) - added by etourigny 6 years ago.
file with longitude > 180 (modified from ticket #1894)
tmp4.nc (201.6 KB) - added by etourigny 6 years ago.
modified file with longitude in interval [-180,180]
reduce-cgcms.nc (24.3 KB) - added by etourigny 6 years ago.

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by etourigny

Attachment: tmp3.nc added

file with longitude > 180 (modified from ticket #1894)

Changed 6 years ago by etourigny

Attachment: tmp4.nc added

modified file with longitude in interval [-180,180]

comment:1 Changed 6 years ago by etourigny

Resolution: fixed
Status: newclosed

Fixed in trunk (r23969) and in 1.9 (r23970), changes in netCDFRasterBand::CheckValidData?() and netCDFDataset::SetProjectionFromVar?() .

Can be overridden (in case of unwanted side-effects) with config option GDAL_NETCDF_CENTERLONG_180=0 .

To test the fix, use gdalinfo and/or qgis on the 2 files, they should both have same extents and perfect line-up in QGis.

comment:2 Changed 6 years ago by etourigny

Keywords: projection added; geolocation removed

comment:3 Changed 6 years ago by etourigny

Resolution: fixed
Status: closedreopened

fix is not good with global datasets or datasets that span the dateline, attaching a file of global span.

Changed 6 years ago by etourigny

Attachment: reduce-cgcms.nc added

comment:4 Changed 6 years ago by Even Rouault

Note: r23970 (1.9 branch commit) was reverted in r23973. It might be indeed good to avoid pushing such non trivial stuff in the stable branch.

comment:5 Changed 6 years ago by etourigny

Agreed - I was a bit fast on the commit there, sorry.

comment:6 Changed 6 years ago by etourigny

commited better fix in trunk (r23974). If minimum longitude value is > 180, then subtract 360 from all longitude values.

This fixes gdalwarp with GEOLOCATION when longitude values are > 180, the result is shifted . Also fixes small rasters which are east of the dateline and do not align will global data (which is usually in the [-180,180] interval).

Note: See TracTickets for help on using tickets.