I have txt files I use to keep track of the process---mostly to help with the lastools command line stuff. I have one for each different state projection I tend to use:
UTM Projection is 16 Northern Hemisphere (32616).
From NOAA program: WMMGUI
Grid-Magnetic, for Karttapullautin: - 7° 12' = -7.2
clipping boundary is: -keep_xy 698300 4392100 702500 4393900
Commands used:
lasmerge -i *.las -olaz -o Park_Name_merged.laz
las2las -i Park_Name_merged.laz -o Park_Name_UTM.laz -sp83 OH_S -survey_feet -elevation_surveyfeet -target_utm 16N
Entire Park: clipped:
las2las Park_Name_UTM.laz -o Park_Name.laz -keep_xy 698300 4392100 702500 4393900
lastile -i Park_Name.laz -olaz -tile_size 1000 (only if the park file is too big to process)
las2dem -i Park_Name.laz -oasc -keep_class 2 -utm 16S (might not work if too large)
So:
merged: state projection, not clipped (full tiles)
UTM: not clipped (full tiles, but reprojected)
Park_Name.laz: reprojected, clipped to "rectangle of interest".
lastile strips out some data above a threshold point number, so I try to not tile unless I need to. Sometimes, I use the -keep_xy las2las switch and create tiles that way. I recently had a park with such dense tiles I had to create 500m tiles to get it to run.
Also, note that -keep_xy is not the same as -keep_XY.
I use OL-Laser and Karttapullautin. I've started trying to figure out Terje's python script method. I've done a few lidar things with OCAD 11, but it seems to be more automatic and I don't like the loss of control. If it can create useful vector layers, I'll be more inclined to use it. For large parks that require tiling to get small grid sizes, I also process contours at the smallest grid I can and still get the whole park. For example, I find a 3m grid gives a good starting point for fieldchecking---it's not too noisy, but it shows fairly small details. But for a big park, I'll use a grid of 6m (or even 10m) if I have to just to get vector contours of the whole park. For the tiles, I typically run contours at both 1m and 3m grids, but if I can do the whole park file at 3m grid, I won't run the tiles at 3m.
I process state-plane aerials in QGIS. I merge, reproject (warp), and clip. Merging requires certain image types: GeoTIFF works and jpg doesn't, so I tend to work in TIFF until I clip, and then I "extract projection" to create world files (.wld), then "Convert" tiffs to jpgs. Finally I rename the .wld to .jgw---as long as the pixel sizes are the same, the world files will work. The newer versions of QGIS might not need the jgw---the "Convert" process creates an xml that seems to do the job. I think I've tiled automatically, but I can't remember. I've definitely tiled using manual coordinates typed into the clipper. Also, when I have used tiles, I have started using QGIS to merge the various lidar products into a whole park image as long as the file sizes aren't too big.
I keep seeing non-orienteering references to processing lidar with GRASS-GIS, but I haven't figured that out yet, either. I use two SAGA-GIS features, but in the QGIS Processing toolbox. I create a DEM (last command line, above), and run the Wetness Index algorithm, then I save (as rendered image, not data) two images: Catchment Area and Wetness Index. This seems to help find ditches and streams, especially on slopes. (You need to end up with the georeferencing world files, and you can use QGIS to convert to jpg if desired.) I'm trying to create vectorized streams and ditches, but I haven't had any luck. TauDEM and LSDTopoToolbox are supposed to be able to vectorize streams and extract channels, but I haven't tried them yet.