Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gdalwarp producing multiple copies of input image at incorrect positions #10975

Closed
bch4132 opened this issue Oct 9, 2024 · 3 comments · Fixed by #10988
Closed

Gdalwarp producing multiple copies of input image at incorrect positions #10975

bch4132 opened this issue Oct 9, 2024 · 3 comments · Fixed by #10988
Assignees

Comments

@bch4132
Copy link

bch4132 commented Oct 9, 2024

What is the bug?

Gdalwarp is producing artifacts in output when using -te arguments larger than bounds of the input

Steps to reproduce the issue

repro.zip
Inside the zip attached there is tiff file used as input. When running this through gdal with the following arguments:
-t_srs "+proj=longlat +datum=WGS84 +ellps=WGS84 +no_defs +type=crs" -of GTiff -co "TILED=YES" -co "BLOCKXSIZE=1024" -co "BLOCKYSIZE=1024" -co "BIGTIFF=YES" -wm 500 -wo "NUM_THREADS=ALL_CPUS" -multi -co "COMPRESS=ZSTD" -co "NUM_THREADS=ALL_CPUS" -dstnodata -32767.0 -ot Float32 -te -81.500000000000 28.500000000000 -81.000000000000 29.000000000000 -r near "n4.tif" "Repro_hgt.tif"
There are copies of the input produced on the left and right side of where the actual input should be on the resulting image.

Input image:
image
Resulting output:
image

Versions and provenance

I have tested with multiple versions, including 3.6.2, 3.9.2 (from QGIS install), as well as 3.10.0dev-d04e73dfbd from a source build all with the same result.

Additional context

No response

@jratike80
Copy link
Collaborator

jratike80 commented Oct 9, 2024

I could re-produce on Windows with GDAL 3.9.1. Without -te the output is good and corner coordinates are:

Corner Coordinates:

Upper Left  ( -81.1762512,  28.6631436) ( 81d10'34.50"W, 28d39'47.32"N)
Lower Left  ( -81.1762512,  28.6354970) ( 81d10'34.50"W, 28d38' 7.79"N)
Upper Right ( -81.1317603,  28.6631436) ( 81d 7'54.34"W, 28d39'47.32"N)
Lower Right ( -81.1317603,  28.6354970) ( 81d 7'54.34"W, 28d38' 7.79"N)
Center      ( -81.1540058,  28.6493203) ( 81d 9'14.42"W, 28d38'57.55"N)

What is this coordinate system of n4.tif?

Coordinate System is:
GEOGCRS["World Geodetic System 1984",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]],
        ID["EPSG",6326]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["arc-second",4.84813681109536E-06]],
    CS[ellipsoidal,2],
        AXIS["latitude",north,
            ORDER[1],
            ANGLEUNIT["arc-second",4.84813681109536E-06]],
        AXIS["longitude",east,
            ORDER[2],
            ANGLEUNIT["arc-second",4.84813681109536E-06]]]

@jratike80
Copy link
Collaborator

I think that the issue must have something to do with those arc-seconds. If I first warp the image into EPSG:4326 without any parameters, and then this interim image into the target extent, then the result looks good.

I have removed all parameters which I thought are not essential.

gdalwarp -t_srs epsg:4326 -te -81.500000000000 28.500000000000 -81.000000000000 29.000000000000 "repro_interim_4326.tif" "Repro_4.tif"

@rouault
Copy link
Member

rouault commented Oct 10, 2024

I think that the issue must have something to do with those arc-seconds.

Exactly. Fix in #10988

rouault added a commit to rouault/gdal that referenced this issue Oct 10, 2024
rouault added a commit to rouault/gdal that referenced this issue Oct 10, 2024
rouault added a commit to rouault/gdal that referenced this issue Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants