Reference implementation · runs in your browser

PointCloud-ID 1.0

A deterministic content identity for geospatial point clouds: invariant under lossless re-encoding, and able to localize any change to a chunk and an attribute. Every computation on this page runs client-side and reproduces the committed test vectors, so you can check the claims yourself without taking anything on faith.

See why a file hash is not enough Compute an identity

The core idea in one screen

Three files, three SHA-256 digests, one PointCloud-ID

Here is the same 10-point survey serialized three ways, the way LAS, LAZ, and COPC differ at the byte level: record order and framing change. A file hash disagrees on all three. Canonicalize the content first, and the PointCloud-ID is identical. Hashes below are computed live with Web Crypto SHA-256.

PointCloud-ID (all three files)

computing…

Same content, one identity. A byte hash cannot tell honest re-encoding from tampering; this can, and it localizes what changed.

Reproduce it yourself

Compute a PointCloud-ID

Edit the points and recompute. Attributes are LAS-native domains (intensity u16, classification u8, GPS time float64, RGB u16, returns u8). The profile is the paper's toy profile (scale 0.5, offset 0, chunk depth 1). The unedited vector must return 37fdee62…, the ID committed in the repository.

Points · JSON

or drop a .json points file here

What the profile does

Canonicalization explorer

The same points, quantized to the grid, encoded as 63-bit Morton codes, and put in canonical order. This order is a pure function of content, which is why reordering a file changes nothing. Chunks are the Morton prefix; a change localizes to one (chunk, attribute) pair.

#	x	y	z	qx	qy	qz	morton	chunk

Check a claim without the cloud

Verify a proof or a signed manifest

A membership proof shows one (chunk × attribute) leaf is committed to a published ID using only an O(log n) sibling path. A signed manifest checks the COSE / Ed25519 signature over the canonical bytes. Both run here with Web Crypto.

Proof document · pcid-proof-1

Awaiting a document

Load a proof or signed manifest, then verify.

Committed, reproducible

Test vectors

Every vector below is committed in the repository and regenerated byte-identical by the reference implementation. This page recomputes them in front of you.

Everything else

Docs, API, and source

Reference API

// stage 1: canonicalize (spec §3)

quantize(v, offset, scale) → int in [0, 2²¹)

encodeMorton3(qx, qy, qz) → 63-bit code

canonicalize(points, profile) → chunks

// stage 2: identity (spec §4-5)

buildAttributeTree(chunks, attr) → root

pointCloudId(trees, profile) → 32-byte ID

proveMembership(…, attr, chunk) → proof

// stage 3: sign (spec §6)

signManifest(bytes, key) → COSE_Sign1

verifyMembershipProof(doc) → verdict

Reproduce locally

$ npm run typecheck && npm test # 55 tests

$ npm run gen:vector # toy-10pt → 37fdee62…

$ python eval/pcid.py # independent NumPy check

Resources

Methods paperavailable on publication Canonicalization profile v1spec Reference implementationTypeScript Evaluation protocol E1–E5NumPy LicenseMIT + CC-BY-4.0

Open source & research

Reference impl (TypeScript, zero runtime deps), an independently written NumPy re-computation, and a deterministic evaluation harness accompany the paper. Identity is defined only under a declared canonicalization profile.