[pdal] Ferry filter not working in LAZ file
Andrew Bell
andrew.bell.ia at gmail.com
Sat Apr 14 07:42:12 PDT 2018
Eric,
If you write version 1.2 LAS, the information about the extra bytes isn't
read by default. You have to tell the PDAL las reader what's in the extra
bytes of each record. You can do this with the option
--readers.las.extra_dims. If you're using PDAL 1.7, there's a new option,
--readers.las.use_eb_vlr that will read the extra bytes VLR that PDAL
writes (PDAL always writes the extra bytes VLR if there are extra bytes,
even in pre-1.4 LAS files). LAS files before version 1.4 may have extra
bytes written that don't have the VLR to define them, which is why the
extra_dims option is necessary. You can also simply write the file with
version 1.4 LAS by specifying --writers.las.minor_version=4.
I've tested filters.ferry and it seems to work fine in your scenario. If
you're not familiar with the details of LAS, it's sometimes easier to write
text output to verify that things are working as expected.
Hope that helps,
On Sat, Apr 14, 2018 at 9:59 AM, Eric Robeck <erobeck at gmail.com> wrote:
> Andrew,
>
> Thanks for your suggestion! I looked up the LAS Writer specification and
> used "extra_dims" to specify the additional fields created by the ferry
> filter and their types, as shown below. However, the dimensions are never
> added to the output file. I have tried using "extra_dims":"all" but with no
> luck. Are there parameters in addition to "extra_dims" that I need to
> specify? VLRs? The JSON pipeline I am using is copied below.
>
> I assumed that the extra DTM field wasn't being created, since it was not
> shown in the schema, statistcs, or point values accessed through 'pdal
> info' and because ferrying a new field didn't change the output file size.
>
> Per Howard's recommendation yesterday, I updated PDAL to 1.7.1 but I
> continue to get the same results.
>
> I will share this with the PDAL mailing group, but wanted to reply to you
> directly first. I appreciate your help.
>
> Thanks,
> Eric
>
>
> {
> "pipeline":
> [
> "C:/data/forest_park/forest_park_UTM_cropped.laz",
> {
> "type":"filters.ferry",
> "dimensions":"Classification=>OldClassification, =>DTM"
> },
> {
> "type":"filters.colorization",
> "dimensions":"DTM:1:1.0",
> "raster":"C:/data/forest_park/dtm/w001001.adf"
> },
> {
> "type":"writers.las",
> "compression":"true",
> "extra_dims":"OldClassification=uint8, DTM=float",
> "scale_x":"0.01",
> "scale_y":"0.01",
> "scale_z":"0.01",
> "offset_x":"auto",
> "offset_y":"auto",
> "offset_z":"auto",
> "filename":"C:/data/forest_park/forest_park_orig_dtm.laz"
> }
> ]
> }
>
>
>
> On Fri, Apr 13, 2018 at 6:09 AM, Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
>
>> Hi Eric,
>>
>> How do you know that the DTM field is not getting created? You'll have to
>> change the writer to put this field in LAS extra bytes if you want it to be
>> part of your output. See the option 'extra_dims' at
>> https://www.pdal.io/stages/writers.las.html for more info.
>>
>> On Fri, Apr 13, 2018, 12:05 AM Eric Robeck <erobeck at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have written a PDAL pipeline to perform the following steps:
>>>
>>> 1.) Ferry the existing Classification to the UserData field for storage
>>> (this is more efficient than creating a new field)
>>> 2.) Use the ferry filter to create a new DTM field
>>> 3.) Use the colorize filter to extract the elevation value from a
>>> single-band TIF (a DTM made from the original ground points)
>>> 4.) Run SMRF to reclassify the ground points
>>>
>>> I cannot get the ferry filter to work at all. It won't transfer values
>>> between existing columns or create new columns, despite using the same
>>> syntax described on PDAL.io. 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.
>>>
>>> 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.
>>>
>>> I am using PDAL 1.6.0 on Windows within OSGeo4W. It was installed this
>>> month. My pipeline is copied below.
>>>
>>> Any help would be greatly appreciated.
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>>> {
>>> "pipeline":
>>> [
>>> "C:/data/forest_park/filtered/forest_park_orig.laz",
>>> {
>>> "type":"filters.ferry",
>>> "dimensions":"Classification=>UserData, =>DTM"
>>> },
>>> {
>>> "type":"filters.colorization",
>>> "dimensions":"DTM:1:1000.0",
>>> "raster":"C:/data/forest_park/dtm/w001001.adf"
>>> },
>>> {
>>> "type":"filters.smrf",
>>> "cell":1.00,
>>> "cut":0,
>>> "scalar":1.25,
>>> "slope":0.00,
>>> "threshold":0.50,
>>> "window":10
>>> },
>>> {
>>> "type":"writers.las",
>>> "tag":"writerslas",
>>> "compression":"true",
>>> "scale_x":"0.01",
>>> "scale_y":"0.01",
>>> "scale_z":"0.01",
>>> "offset_x":"auto",
>>> "offset_y":"auto",
>>> "offset_z":"auto",
>>> "filename":"C:/data/forest_park/forest_park_orig_dtm.laz"
>>> }
>>> ]
>>> }
>>> _______________________________________________
>>> pdal mailing list
>>> pdal at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/pdal
>>
>>
>
--
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20180414/fdc0a310/attachment-0001.html>
More information about the pdal
mailing list