Opened 6 years ago

Closed 5 years ago

#7247 closed defect (wontfix)

"gdalwarp" incorrect resolution calculation

Reported by: justinmilk Owned by: warmerdam
Priority: high Milestone: closed_because_of_github_migration
Component: default Version: unspecified
Severity: normal Keywords: gdalwarp

Description (last modified by justinmilk)

Case scenario: GDAL 2.2.x; GeoTIFF, that crosses 180 meridian (example - B2 band of Landsat 8 scene -

When trying to crop it using gdalwarp with the -te option, but not specifying -ts or -tr options, I'm getting an output with the resolution very far from expected, regardless of output extent.


gdalwarp -te_srs "+proj=longlat +datum=WGS84 +no_defs " -te 179.819340820312505 -8.238065294160887 179.916987304687495 -8.141414642148055 -t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs" -dstalpha -srcnodata 0 B2.TIF B2_new.TIF

Running this command gave me output with size 3x3 pixels and resolution nearing 3600 meters, when original is only 30 meters!

Change History (3)

comment:1 by justinmilk, 6 years ago

Description: modified (diff)

comment:2 by justinmilk, 6 years ago

After some experiments turned out that output projection option (-t_srs "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs") causes the problem, which now partially becomes logical, as input dataset goes out of bounds of Pseudo-Mercator. Without this option the output is completely fine.

Still, originally described behavior seems unexpected.

comment:3 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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 if it is not already reported there.

Note: See TracTickets for help on using tickets.