<div dir="ltr"><br><div><div><div>Howard,<br><br><br></div>Thanks for your suggestions.
I updated PDAL to 1.7.1. I didn't notice a difference with regards to
precision, but most* ferry operations work, as long as they are to existing fields. Because the field I use to store the DTM elevation (Red) is
an integer, I scale it by 100 so there is no loss of precision.
<br><br>
The pipeline I would like to use is shown below. I transfer the existing
classification to a new dimension, then create a DTM dimension that is
populated in the next step. Because the dimensions are not saved,
however, I use the substitute approach, below, which works. I ferry the
Classification to UserData, which has the same dimension type, then use
Red to store the DTM value x 100 because it is an integer.
<br>
<br>
Based on a suggestion by Andrew Bell, I tried using the "extra_dims" option in Writers.las to specify the
additional fields created by the ferry filter and their types, as shown
in the first pipeline below. However, the dimensions are never added to the output file. Are there
parameters in addition to "extra_dims" that I need to specify? VLRs? Do I need to write to uncompressed LAS files first?<br><br></div><div>Pete Gadomski's workflow was a great inspiration and helped me develop my substitute pipeline below. Thank you for the link!<br></div><div><br><br></div><div>* I noticed some weird behavior with the assign filter that I want to point out. When assigning multiple dimensions, sometimes one doesn't get assigned. It appears to depend on the order of the assignment. For example, in this stage Classification, Blue and Green are correctly assigned, but GpsTime is not:<br><br> {<br> "type":"filters.assign",<br> "assignment":"Classification[:]=0",<br> "assignment":"GpsTime[:]=50",<br> "assignment":"Blue[:]=10",<br> "assignment":"Green[:]=20"<br> },<br></div><div><br></div><div>However, when I take out the "GpsTime" assignment and replace it with "Green", the Green assignment fails, despite having the same value:<br></div><div><br> {<br> "type":"filters.assign",<br> "assignment":"Classification[:]=0",<br>
"assignment":"Green[:]=20",<br> "assignment":"Blue[:]=10"<br> },<br><br></div><div>I got around this by leaving the "GpsTime" spacer in the above example since my goal was to update Blue and Green only. Apparently the second "assignment" is being ignored by PDAL.<br></div><div><br></div></div><div><br></div><div>Thanks,<br></div><div>Eric<br><br></div><div><br><b><u><br></u></b></div><div><b><u>Ideal Pipeline:</u></b><br><br></div><div><span style="font-family:monospace,monospace">{<br> "pipeline":<br> [<br> "C:/data/forest_park/forest_park_UTM_cropped.laz",<br> {<br> "type":"filters.ferry",<br> "dimensions":"Classification=>OldClassification, =>DTM"<br> },<br> {<br> "type":"filters.colorization",<br> "dimensions":"DTM:1:1.0",<br> "raster":"C:/data/forest_park/dtm/w001001.adf"<br> },<br> {<br> "type":"writers.las",<br> "compression":"true",<br> "extra_dims":"OldClassification=uint8, DTM=float",<br> "scale_x":"0.01",<br> "scale_y":"0.01",<br> "scale_z":"0.01",<br> "offset_x":"auto",<br> "offset_y":"auto",<br> "offset_z":"auto",<br> "filename":"C:/data/forest_park/forest_park_orig_dtm.laz"<br> }<br> ]<br>}<br></span></div><div><div><br></div></div>
<u><b>Substitute Pipeline:</b></u><br><br><span style="font-family:monospace,monospace">{<br> "pipeline":<br> [<br> "C:/data/forest_park/forest_park_UTM_cropped.laz",<br> {<br> "type":"filters.ferry",<br> "dimensions":"Classification=>UserData"<br> },<br> {<br> "type":"filters.colorization",<br> "dimensions":"Red:1:100.0",<br> "raster":"C:/data/forest_park/dtm/w001001.adf"<br> },<br> {<br> "type":"writers.las",<br> "compression":"true",<br> "scale_x":"0.01",<br> "scale_y":"0.01",<br> "scale_z":"0.01",<br> "offset_x":"auto",<br> "offset_y":"auto",<br> "offset_z":"auto",<br> "filename":"C:/data/forest_park/forest_park_orig_dtm.laz"<br> }<br> ]<br>}</span><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 10:12 AM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><span class="gmail-"><blockquote type="cite"><div>On Apr 12, 2018, at 11:05 PM, Eric Robeck <<a href="mailto:erobeck@gmail.com" target="_blank">erobeck@gmail.com</a>> wrote:</div><br class="gmail-m_-3329503787266451036Apple-interchange-newline"><div><div dir="ltr"><div><div>Hello,<br><br></div>I have written a PDAL pipeline to perform the following steps:<br><br>1.) Ferry the existing Classification to the UserData field for storage (this is more efficient than creating a new field)<br></div></div></div></blockquote><div><br></div></span><div>Did you find this to be the case? Adding another dimension shouldn't really have an extra cost.</div><span class="gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div>2.) Use the ferry filter to create a new DTM field<br></div></div></div></blockquote><br><blockquote type="cite"><div><div dir="ltr"><div>3.) Use the colorize filter to extract the elevation value from a single-band TIF (a DTM made from the original ground points)<br></div></div></div></blockquote><div><br></div></span><div>Pete Gadomski made a post about this contorted scenario that's currently required. See <a href="http://www.gadom.ski/2018/02/28/pdal-hs.html" target="_blank">http://www.gadom.ski/2018/<wbr>02/28/pdal-hs.html</a> for some details.</div><span class="gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div>4.) Run SMRF to reclassify the ground points<br></div><div><br>I cannot get the ferry filter to work at all. </div></div></div></blockquote><div><br></div></span><div>The syntax in your pipeline is 1.7's syntax, but you stated you're using 1.6.0. This might be the discrepancy. We want to make this scenario better. filters.colorization is a bad name for what it does (it's really raster overlay). 1.7 fixed the precision issue [1] when doing the task.</div><span class="gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div>It won't transfer values between existing columns or create new columns, despite using the same syntax described on <a href="http://PDAL.io" target="_blank">PDAL.io</a>.
I have tried various ways to get around this issue. Changing the order
of filters.ferry in the pipeline didn't make a difference. I saw that
the online examples worked on uncompressed LAS files, so I converted the
input files from LAZ to LAS but there was no change. The pipeline completes without errors, but info --stats and info --schema show that the ferried fields were not created or updated.<br>
<br>The colorize filter works fine, as long as I use an existing field. For example,
"dimensions":"Red:1:1000.0" works by mapping the elevation values to the Red field and multiplying by 1000 to preserve millimeter precision in an integer field. However,
"dimensions":"DTM:1:1000.0"
does not, because the ferry filter doesn't create the DTM field. The SMRF filter also works well, but without the ability to ferry values I lose the original classifications.<br></div><div><br></div><div>I am using PDAL 1.6.0 on Windows within OSGeo4W. It was installed this month. My pipeline is copied below.<br></div></div></div></blockquote><div><br></div></span><div>PDAL 1.7.1 is now available via OSGeo4W64. I don't know that this will solve any issues for you, but we will be talking about the same codebase as far as functionality goes. I know that the filters.ferry syntax was amended to be more explicit about where data from dimensions should be going.</div><div><br></div><div>Hope this helps. Pete's write-up is a good one of how to achieve what you're after.</div><div><br></div><div>[1] <a href="https://github.com/PDAL/PDAL/pull/1841" target="_blank">https://github.com/PDAL/<wbr>PDAL/pull/1841</a></div></div><br></div></blockquote></div><br></div></div>