Loading data

Supported formats

Format	Extension	Notes
COPC point cloud	.copc.laz	The primary target. LOD streaming via the octree works
Raw LAS / LAZ	.las / .laz	Opens as-is, no conversion needed. A large .las automatically becomes a thinned preview (below)
3D Gaussian Splatting	.ply / .spz and others	Display only. Not a target for measuring, selecting, or editing
Reference surface (TIN)	J-LandXML / DXF / SHP / IFC	Overlays a design surface on the point cloud (below)

Opening raw LAS / LAZ as-is

.las / .laz (an ordinary point cloud file, not COPC) can be opened directly by drag-and-drop, file picker, or URL load. There's no conversion step, but there's no octree-based staged loading like COPC — once the count is known from the header, every point is read at once and stays resident from then on (never thinned or evicted by LOD).

For small to medium sizes (up to 20 million points), this loads every point.

A large .las automatically becomes a thinned preview

An uncompressed LAS with more than 20 million points opens directly as a thinned preview, with no confirmation asked. Point records in uncompressed LAS are fixed-length and contiguous, so points can be sampled evenly across the whole file without reading it all — measured in practice: pulling 2 million points from a 40GB, 1.2-billion-point file reads only 68MB (0.17% of the file).

While previewing, a badge at the top of the screen always shows the real point count and the thinning ratio. Measuring and filing findings are disabled in this state. The thinned points are real (their coordinates are correct), but the point you actually wanted may simply not have been read, and a value could silently be off from reality.

Compressed LAZ can't be thinned this way (it can only be decompressed chunk by chunk, and the chunk table itself is compressed). A large .laz is stopped as before, and converting to COPC is suggested.

Both compressed (.laz, the LASzip scheme) and uncompressed (.las) are supported, but v1 currently supports point data formats 0/1/2/3/6/7/8 (extra bytes and waveform data are not supported).

If you want measuring and findings, or want something lighter for distribution, converting to COPC as described below turns on LOD streaming.

Converting .las to COPC (when LOD streaming is needed at scale)

Converting a large file to a single .copc.laz with PDAL turns on octree-based staged loading.

pdal translate input.las output.copc.laz --writer copc

Measured (Kasado Bridge dataset):

Item	Value
Input	~3.24 GB / 95,169,313 points (Point Format 3 = XYZ + Intensity + GPS + RGB)
Output	496 MB (Point Format 7)
Time	~3 minutes (PDAL 2.10.2)

Four ways to open data

Drag and drop. Drop a .copc.laz / .las / .laz onto the screen. No server is involved, so there's no need to worry about Range either (raw LAS/LAZ is handled entirely in the browser, with no upload to a server). Dropping multiple files at once, or holding Shift while dropping, layers them into one scene.

File picker. The 📁 Data tool rail → "Open file".

URL. Enter a URL into the same panel's field and press "Load", or use "+ Add" to layer it onto the existing scene (.copc.laz / .las / .laz all work).

Server requirement

Loading from a URL requires the hosting server to support HTTP Range. If it's on a different origin, its CORS setup must include content-range and accept-ranges in Access-Control-Expose-Headers. Without this, the confusing failure is that the request succeeds but the content can't be read.

A URL parameter. ?data=<URL> loads it at startup. The #s=... hash also carries the camera and display settings, so you can share "this data from this viewpoint" (that's what the data panel's "Copy share link" produces). → URL parameters

Layering multiple sources

Point clouds loaded via "add" line up as layers, individually toggleable and removable (📁 Data → "Layers"). From commands: addData / setSourceVisible / removeSource, and queryLayers to list them.

Files with a different coordinate system can't be layered. When the detected CRS conflicts, adding it is refused and the reason is shown. Layering silently would make two point clouds tens of meters apart look like "that's just the shape".

How coordinates are handled

A plane-rectangular-coordinate-system point cloud has coordinate values on the order of tens of thousands of meters, and loading those onto the GPU as raw float32 makes points jitter. oniyanma subtracts the COPC header's cube center as a fixed offset and normalizes near the origin before rendering.

Because of that, there are two coordinate systems:

• Real coordinates — the source data's coordinates (m). Measurement values, the camera API, and finding pins are all in this system
• Aligned (scene) frame — coordinates normalized for rendering. selectBox ranges and alignedBounds are in this system

The transform is scene = Rz(-alignYaw) · (real - offset), and offset and alignYaw are available from getState().frame and queryCrs. Details: reference overview.

CRS is recorded only — never reprojected. The EPSG code and vertical datum (orthometric / ellipsoidal height) can be checked with queryCrs, so you can later say what basis "this 12.4 m" is measured against.

Reference surfaces (TIN design surfaces)

Overlaying a design surface (TIN) on the point cloud lets you color-code deviation with deviation analysis. 📁 Data → "Reference surfaces" → "Load", or the command addSurface. The point cloud must already be loaded.

Format	Extension	Coverage
J-LandXML	.xml	The TIN definition in <Surfaces><Surface>
DXF	.dxf	3DFACE entities only (the typical form Civil3D / 12d etc. export a TIN as)
Shapefile	.shp	Only TriangleStrip / TriangleFan within MultiPatch (shape type 31)
IFC	.ifc	Geometry resolved via web-ifc before loading

All of these normalize to the same TIN (triangle mesh), so deviation analysis and overlay work the same regardless of format. DXF POLYLINE polyface meshes and SHP PolygonZ / PolylineZ (extruded shapes like walls) are not supported. IFC has no guarantee of being in a surveying coordinate system, so check visually that it isn't offset (like the other formats, it's assumed to share the point cloud's real coordinates).

Whether LandXML's coordinate order is "northing, easting" or "easting, northing" varies by project, so it's switched with an axis order toggle. Getting it backwards puts the design surface 90 degrees off from where it should be — if things don't line up, suspect this first (DXF / SHP / IFC have no concept of axis order; they use the file's XYZ as-is).

Default dataset attribution

The Kasado Bridge point cloud opened in the demo is converted to COPC format from the 「令和3年度県道笠戸島公園線（笠戸大橋）「AIのデータ解析による損傷予測構築」に伴う設計業務委託」 point cloud 3D model (commissioned by 山口県土木建築部, contracted by 大日本コンサルタント株式会社, distributed by My City Construction). It's licensed CC BY 4.0, which requires attribution, a link to the license, and disclosure of any modification. The app shows the same notice at the bottom of the data panel. If you replace the dataset, update that notice too.