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

[Trevor Wekel]

Hi Frank,

For "web context", MapGuide has a "base layer" concept which can be used to create cached tiles.  Raster layers can be rendered by FDO and MapGuide and then cached on the MapGuide Server as base layer tiles.  So caching at the FDO level is not absolutely necessary.  As far as I know, the GDAL Provider does not do any caching currently and interactions between MapGuide and FDO would have to be considered in more detail if we want to go down that road.

For example, MapGuide only uses one GDAL FDO connection so any caching done at the connection level would be ineffective.  At some point in the future, MapGuide may hold on to multiple GDAL FDO connections and use them simultaneously.  When that happens, reworking the GDAL Provider to make use of the block cache may be appropriate.  I suspect that would be a lengthy discussion and a whole other set of RFCs.  Caching may be appropriate for serving all raster data, not just resampled data.

Regards,
Trevor


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: October 12, 2012 5:30 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 65 Implement Resampling for GDAL Provider


On Fri, Oct 12, 2012 at 3:20 PM, Trevor Wekel <trevor_wekel at otxsystems.com<mailto: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<mailto: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/e96488f6/attachment-0001.html>