[pdal] Fwd: Change the pdal container

Helimap Postmaster postmaster at helimap.ch
Wed Mar 16 05:16:31 PDT 2016


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.
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.

There is indeed only one cloud, one single file.

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).

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?

cheers,

Pol

On Tue, Mar 15, 2016 at 11:05 PM, Andrew Bell <andrew.bell.ia at gmail.com>
wrote:

> On Tue, Mar 15, 2016 at 11:40 AM, Helimap Postmaster <
> postmaster at helimap.ch> wrote:
>
>>
>> Hello all,
>>
>> This is a follow-up on a discussion started on liblas-devel mailing list
>> with subject 'How to use a cached reader (c++)'.
>>
>> 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.
>>
>> I've seen that pdal uses a std::set as a container
>> <https://github.com/PDAL/PDAL/blob/master/include/pdal/PointView.hpp#L66>
>> 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.
>>
>
> 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.
>
> Is it possible to re-implement PointView class to use a
>> std::vector<PointViewPtr>? Is it possible for me to access this vector?
>>
>
> 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.
>
> 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.
>>
>
> 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.
>
> 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.
>
> Best,
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20160316/b74e3d70/attachment.html>


More information about the pdal mailing list