Hello Alan,
I have improved your workflow to what you see below. The *most* important improvement is to run lasindex *before* lastile in case you want to run lastile with multiple cores. There are two good choices for lastile:
1) run lastile on a single core
2) first run lasindex and then run lastile on multiple cores
but running lastile with multiple cores *without* having spatially indexed LiDAR is a very bad option. That will generally be much slower than simply running lastile on a single core. Without spatial indexing each core will have to reach most of the LiDAR and you drown in I/O overload. For the combination of lastile with multiple cores the spatial indexing information is crucial. I should let the lastile tool issue a warning in future versions.
Once you have buffered tiles there is no more need for spatial indexing because each tile gets processed on its own (without querying the data along the edges from neighbor tiles) and because there is no spatial area-of-interest query happening (each tile gets loaded and processed completely. Hence the later calls to lasindex gave no performance gains at all.
When does lasindex give performance gains?
(a) during multi-core tiling
(b) during on-the-fly buffering with '-buffered 200'
(c) during area-of-interest queries with '-inside xxx xxx xxx xxx' calls
(d) during clipping operations (e.g. lasclip, lascanopy with 'lop')
(e) when picking a rectangular area in the LAStools GUIs
(f) typical clip, zip, ship server operations like:
las2las -i server2\area34\*.laz -merged ^
-inside 203525 5354475 205575 5357525 ^
-o download\user_request_002635.laz
=====================
lastile -i -v f:\BayfieldCo_WI_LIDAR\Classified_LAZ\*.laz ^
-drop_scan_angle_above 15 ^
-drop_scan_angle_below -15 ^
-tile_size 2000 -buffer 300 ^
-keep_class 1 2 ^
-odir %BLOCK%\laz_tiled -olaz ^
-cores %CORES%