<div dir="ltr"><div><div><div><div><div><div>Hello Andrew,<br><br></div>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. 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.<br><br></div>There is indeed only one cloud, one single file.<br><br></div>My raw issue regards how can I get a std::vector<float3> (float3 is a struct with 3 doubles, but could be whatever pdal needs so long as it stores the raw x,y,z coordinates).<br><br></div>Maybe I've pinpoint the wrong place, I thought the std::set was the underlying container storing the points, but apparently I am wrong? If so, where is the container, how to retrieve it and is it a std::vector?<br><br></div>cheers,<br><br></div>Pol<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 11:05 PM, Andrew Bell <span dir="ltr"><<a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Mar 15, 2016 at 11:40 AM, Helimap Postmaster <span dir="ltr"><<a href="mailto:postmaster@helimap.ch" target="_blank">postmaster@helimap.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div><div><div><div><div><div>Hello all,<br><br></div>This is a follow-up on a discussion started on liblas-devel mailing list with subject 'How to use a cached reader (c++)'.<br><br></div>The
 question it has come to is, how can I change the pdal cloud container? 
The cloud container, not the point container, that is, the container 
that stores all the points.<br><br></div>I've seen that pdal <a href="https://github.com/PDAL/PDAL/blob/master/include/pdal/PointView.hpp#L66" target="_blank">uses a std::set as a container</a>
 for the cloud, but std::set doesn't play with the parallel access of an
 openmp 2.0 for loop, which can only handle std::vector or std::queue.</div></div></div></div></div></div></blockquote><div><br></div></span><div>Well, not exactly.  By default PDAL has a set of buffers that contain the points.  You're welcome to implement a class derived from BasePointTable and arrange the data as you like.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>Is
 it possible to re-implement PointView class to use a 
std::vector<PointViewPtr>? Is it possible for me to access this 
vector?<br></div></div></div></div></div></blockquote><div><br></div></span><div>If what you're wanting to do is simply loop through points that you read, you'd only have a single view into a single table.  The access is direct from the view to the table. The table, by default, stores data in a vector of blocks, the blocks being memory containing points.<br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div>The first simple scenario is that I read the full 
pointcloud and store it into a std::vector<PointViewPtr>, then I 
process each point in parallel in an openmp for loop, and finally I save
 the modified std::vector to a new las file. The process is roughly 
adding color to each las point.<br></div></div></div></div></div></blockquote><div><br></div></span><div>I'm not sure why you need openmp, but I won't question.  If your colorizing algorithm is slow, then perhaps some threading system will be helpful.  But I'm not sure that you're worrying anything that is necessarily a problem given what you've said so far.  I certainly can't see any reason for a vector of point views.  If you're reading a single file, one PointView should suffice and be all that is normally created.  All points should be accessible through the one PointView.</div><div><br></div><div>The normal way to attack these problems is to first come up with a single-threaded solution and then optimize through threading as necessary.  Writing the base code will clarify issues and allow others to help you better than we can at this time.</div><div><br></div><div>Best,</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- <br></div></font></span></div><span class="HOEnZb"><font color="#888888"><div>Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br></div>