[pdal] Colorization using a large VRT raster is slow, but using a small VRT raster is fast ... but why?

[Michael Rosen]

I am using the filters.colorization with a .vrt built by gdalbuiltvrt.  The
raster dataset actually contains 2200 files which I believe are all
correctly georeferenced and non-overlapping.  Of those, there are only 19
that actually intersect the point cloud being colorized.

What I'm observing is that if I build the vrt with only the 19 files, the
colorization runs in less than two minutes.  However, if build the vrt with
all of them, then it takes an unacceptably long time (I've not watched it
finish but I'm keeping an eye on the open file handles ... it's finding
right files but it's just moving through them really slowly).

I would expect that the VRT would be able to immediately provide the pixels
from the right raster tile, making the number of tiles in the mosaic
irrelevant.  That's clearly not the case (does it not do some sort of
indexing here?).  Can anyone offer an explanation / fix?  This is important
because I actually have many LAS tiles to colorize and while all of them
are contained in the bounds of the large mosaic, they each have a different
extent.

I guess a work around would be to build small VRTs based on the geographic
extent of each LAS tile.  But how?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20171011/6e7cec10/attachment.html>