[pdal] About litree filter output: "PDAL: All points collinear"

[Ulises Ibarra]

Hi Jim:

Thank you very much for answering.

I thought that the origin of the problem was due to the fact that the
input.las file was made from the union of several files obtained by (TLS)
terrestrial scanning. I can't understand the concept of PointView, and I
imagined that the error was that there were many points where the
terrestrial scanner is located, but when making a large file made of small
files, that information was lost.

I did a test with a single file and got good results even though multiple
trees were considered under the same ClusterID. I subsampled the original
file with filters.sample.radios=0.020. And to this file I applied the
pipeline that I sent in my previous email with small modifications.
Processing time was around 24 hours.

In total I have 47 scans of that piece of rainforest. A question: What do
you think about the processing time of a large file that contains the 47
scans: Could it take 24 hours X 47 files = 1128 hours?

Regards

Ulises


El mié, 21 dic 2022 a las 1:01, Jim Klassen (<klassen.js at gmail.com>)
escribió:

> On 12/16/22 19:19, Ulises Ibarra wrote:
>
> Hello everyone:
> I have a question about the use of filters.litree. When I run:
>
> $ pdal pipeline ./litree_prueba.json
>
> where de ./litree_prueba.json:
>
> [
>        "./input.las"
>     {
>         "type":"filters.hag_delaunay"
>     },
>     {
>         "type":"filters.sort",
>         "dimension":"HeightAboveGround",
>         "order":"DESC"
>     },
>     {
>         "type":"filters.litree",
>         "min_points":50,
>         "min_height":3.0,
>         "radius":50.0
>     },
>     {
>         "type":"writers.las",
>         "filename":"./output.as",
>         "minor_version":4,
>         "extra_dims":"all"
>     }
> ]
>
> I get de following output:
> "PDAL: All points collinear"
>
> And the file "output.las" was never created.
>
> Could you guide me on what I'm doing wrong, please?
>
> Thank you
>
> Ulises
>
>
> I've seen that error before when using hag_delaunay.  It's complaining it
> can't make triangles (delaunay triangulation) because it thinks all of the
> input points fall on a line.  I found that sometimes hag_nn will work in
> these situations.  It has been awhile since I've hit that error (so I was
> using an older version of PDAL), it was sporadic (only occurred on some
> input tiles) and I didn't have time to track down the exact points that
> were causing it.
>
> I'm assuming (dangerous, I know) that PDAL is looking at some subset of
> close points when it is constructing the triangulation and that the error
> is stating that all points were collinear in one/some of those subsets
> rather than saying that the entire point cloud is collinear.  However, if
> all of the source points are actually all collinear, then that would
> explain it.
>
> If I remember right, this tended to happen on messy (noisy), very dense
> (higher point density than reasonable given the precision of the
> measurements) point clouds where I suspect that it may have been possible
> for the point cloud to have areas where there were many points at the same
> or nearly the same X,Y,Z.  Another possibility was the error being
> triggered by some odd (noise) points forming nonsensical geometries.  But
> as I said, I never did have time to track down the root cause for sure.
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20221227/e19e3b2d/attachment.htm>