[pdal] Documentation on using PDAL

[Andrew Bell]

On Fri, Apr 15, 2016 at 12:01 PM, César Martínez Izquierdo <
cesar.izq at gmail.com> wrote:

> Regarding our needs, the library would be used on a desktop GIS software
> (gvSIG), so the use cases are quite diverse. We would implement a LAS data
> provider for our own framework, this provider would be internally based on
> PDAL.
>
> Therefore, typical usages could be:
> - To access all the LAS points on a sequential way (to draw the layer)
>
- To access all the LAS points on an area (when zooming to the layer)
>

This just isn't possible.  The LAS format doesn't provide a spatial index.


> - To access a single LAS point (info by point)
>

This is an unusual requirement for point clouds.  There isn't usually much
information in a single point.

- To write a new LAS file, the input of which could be any other point
> layer loaded on our GIS software (including another LAS/LAZ file but it
> could also be Shapefiles for instance). Note that because we have our own
> abstraction layers, we will not be able to directly use a PDAL reader as
> the input of a pipeline in this case (although we might create a custom
> reader that wraps our gvSIG data providers)
>

You just need to put your data into a PDAL PointTable (usually using a PDAL
PointView) and then PDAL can write the data.  There are fancier things that
can be done that require more code on your part.


> As LAS files can be sometimes huge, I am specially worried about PDAL
> reading/writing strategies.
>
Does a las_reader.execute(table) (as shown on the libLAS to PDAL tutorial)
> load the full file on-memory? Or does it load blocks on demand when you
> actually request one point to the ViewSet?
>

There are no blocks in a LAS file.  Points in LAS files may be in any order
whatsoever and there is no spatial index, which is why reading all points
is usually the only solution.  This is a limitation of the file format and
not PDAL.  Many people break large files into geographically-based
subfiles, or tiles, but then you're just reading smaller LAS files and have
to do your own organization and preprocess the data.  Some people use PDAL
to read points from a LAS file and place them in a database that supports
spatial indexing, like Postgres, SQLite or Oracle.  HOBU also has a
level-of-detail indexed format readable through PDAL that can be used by
visualization which you might want to consider, but it's not directly
reading points from LAS.


> If everything is read on-memory, the I guess we'll need to limit the
> number of loaded points, but at the same time it would probably simplify
> the implementation of our data provider.
>

You can limit memory consumption by streaming points, as mentioned
earlier.  If you can use the data directly from PDAL's PointTable/View for
visualization streaming won't buy you anything since you need to store the
data somewhere anyway.  However, most people doing visualization software
need to load the data on a graphics card so using PDAL's buffer doesn't
make sense.

Our software (gvSIG) is written in Java, so using PDAL means writing some
> Java-C++ bindings, that's why we want to carefully assess if PDAL fits our
> needs before actually implementing anything. I was (probably wrongly)
> feeling that libLAS could better suit our needs, but I am aware PDAL is
> much more active nowadays.
>

 Let us know if you have more questions.

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