Ticket #1945 (closed defect: fixed)

Opened 10 months ago

Last modified 10 months ago

gdalwarp with a resampling method other than "near" creates a border of wrong values at the transition of the data to the nodata values.

Reported by: jluis Assigned to: warmerdam
Priority: normal Milestone:
Component: Utilities Version: svn-trunk
Severity: normal Keywords:
Cc:

Description

gdalwarp with a resampling method other than "near" creates a border of wrong values at the transition of the data to the nodata values. Besides this problem, this reprojection also creates a band of zeros at the west and south borders. The attached image illustrates well both problems.

Example command that demonstrate the problem

gdalwarp -s_srs "+proj=tmerc +lat_0=39.66666666666666 + lon_0=-8.131906111111111 +k=1.0 +x_0=200000 +y_0=300000 +ellps=intl +towgs84=-30 2.581,-61.360,103.047,0,0,0,0" -t_srs "+proj=utm +zone=29 +datum=WGS84" -tr 25 25 -ot Int16 -r cubic lixo.tiff lixo2.tiff

Attachments

lixo.tiff (469.5 kB) - added by jluis on 10/26/07 15:31:46.
lixo2.jpg (11.7 kB) - added by jluis on 10/26/07 15:33:10.

Change History

10/26/07 15:31:46 changed by jluis

  • attachment lixo.tiff added.

10/26/07 15:33:10 changed by jluis

  • attachment lixo2.jpg added.

10/27/07 06:48:21 changed by rouault

To remove the zeros at the west and south borders, you have to add "-dstnodata -32768" on the command line to make sure that the output will have the same nodata as the input.

As far as the wrong values at the transition between data and nodata, this is an already known problem reported in #1610

10/28/07 14:36:05 changed by warmerdam

  • status changed from new to closed.
  • component changed from default to Utilities.
  • resolution set to duplicate.

I have confirmed that the command works fine if -srcnodata -32768 is provided. So with #1610 fixed, this bug devolves to the issue that gdalwarp ignores nodata values set on the source file as described in #1949. So I'm closing this bug as a duplicate of that one.

10/28/07 16:49:33 changed by jluis

With the gdalwarp 1.4.3 version the following command still produces wrong results on the transition between data and nodata.

gdalwarp -s_srs "+proj=tmerc +lat_0=39.66666666666666 + lon_0=-8.131906111111111 +k=1.0 +x_0=200000 +y_0=300000 +ellps=intl +towgs84=-30 2.581,-61.360,103.047,0,0,0,0" -t_srs "+proj=utm +zone=29 +datum=WGS84" -tr 25 2 5 -ot Int16 -rb lixo.tiff lixo2.tiff

10/28/07 17:20:11 changed by jluis

  • status changed from closed to reopened.
  • resolution deleted.

10/28/07 17:24:01 changed by warmerdam

Joaquim,

You are still not specifying -srcnodata in the command. Without this option the interpolation kernel does not realize that -32768 is a nodata value, and so it doesn't realize it should not include it in the interpolation kernel.

10/28/07 17:43:26 changed by jluis

Sorry for the misunderstanding but this hole thing is quite confusing. Why should one have to tell about the srcnodata? Its on the file's metadata.

Anyway, specifying only the -srcnodata is not enough. One has to tell it the -dstnodata as well, otherwise the old srcnodata are converted to zeros.

Here is the command that finally worked

gdalwarp -s_srs "+proj=tmerc +lat_0=39.66666666666666 + lon_0=-8.131906111111111 +k=1.0 +x_0=200000 +y_0=300000 +ellps=intl +towgs84=-30 2.581,-61.360,103.047,0,0,0,0" -t_srs "+proj=utm +zone=29 +datum=WGS84" -tr 25 2 5 -ot Int16 -rc -srcnodata -32768 -dstnodata -32768 lixo.tiff lixo2.tiff

Joaquim

10/28/07 18:18:28 changed by warmerdam

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

Joaquim,

-srcnodata had to be specified explicitly because gdalwarp was ignoring nodata values marked on source images as described in bug #1949. I had closed this bug because it duplicated that one. Note that I have also fixed #1949 this afternoon, but only in trunk, not 1.4.x since I consider it more of a feature addition than a bug fix.

The -dstnodata argument is necessary if you wish to preserve nodata values as -32768 and to keep them distinct from 0. But it isn't necessary to avoid the interpolator mixing problem.

Sorry for the confusion. I am closing this again since as I understand it all issues are dealth with.