<div dir="ltr">Hi Jim:<br><br>Thank you very much for answering.<br><br>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.<br><br>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.<br><br>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?<br><br><div>Regards</div><div><br></div><div>Ulises<br></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 21 dic 2022 a las 1:01, Jim Klassen (<<a href="mailto:klassen.js@gmail.com">klassen.js@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    On 12/16/22 19:19, Ulises Ibarra wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Hello everyone:</div>
        <div>I have a question about the use of filters.litree. When I
          run:</div>
        <div><br>
        </div>
        <div>$ pdal pipeline ./litree_prueba.json</div>
        <div><br>
        </div>
        <div>where de ./litree_prueba.json:<br>
        </div>
        <div><br>
        </div>
        <div>[<br>
                 "./input.las"<br>
              {<br>
                  "type":"filters.hag_delaunay"<br>
              },<br>
              {<br>
                  "type":"filters.sort",<br>
                  "dimension":"HeightAboveGround",<br>
                  "order":"DESC"<br>
              },<br>
              {<br>
                  "type":"<span><span>filters.litree</span></span>",<br>
                  "min_points":50,<br>
                  "min_height":3.0,<br>
                  "radius":50.0<br>
              },<br>
              {<br>
                  "type":"writers.las",<br>
                  "filename":"./<a href="http://output.as" target="_blank">output.as</a>",<br>
                  "minor_version":4,<br>
                  "extra_dims":"all"<br>
              }<br>
          ]</div>
        <br>
        <div>I get de following output: <br>
        </div>
        <div>"PDAL: All points collinear"</div>
        <div><br>
        </div>
        <div>And the file "output.las" was never created.<br>
        </div>
        <div><br>
        </div>
        <span lang="en"><span><span>Could you guide me
              on what I'm doing wrong, please?</span></span></span><br>
        <div><br>
        </div>
        <div>Thank you</div>
        <div><br>
        </div>
        <div>Ulises<br>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
  </div>

_______________________________________________<br>
pdal mailing list<br>
<a href="mailto:pdal@lists.osgeo.org" target="_blank">pdal@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pdal" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pdal</a><br>
</blockquote></div></div>