Opened 11 years ago
Closed 5 years ago
#4850 closed defect (wontfix)
gdalwarp discards data when the target extent is too large
Reported by: | sfllaw | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | default | Version: | 1.9.1 |
Severity: | normal | Keywords: | |
Cc: | simon.law@…, mdupuis@… |
Description (last modified by )
gdalwarp discards 25 pixels longitudinally, shown as black borders, on the west or east side if the target extent is too large on that side.
We have a sample 512×512 EPSG:3785 image called bluemarble.tif
, attached to this ticket.
bluemarble-warped.tif is the output generated when we run the following command:
gdalwarp -q -of GTiff -t_srs EPSG:3785 -te -20037508.3428 -20037508.34 20037508.34 20037508.34 -ts 512 512 bluemarble.tif bluemarble-warped.tif
As you can see, there are 25 pixels cropped from the western edge of the picture, replaced with (0, 0, 0). This is because -20037508.3428 m for the western extent is supposed to be -20037508.342789244.
If we pass in a -dstnovalue
option to the command, it behaves correctly.
Attachments (3)
Change History (7)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|---|
Summary: | u → gdalwarp discards data when the target extent is too large |
comment:2 by , 11 years ago
Description: | modified (diff) |
---|
by , 11 years ago
Attachment: | bluemarble.tif added |
---|
by , 11 years ago
Attachment: | bluemarble-warped.tif added |
---|
comment:3 by , 11 years ago
Description: | modified (diff) |
---|
comment:4 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.
Source image