[pdal] Change the pdal container

[Howard Butler]

> On Mar 16, 2016, at 7:16 AM, Helimap Postmaster <postmaster at helimap.ch> wrote:
> 
> Hello Andrew,
> 
> Thanks for digging in the issue! Unfortunately, I am not familiar yet with the 'views' and 'tables' terminology... What I need after the read of the las is a std::vector<float3> with the x,y,z coordinates of the las' points.

It's not very clear what you are actually asking for. Do you just want all of the XYZ data of an LAS file to be in a std::vector<float> after reading? If so, just read the data up and then copy it from the PointView using getFieldAs<float> and be on your way.

> I think there has been a little confusion with that. My las file is millions of points that I need to colorize (in parallel). At the moment I have it working for ascii xyzc to xyzrgb. I want to add las support, and therefore I have to read the las cloud, colorize each pixel and save it.

filters.colorization does exactly this. See http://www.pdal.io/stages/filters.colorization.html Running it over 20 million points should only be seconds. It is actually most sensitive to GDAL's raster cache settings more than anything.

I would also note that I think your approach to parallelization is The Hard Way. LiDAR and point cloud workflows often start with chopping things up into tiles, virtual or real, and then processing those pieces individually. The data are frequently at rest ready to go for this scenario. While not always ideal for every processing task (how do you interpolate over edges?), it's a tried-and-true approach. PDAL right now expects that you are doing your fan-out at the process level (run over a bunch of tiles) rather than the intra-process one (run parallel over a single tile). 

That's not to say it's impossible to do the latter, but it's just not the expected operating mode. As Andrew mentioned, you can implement your own storage to do things in whatever fashion you wish. 

Howard