mapresample.c grossly oversamples in some cases.

[warmerdam]

The logic for computing the cellsize in the intermediately loaded image
assumes that the source area will take up the whole output map.  This means
in cases where the source area only fills a small portion of the destination 
map view the intermediate data will be loaded at much higher resolution than 
necessary.

In the following the nDstXSize really ought to be with width of the
window on the destimation map to be overwritten from the source image - 
not the width of the whole map view. 

        sDummyMap.cellsize = 
            (dfNominalCellSize * (sSrcExtent.maxx - sSrcExtent.minx))
            / (dfOversampleRatio * nDstXSize);

This is resulting in poor performance in some rendering cases.  Notably
when zoomed out far enough that each raster loaded covers only a modest
portion of the display.

[fwarmerdam]

I'll take this fix.

[fwarmerdam]

this will be somewhat messy to fix because at the point we are loading
the source image data we don't really have any idea of what part of the
destination map view will be set from the source data.  We really need
to reproject the source rectangle back onto the destination.

I would add that the underlying resampling functions will process the whole map
view, warping onto the source image to sample, regardless of the fact that
the source image may only overlay a small portion of the map view.  If we get
an appropxiate "destination rectangle" we should use it in the resamplers to
restrict the region over which they do resampling work.  This would also be
a substantial performance advantage. 

But clearly this bug is growing more ... involved ... to fix. 

[bill@…]

Frank, please tell me how I can help you on this.  In particular, if you'd like
me to test any potential fixes against large ECW/MrSID datasets, please let me
know.  As you know I've seen this problem in droves in those sets.

[fwarmerdam]

A preliminary fix has been committed.  Basically I pick the source data
cellsize for loading based on the relationship between the map size and
the region on the source image *before* the source region has been clipped 
to available data. 

This should give the desired ratio in all circumstances I think. 

The change is quite modest and could be retrofitted into 4.6.x if needed.

[bill@…]

Frank, this certainly has a big impact.

Here are the before and after timings from the test script I sent you:

Before (no resample, resample=1.0 and resample = default (2.0))
1.06user 0.34system 0:01.79elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k
3.35user 1.02system 0:04.50elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
11.30user 2.61system 0:14.11elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k

After (no resample, resample=1.0 and resample = default (2.0))
1.03user 0.34system 0:01.48elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
1.12user 0.35system 0:01.53elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
3.27user 0.94system 0:04.27elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k

So, this has made a huge difference.  

The numbers above have profiling (qprof) turned on.  here is the same output
without it:
0.72user 0.05system 0:00.80elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
0.81user 0.05system 0:00.89elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
2.42user 0.21system 0:02.69elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k

I'm not sure how meaningful that is, but I thought I'd post it.

Thanks for all your help on this.  Hopefully, it will mean I don't need so many
summary layers in the mapscript area.

[bill@…]

Zip of two images showing introduced artifact

[fwarmerdam]

Bill, 

I have reproduced the cracking effect with the previous
test dataset.  I will see what I can do. 

I don't think mosaicing then reprojecting would be prudent.  Amoung other
issues, not all files in a tile index need to be in the same projection
(though the bounding rectangle in the tileindex needs to be in a uniform
projection).