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 |
Cc: |
Description (last modified by )
Case scenario: GDAL 2.2.x; GeoTIFF, that crosses 180 meridian (example - B2 band of Landsat 8 scene - https://landsat-pds.s3.amazonaws.com/c1/L8/075/066/LC08_L1TP_075066_20180117_20180118_01_RT/LC08_L1TP_075066_20180117_20180118_01_RT_B2.TIF).
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.
E.g.:
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 , 6 years ago
Description: | modified (diff) |
---|
comment:2 by , 6 years ago
comment:3 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
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.