[pdal] Ferry filter not working in LAZ file
Eric Robeck
erobeck at gmail.com
Sat Apr 14 10:11:49 PDT 2018
Andrew,
Writing to LAS 1.4 format did the trick! I had been specifying the
"extra_dims" option in the "writers.las" stage, so I'm not clear as to why
it wasn't working. But I will continue to use version 1.4 as backwards
compatibility is not an issue.
Thanks for the quick reply.
Regards,
Eric
On Sat, Apr 14, 2018 at 9:42 AM, Andrew Bell <andrew.bell.ia at gmail.com>
wrote:
> 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/8374f61a/attachment.html>
More information about the pdal
mailing list