Size COPC octree from union bbox when merging multiple inputs by agrigoriev · Pull Request #296 · r-lidar/lasR

agrigoriev · 2026-04-26T06:04:55Z

This pull request improves the robustness and correctness of merged COPC (Cloud Optimized Point Cloud) file writing by ensuring accurate 3D bounding boxes and point counts are used throughout the pipeline. It enforces strict validation of input metadata, updates the handling of 3D bounds in both reading and writing, and adds safeguards to prevent malformed outputs when merging multiple files. A new test verifies the correctness of the merged COPC output.

Improvements to 3D bounding box and point count handling:

Enforces that all features in a VPC (Virtual Point Cloud) file must have a consistent 3D bounding box (proj:bbox with 6 elements); mixed 2D/3D bboxes now cause a clear error, preventing silent creation of malformed merged outputs. [1] [2] [3] [4]
Updates the reading of point counts in read_vpc to use 64-bit integers, preventing silent truncation for large datasets.
Ensures the union 3D bounding box and total point count are properly tracked and exposed in FileCollection, and used when merging files into a single COPC output. [1] [2] [3] [4] [5]

COPC writing and validation enhancements:

In LASRlaswriter, captures the union bounding box and total point count from the input collection and uses them to size the COPC octree and compute the correct auto max_depth for merged outputs; refuses to write merged COPC files if the input lacks a valid 3D bounding box. [1] [2] [3] [4]
Updates the VPC writing logic to always emit 6-element 3D proj:bbox arrays, aligning with the stricter requirements for merged COPC outputs. [1] [2] [3]

Testing improvements:

Adds a new test to verify that merging multiple input files into a single COPC output produces the correct union bounding box and point count, ensuring the octree is sized to the union of all input files.

Fix 5 from the maintainer review on #296. The catalog union-bbox override in set_header was applied to every initialization, including per-file COPC mode (`*.copc.laz` template with a `*` placeholder) where each output file should use its own tile's bbox. Per-file outputs were being inflated to cover the whole input set. Gate the override on (catalog_bbox_valid && merged && path_has_copc_suffix(template_filename)) so: - single-file COPC (merged) keeps the union override (correct) - per-file COPC (`*` placeholder) uses each tile's own bbox - non-COPC writes are untouched (they ignore bbox at open anyway, but explicit gate keeps it clear) Verified: per-file COPC writes of bcts_1+bcts_2 produce two outputs with their own per-file bbox in the COPC info VLR (file 1 center_y ~629279, not the union 629429). Merge mode unchanged.

Two follow-up fixes for #296: Issue 1 — auto max_depth used file-1's count, not the merged total. LASRlaswriter::set_header overrode bbox for merged COPC but left header.number_of_point_records as the per-tile count. LASio::init saves whatever count it sees, and COPCwriter's compute_max_depth heuristic divides total points by max_points_per_octant (100000) to pick depth — so a 1.35M-point merge picked depth from file-1's 531k count alone, ending up too shallow for the merged data set. - FileCollection::get_total_points() sums header counts across every input. - LASRlaswriter::process(FileCollection*&) captures the total. - set_header overrides h.number_of_point_records with the catalog total when writing merged COPC. Verified: bcts_1+bcts_2 merge now produces 88 hierarchy entries vs 40 with file-1's count alone, and depth-3 reads now return all 1.35M points. Issue 4 — VPC z bounds were dropped, catalog_bbox_valid only checked x/y. read_vpc parsed the 6-element STAC proj:bbox using indices [0,1,3,4] (skipping z at [2] and [5]); FileCollection's zmin/zmax stayed at numeric_limits defaults. Combined with the write-side check that ignored z, merged COPC from a VPC could get bogus z bounds and either fail late (degenerate-bbox check) or silently clamp. - read_vpc reads min_z/max_z from 6-element bbox and updates headers + catalog z accumulators. - catalog_bbox_valid now requires zmin ≤ zmax in addition to x/y validity.

Issue 10 from the latest review on #296. The lasR-emitted VPC was a closed loop bug: write_vpc wrote properties.proj:bbox as 4 elements (no z) and a 6D top-level "bbox" field, but read_vpc only inspects properties.proj:bbox. Round-tripping a lasR-generated VPC into a merged COPC write therefore lost z bounds on the catalog side, the writer's catalog_bbox_valid check (which now requires z) returned false, and the union bbox/count override was silently skipped — falling back to the per-tile bbox of file 1. Switch the proj:bbox write to the 6-element form [minx, miny, minz, maxx, maxy, maxz]. The reader already handles both the 4D and 6D forms (post-#296), so this stays compatible with VPCs emitted by other tools. Separately, pc:count was parsed as `int`. The STAC pointcloud extension puts no upper bound on the field, and a catalog over ~2.1B points would silently truncate, mis-sizing the auto max_depth heuristic. Read as uint64_t.