Point cloud generic

For deliveries that are only point clouds, with no imagery and no pose file. Everything the platform needs is read out of the LAS/LAZ headers, so there is no CSV to get wrong.

Folder layout#

<dataset bucket>/
└── pointcloud/            one of three accepted names — see below
    ├── tile_001.laz
    ├── tile_002.laz
    └── subfolder/         nested folders are scanned too
        └── tile_003.laz

The pointcloud folder is looked for under these names, in this order — the first containing at least one matching file wins:

1. pointcloud/
2. Pointcloud/
3. ingest/Pointcloud/

The others are then not scanned at all. If you deliver into two of them, only one is indexed — so pick one.

If none of the three exists, or none contains a point cloud file, the run fails. That is deliberate: a point-cloud-only delivery with no point clouds is never what you meant.

Files#

Supplier-delivered .copc.laz files are accepted like any other LAZ. There is no filename convention — name your tiles whatever your export produces.

What is read from each file#

Only the LAS public header, via a ranged read of the first 64 KiB — the point data itself is not downloaded during indexing. From that header:

• min_x / min_y / max_x / max_y become the file's 2D boundary.

• The point data record format decides whether the file is flagged as having colour: formats 2, 3, 5, 7, 8 and 10 carry RGB.

• The LAS public header of each point cloud file must parse (it is read from the first 64 KiB). A corrupt or truncated header fails the run, naming the file.

• Point-data record formats 0 and 2 carry no GPS time, so the merged point cloud gets no temporal index and cannot be filtered by capture time. (a warning, not an error)

• The point records must actually be there: a header can parse while the data behind it is truncated (a half-finished upload or copy). Checked for uncompressed LAS, where the declared point count and record length give an exact expected size; LAZ stores points in variable-size chunks, so the same arithmetic does not apply.

Coordinate reference system#

Nothing is reprojected. Boundaries are stamped with the dataset's 2D SRID and the delivered coordinates are taken as-is. The CRS recorded in the LAS header is not read and not checked.

Deliver in the dataset's configured CRS. See Coordinates are not reprojected.

Ingest parameters#

None are required. This template runs on a dataset with an empty parameter set.

What you get back#

• One indexed record per source file, in the set named source.
• A single merged COPC point cloud at copc/pointcloud.copc.laz, built from every indexed file. This is what the web viewer streams.

The merged output carries a temporal index when the source files have GPS time — that is, point data record formats 1, 3, 4, 5, 6, 7, 8, 9 and 10. Formats 0 and 2 have no GPS time, so the index is skipped; the ingest still succeeds, but the result cannot be filtered by capture time. Only the first file is inspected, so a delivery mixing formats is decided by whichever file sorts first.

The merged output lives outside all three source prefixes, so re-running never feeds the previous output back into itself.

Re-running is safe and is the normal way to fix a bad delivery — see Re-running is safe.

Common failures#