Tile structures and project headers — packaging large captures

If you've ever received a LiDAR delivery for a multi-hundred- hectare site and tried to open the first file in your CAD tool, you've met the tile-structure question. Below about 50 million points a single LAS file works fine; above that, single-file ingestion ranges from "very slow" to "your software won't load it at all". Tiling solves the problem — but tiling badly introduces its own.

This article follows on from the LAS / LAZ landscape article with the specific question of how multi-tile deliveries should actually be packaged. Size trade-offs, naming conventions, manifest content, and the buffer pattern that catches out the inattentive.

Why tile at all

Most desktop spatial tools have practical limits on file size they handle smoothly:

• CloudCompare handles single LAS files of up to ~10 GB before it gets uncomfortable; up to ~50 GB before it refuses.
• QGIS / ArcGIS Pro ingest LAZ natively but visualisation performance degrades past a few hundred million points per layer.
• AutoCAD Civil 3D / 12d read LAZ but have practical limits around 100-200 million points per surface.
• Memory — even modern workstations with 32-64 GB RAM struggle with single files past 1-2 billion points.

For a typical mid-sized capture — say a 200 hectare site at 80 pt/m² ground density (totalling ~1.6 billion points across all returns) — the cloud needs to be tiled to be workable. The question is how.

The square-grid pattern

The standard tile structure: an axis-aligned grid of square tiles, each tile containing all points that fall within its boundary. The grid is aligned to the project's coordinate system — typically MGA — so tile corners sit at round-number eastings and northings (e.g., every 500 metres on the 500 multiple).

This pattern is supported by every commercial and open-source LiDAR tool, easy to compute lookups against, easy to extend if the project boundary grows, and intuitively understandable.

Two less-common alternatives worth knowing about:

Strip-based tiling preserves flight strips as the organising structure — each tile is a contiguous along-strip segment. Useful for corridor projects where chainage drives the downstream workflow; less useful for area projects.

Adaptive tiling uses variable tile sizes based on local point density — smaller tiles where density is high, larger where it's sparse. Theoretically optimal for file balance, practically rare because the irregular grid is harder to navigate.

For 95% of production projects, square-grid is the right answer.

Tile size trade-offs

The standard size options, with their characteristic use cases:

| Tile size | Points/tile typical | Files per 100 ha | Use case | | --------------- | ------------------- | ---------------- | ------------------------- | | 250 m × 250 m | 4 — 25 million | ~160 files | Urban detail, asset work | | 500 m × 500 m | 15 — 100 million | ~40 files | Standard engineering | | 1 km × 1 km | 60 — 400 million | ~10 files | Regional / large captures | | 2 km × 2 km | 240 — 1.6 billion | ~2 — 3 files | Very large / coarse work |

Smaller tiles mean more files (administrative overhead, more header parsing) and smaller per-file size (faster individual loads, easier streaming). Larger tiles mean fewer files (less filesystem overhead, simpler manifest) but heavier per-file load (slower interactive use).

The 500 m × 500 m default suits most engineering work — a typical capture sits at 15-100 million points per tile, well within practical desktop tool limits, with file counts that stay manageable.

Specialist exceptions:

• Asset inspection or urban detail work often benefits from 250 m tiles because the detail review is concentrated in small geographic areas
• Regional flood modelling or very large mine sites often use 1 km tiles because the workflow processes per-tile rather than visualising interactively
• Corridor projects sometimes use chainage-based segments instead of geographic tiles

Worth specifying tile size explicitly at scoping if your project has any non-default requirement.

Grid alignment to project datum

A well-packaged tile grid aligns to round-number coordinates in the project's CRS:

• Tile origin at (E, N) = (500000, 6500000) — a round MGA intersection
• Tile boundaries on every 500 m multiple (or whatever the tile size is)
• Tile coordinates explicitly tagged in the manifest

This alignment matters because:

• Adjacent projects (separate captures, possibly years apart) using the same grid alignment produce tiles that compose seamlessly
• ELVIS public data and many other public LiDAR datasets use standardised grid alignments — matching the same grid simplifies integration
• Software tools that compute tile lookups from coordinates can do so trivially against an aligned grid

A capture that aligns to project-boundary corners instead produces tiles that don't compose with any other capture and make computational tile lookups awkward.

Naming conventions

Three patterns in production use:

Coordinate-based — filename encodes the tile's southwest corner coordinates. Example: tile_E500000_N6500000.laz. Computationally trivial to derive from any coordinate; clear human readability.

Grid-index-based — filename encodes row and column indices. Example: tile_R042_C087.laz or tile_055_023.laz. Compact, but requires a manifest to derive coordinates from filename.

Project-specific — filename encodes a project-relevant chunking. For corridor work, chainage: corridor_CH01000-CH01500.laz. For sub-area projects, area code: north_block_001.laz. Higher human readability for the specific project context; doesn't generalise.

The coordinate-based pattern is the safest default. It's self-documenting, computationally usable, and survives manifest loss. Grid-index naming is more compact but loses standalone meaning. Project-specific naming is fine when the convention is documented.

A clean naming spec follows the pattern {project}_{sensor-tag}_E{easting}_N{northing}.laz, producing files like projx_lidar_E500000_N6500000.laz. Lengthy but unambiguous.

The project header / manifest

Every multi-tile delivery should ship with a project header file documenting the structure. The manifest answers:

• What coordinate system + datum is the project in?
• What tile size + grid alignment?
• What naming convention?
• Which tiles are populated, which are empty?
• What classification scheme is in use?
• What QA results apply at the project level vs per-tile?
• What deliverable formats are included?

Two common formats:

JSON manifest — modern preference. Human-readable, machine- parseable, easy to extend with project-specific fields.

{
  "project_id": "PROJX-2026-04",
  "crs": "EPSG:7855",
  "vertical_datum": "AHD",
  "tile_grid_size_m": 500,
  "tile_origin": [500000, 6500000],
  "naming_convention": "tile_E{easting}_N{northing}.laz",
  "tiles": [
    {"easting": 500000, "northing": 6500000, "points": 47823491},
    ...
  ]
}

XML manifest — older convention. More verbose, more ceremony. Still common in deliveries to clients with legacy ingestion tooling.

Either works. The important thing is that something exists. A multi-tile delivery without a manifest forces downstream consumers to infer the structure from filenames, which is brittle and time-consuming.

Per-tile QA metadata

A reputable delivery also includes per-tile QA metadata, either embedded in the manifest or as a sidecar file per tile. Useful per-tile information:

• Point count (all returns + ground-classified)
• Bounding box (slightly more precise than the tile grid if the project boundary is irregular)
• Mean point density (returns per square metre)
• Classification class distribution
• Validation against any control checkpoints falling inside the tile

For projects accepting tiled deliveries, the per-tile QA helps identify problem areas — a tile reporting much lower density than its neighbours, or a tile with unusual classification distribution, surfaces issues for review before they propagate into design.

The tile-plus-buffer pattern

A subtle issue with tiled deliveries: surfaces generated per-tile don't quite match at tile edges.

If the DTM is generated tile-by-tile (interpolating only within each tile boundary), the surface immediately inside a tile edge is built from fewer surrounding points than the surface in the tile interior. Edge values get noisier; adjacent tiles disagree slightly along their shared boundary; the assembled multi-tile surface has visible seams.

The fix is tile-plus-buffer processing:

1. Each tile is processed with a buffer of overlap from neighbouring tiles (typically 20-50 m on each side)
2. Surface generation runs over the full buffered area
3. Only the un-buffered tile portion is exported

The result: edge values are interpolated from the same point density as interior values; adjacent tiles agree at their shared boundaries; the assembled multi-tile surface is seamless.

For point cloud deliverables, the buffer is sometimes preserved in the tile (each tile contains slightly more points than its nominal extent suggests, with an explicit "buffer zone" flag). For raster deliverables, the buffer is cropped out before delivery.

Worth asking whether tile-plus-buffer processing was used — the answer is usually yes for engineering work, but worth confirming.

Common tile structure mistakes

Three patterns in marginal deliveries:

Tile boundaries on project-boundary corners. The grid is aligned to the project rather than to MGA coordinates. Tile lookup from arbitrary coordinates requires the manifest; adjacent projects don't compose. Avoid by aligning to round MGA coordinates.

Inconsistent tile size across the project. Some areas use 500 m tiles, others use 1 km. The varying size is awkward to navigate and harder to ingest. Avoid by picking one tile size for the whole project at scoping.

Empty manifest or no manifest at all. Downstream consumers have to infer structure from filenames; new team members can't work with the delivery without help; future re-use is painful. Avoid by treating manifest as part of the deliverable, not an afterthought.

TL;DR

Above 50 million points, single-file LAS is impractical. The standard answer is a square-grid tile structure aligned to round MGA coordinates with coordinate-based filenames. Tile size defaults to 500 m × 500 m for engineering work; smaller for detail, larger for regional.

Every multi-tile delivery needs a manifest documenting the grid, datum, classification and contents. Per-tile QA metadata helps identify problem areas before downstream impact.

Tile-plus-buffer processing prevents seam artefacts at tile boundaries — worth confirming the operator uses it.

Specify all of the above at scoping rather than discovering at delivery what got included.