Warnings about number of points while piping

[Jean-François Bourdon]

I'm exploring ways of speeding of up our workflow and piping seems a good way to achieve that. So I gived it a try with the fusa dataset looking to:

1. Reset classification to 1
2. Classify ground
3. Use this new classified point clouds to produce a DEM, a density grid of ground points and a density grid of first returns

las2las -i fusa.laz -set_classification 1 -stdout |^

lasground_new64 -stdin -stdout |^

las2dem -stdin -pipe_on -keep_class 2 -step 1 -o dem.tif |^

lasgrid -stdin -pipe_on -density -keep_class 2 -step 1 -o density_ground.png |^

lasgrid -stdin -density -keep_first -step 1 -o density_first.png

I get what I want, but I also get these warning and error messages:

WARNING: written 161864 points but expected 277573 points

ERROR: stream not seekable. cannot update header from 277573 to 161864 points.

WARNING: end-of-file after 161864 of 277573 points

As far as I know, 277573 is total number of records and 161864 is number of ground points... but why these messages?

On a side note, piping is not very much documented in the README other than if -stdin / -stdout can be used with a given tool. It would be a good addition to have a seperate README (or inside each README) explaining how to use piping. It may not be that essential, but it would be faster than looking into the different threads in this forum. For example, what I finally understound is that -pipe_on is needed to pass the last -stdout to the next tool. Maybe I'm slow also...

[Jean-François Bourdon]

And now I'm confused because with fusa dataset, it took 2 seconds more with piping than without. I also tried with a larger dataset (a 300 MB LAS) and the difference was just enormous with several times slower with piping than without even if two intermediate 300 MB LAS need to be written/read to/from disk (las2las and lasground operations). I must be doing something wrong.

Thanks for any help on this

[Martin Isenburg]

Hello,

just going through some old emails and found this:

The way that the pipe is implemented is that it takes the content after all filters and transforms are applied and pipes this one on so that after the first '-keep_class 2' only the ground points are being piped on, which makes the second '-keep_class 2' kind of redundant.

las2las -i fusa.laz -set_classification 1 -stdout |^

lasground_new64 -stdin -stdout |^

las2dem -stdin -pipe_on -keep_class 2 -step 1 -o dem.tif |^

lasgrid -stdin -pipe_on -density -keep_class 2 -step 1 -o density_ground.png |^

lasgrid -stdin -density -keep_first -step 1 -o density_first.png

The final '-keep_first' will then only contain ground points that are first returns and not deliver the intended result.

I could see that a '-pipe_on_raw' command would be useful to pipe on the unmodified input but that would require some major code updates.

According to your experiments the efficiency of piping is not great compared to writing to temporary LAS files, that probably get cached by the file system and do not actually need to be reread from disk.

Regards,

Martin

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/0ac53368-7f85-4430-8fd9-943ad7964fc7o%40googlegroups.com.