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

[Orest Halustchak]

+1
Orest

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Tuesday, October 23, 2012 6:03 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 65 Implement Resampling for GDAL Provider

+1
Haris

On Wed, Oct 24, 2012 at 12:00 AM, Greg Boone <greg.boone at autodesk.com> wrote:
> Well, +1 again.
>
>
>
> Voting has been open for some time now. Final votes are due tomorrow, 
> by 5pm ET.
>
>
>
> Greg
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor 
> Wekel
> Sent: Tuesday, October 23, 2012 5:54 PM
>
>
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] RFC 65 Implement Resampling for GDAL 
> Provider
>
>
>
> Ok.  Thanks Greg.  I make a couple of small updates to the RFC and 
> attached the latest code yesterday.
>
>
>
> Regards,
>
> Trevor
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: October 23, 2012 3:52 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] RFC 65 Implement Resampling for GDAL 
> Provider
>
>
>
> I think the RFC is ok, the final say on the code review is Frank.
>
>
>
> Greg
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor 
> Wekel
> Sent: Sunday, October 21, 2012 10:56 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] RFC 65 Implement Resampling for GDAL 
> Provider
>
>
>
> Hi Frank,
>
>
>
> I have attached an updated patch to RFC 65 with the CPLPrintPointer 
> modification and compile fixes [Makefile.am updates] for Linux.  The 
> code compiles and the FDO unit tests are clean on VC10 32bit Windows, 
> VC10 64bit Windows, and 32bit CentOS 5.
>
>
>
> I was also able to verify the functionality visually in MapGuide on 
> all three platforms.  No code changes are required for MapGuide.  Just 
> add the following parameter to the feature source XML document:
>
>
>
> <Parameter>
>
>     <Name>ResamplingMethod</Name>
>
>     <Value>bilinear</Value>
>
> </Parameter>
>
>
>
> If everyone is ok with the RFC "as is", can we get it approved?  I can 
> check the code in the next day or so.
>
>
>
> 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>
> 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::FdoRfpStreamReaderGdalByTileResa
> mple()
>
> {
>
> 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
>
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals