<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 9/14/20 6:39 AM, Andrew Bell wrote:<br>
<blockquote type="cite"
cite="mid:CACJ51z2SFxROetpXuV8iYw6reUSV3QFd0b3HjvE2nMAq7moEsQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep 14, 2020 at 5:02
AM Peder Axensten <<a href="mailto:Peder.Axensten@slu.se"
moz-do-not-send="true">Peder.Axensten@slu.se</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Pity.<br>
<br>
I see that the present users’ domain doesn’t seem to have a
need for bounding box header information. I believe that
users in other domains do – possibly few and small domains,
but who knows? To me it still seems an arbitrary limitation
and your arguments have not convinced me.</blockquote>
<div><br>
</div>
<div>PDAL has been around for about six years and this hasn't
come up, so I think this is a pretty unique ask. We
calculate the bounding area all the time with the existing
code and it works fine. The time it takes is dwarfed by the
time it takes to read the file itself, with no other
processing in place.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">But it’s your
prerogative.</blockquote>
<div><br>
</div>
<div>Actually, no. The code is there for you to do as you
wish. The data you want is there, you just have to write a
bit of code to fetch it.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> I’ll ponder what the
most viable option is for us: status quo with liblas, use
pdal for reading only, or make a pdal filter/writer and use
some workaround in our process chain. I will probably come
back for more advice... :-)<br>
</blockquote>
<div><br>
</div>
<div>If what you want is just to read a LAS file into memory,
then there's no reason not to use liblas if it meets your
requirements.</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
<div>-- <br>
</div>
</div>
<div dir="ltr" class="gmail_signature">Andrew Bell<br>
<a href="mailto:andrew.bell.ia@gmail.com" target="_blank"
moz-do-not-send="true">andrew.bell.ia@gmail.com</a></div>
</div>
<br>
</blockquote>
<br>
In my work we regularly work from a "tileindex" (which in this case
is an index of the the desired output tiles rather than calculated
from existing files). We then use OGR within python to iterate over
the features in the tile index and use that to override parameters
in the pipeline like "readers.tindex.bounds" (or
"readers.ept.bounds"), "writers.gdal.bounds",
"writers.gdal.filename", etc. Then each tile is submitted to a job
queue which lets us process the tiles in parallel.<br>
<br>
In our case the source is generally LAZ tiles, but relying on the
LAZ header for the bounding box would still present issues for us.
First, we generally set "readers.tindex.bounds" to be slightly
larger than "writers.gdal.bounds" to avoid edge artifacts in the
output tiles. Second, in our case the LAZ tiles are more-or-less
but not exactly grid aligned so using a tile bounding box would
produce no-data areas in the output tiles. (And this is after we
had PDAL re-write all the LAZ tiles which along with doing other
pre-processing and data cleanup, had the effect of correcting the
bounding box information in the header which was all over the place
as delivered).<br>
<br>
So for us, we've found it more useful to move the tile bounding box
identification a level above PDAL in our workflow.<br>
<br>
</body>
</html>