The problem will be in all methods if I recall correctly, but to
varying degrees. In the original resampling method, they all use
kernels of varying sizes. When said kernel would sample against the
edge of the image, it defaults to bilinear resampling (I think).
Cubicspline has the largest
Well, the good news is that the artifacts don't seem to be present when I
use the plain "cubic" resampling method. The bad news is that the the
quality of that method isn't good enough for me to use. I think my solution
is going to have to be that I manually cut pieces out of the low-res mosaic
t
Hi Seth and Frank,
Thanks for the feedback. I just finished reading the changelog link that
Seth sent and all I can say is, "Wow, nice job!"
I did some further testing last night using a single GTOPO30 tile, and doing
a 10x upsample. The artifacts are present in it at columns 6000 and 12000,
so
I agree with Frank, this sounds like the bug that I reported (and
fixed) here:
http://trac.osgeo.org/gdal/ticket/2327
(Although it became a log of my alterations to the warper kernel,
which was well beyond the scope of the original bug.)
~Seth
On Sep 29, 2008, at 11:19 PM, Frank Warmerdam
On Tue, Sep 30, 2008 at 4:30 AM, Roger André <[EMAIL PROTECTED]> wrote:
> Hi List,
>
> I've hit the same problem twice now, and I'm pretty certain after Round 2
> that I'm not introducing it. Basically, I'm using gdal_merge.py to mosaic a
> group of low-resolution, 32-bit floating point rasters to
Hi List,
I've hit the same problem twice now, and I'm pretty certain after Round 2
that I'm not introducing it. Basically, I'm using gdal_merge.py to mosaic a
group of low-resolution, 32-bit floating point rasters together, then
running "gdalwarp -ts xxx yyy -r cubicspline" on the mosaic to get a
