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

[etourigny]

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.

[etourigny]

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

[etourigny]

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

[etourigny]

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.

[etourigny]

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

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

[etourigny]

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

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

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.