Point cloud generic

Point clouds only, with no imagery and no pose file: LAS or LAZ files in one point cloud folder such as pointcloud, nested as deep as you like. Everything needed is read from the file headers, so there is no CSV to prepare.

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.

• Where a file describes extra per-point fields (the LAS 1.4 Extra Bytes record), every minimum and maximum a field descriptor flags as filled in must be a real statistic: a value the field's data type can hold, not NaN or infinity, and a minimum no larger than the maximum. Unset placeholders such as the largest 64-bit integer on a u16 field, or ±DBL_MAX on an f32, fail the delivery. Write the actual minimum and maximum, or clear the descriptor's min/max flags (options bits 1 and 2) when your software does not compute them. The record must also be a whole number of 192-byte descriptors.

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 dataset type 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#