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

[Andrew Bell]

PDAL reads the entire raster into memory, assuming that it pretty much
matches the extent of the point set that you're coloring.  Seems that this
is a bad assumption in your case.  The code would have to be changed to
limit the portion of the raster that you've created that gets read.  Feel
free to create a ticket.

On Wed, Oct 11, 2017 at 12:48 PM, Michael Rosen <michael.rosen at gmail.com>
wrote:

>
>
>
> 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?
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
>



-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20171011/a6b7ecc8/attachment.html>