[fdo-internals] RFC 65 Implement Resampling for GDAL Provider

[Frank Warmerdam]

On Fri, Oct 12, 2012 at 3:20 PM, Trevor Wekel
<trevor_wekel at otxsystems.com>wrote:

>  Hi Frank,****
>
> ** **
>
> I was not aware of VRTWarpedDataset so did not consider it initially.****
>
> ** **
>
> So I took a quick look at vrtwarped.cpp.  I have a question.  In
> vrtwarped.cpp, the ProcessBlock() seems to cache the results of the warp
> operation (GDALCopyWords around line 1174) into each raster band.  Does
> this mean that all blocks will end up being cached?****
>
>
> Trevor,

Yes, VRTWarpedDataset will always push produced tiles into the GDAL block
cache.  Note that most drivers go through the block cache too.


> For FDO, we basically call a ReadNext() to suck the contents of the tile
> into a buffer supplied by the caller.  The ReadNext() drives the calls to
> _getTile().  As far as I can tell, our access pattern is linear and we only
> access each tile once.  If we switch to using VRTWarpedDataset, will we
> have to call ProcessBlock() for each tile?  Will this end up caching all
> the blocks as we do the linear read?
>

 In a web context, the ideal would be a long lived server which keeps
around the VRTWarpedDataset for subsequent use.  I not sure how practical
that is in the FDO/MapGuide use case.   In this situation caching the
blocks can help subsequent views but there might be better other layers at
which to do that.

****
>
> ** **
>
> As an alternative to using VRTWarpedDataset, would it be ok to instantiate
> a GDALWarpOperation as a member of the FdoRfpStreamReaderByTileResample?
> Pseudo code would be something like this:****
>
> ** **
>
>
> FdoRfpStreamReaderGdalByTileResample::FdoRfpStreamReaderGdalByTileResample()
> ****
>
> {****
>
> m_warpOp = new GDALWarpOperation();****
>
> }****
>
> ** **
>
> FdoRfpStreamReaderGdalByTileResample::_getTile()****
>
> {****
>
> warpOptions = GDALCreateWarpOptions();****
>
> // populate warp options****
>
> m_warpOp->Initialize(warpOptions);****
>
> m_warpOp->WarpRegion(0,0,origXSize,origYSize);****
>
> }****
>
> ** **
>
> This may improve the speed of the _getTile() call if a) Initialize() can
> be called more than once and b) the new GDALWarpOperation() does a lot of
> setup work
>

It is more likely to be the Iniitalize() that is expensive and
reinitialzing an existing WarpOperation is not a well trod path and likely
to lead to pain.  I advise against it.  In retrospect, sticking with your
existing approach is likely ok but you might want to get a sense of how
much time is spent in the setup code vs. the actual warping.   Larger tiles
will help.

Best regards,


-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/fdo-internals/attachments/20121012/a645a159/attachment.html>