NavVis

Raw NavVis recordings, each folder exactly as the scanner wrote it, with the surveyed ground control points of the project. Put the recordings under ingest/sessions and the GCP files under ingest/gcp; every recording must have observed at least three of the GCPs.

Folder layout#

<dataset bucket>/
└── ingest/
    ├── sessions/
    │   ├── 2026-06-23_13.52.11/      one NavVis recording per folder
    │   │   ├── dataset_manifest.json
    │   │   ├── dataset.json
    │   │   ├── sensor_frame.xml
    │   │   ├── anchors/
    │   │   ├── cam/
    │   │   ├── info/
    │   │   ├── internal/
    │   │   └── …
    │   └── 2026-06-23_14.20.05/
    └── gcp/
        └── targets.txt               one or more GCP files

Deliver every recording of the project under ingest/sessions/, each in a folder of its own, and the GCP files under ingest/gcp/. Nothing else is read.

Recordings#

Upload each recording folder whole and unchanged, as the scanner wrote it, named as the scanner named it. Do not process, register or split it first, and do not put a recording inside another folder in sessions/.

A recording lists its own files in dataset_manifest.json. That list is how a delivery is checked for completeness: every file in it must be there, at its size. An upload that stopped halfway shows up as a file that is missing or too small; upload the recording again.

The anchors set while recording (anchors/anchors.txt) are how a recording is tied to the GCPs: name each anchor exactly as its target is named in the GCP file.

Ground control points#

Deliver the surveyed GCPs as text (.txt) or CSV (.csv), one point per line:

name  X  Y  Z  [code]
TA7   200129.3140  360956.6857  24.7377  201
TA13  200014.2955  360894.9406  25.4342  201

• Columns are separated by spaces, tabs, commas or semicolons; decimals use a point.
• X, Y and Z are in the dataset's CRS, X (easting) first. Nothing is reprojected; see Coordinates are not reprojected.
• A header line before the first point is allowed, and # starts a comment.
• Several files are fine, but a name is one point: the same name with two positions is refused.
• Only this project's GCPs. A survey file covering several sites must be cut down to this one before delivery. Reused names across sites are exactly how a point from the wrong site ends up in a project.
• Every recording must observe at least three GCPs with its anchors.

Ingest parameters#

1.95 m is the height of a NavVis VLX's panoramas carried by a walking operator; set height_above_ground for any other camera height.

Checks#

Every delivery is checked before anything is processed:

• The delivery holds at least one recording folder under ingest/sessions/, no loose files directly in ingest/sessions/, and at least one .txt or .csv GCP file under ingest/gcp/.
• Each recording is whole: it has its dataset_manifest.json, every file the manifest lists is there at the size the manifest gives, and it has sensor_frame.xml and anchors/anchors.txt. No recording is delivered twice.
• Files in a recording folder that its manifest does not list are named, and are not processed: what an upload tool leaves behind (.part files), notes, copies. (a warning, not an error)
• Every GCP file reads: after an optional header, each line is name X Y Z, optionally followed by a code, with a decimal point. A name is one point across all files. Each GCP lies within the area of use of the dataset's CRS.
• Each recording's anchors name at least three GCPs from the GCP files, and those GCPs lie where the recording placed its anchors, to within 250 m: the positions the scanner records while walking are rough, so this catches a GCP of another site under the same name, not a poor pick.
• The GCP files hold this project's points only: no GCP lies more than 500 m beyond the GCPs the recordings observed.
• GCPs within the project's area that no recording observed are listed. They do no harm. (a warning, not an error)

What you get back#

• One georeferenced point cloud, tied to the GCPs, cleaned of moving objects, smoothed and coloured from the panoramas: as LAZ files under pointcloud/, one per recording (<recording>.laz), in the dataset's CRS. Points no panorama sees are black.
• A single merged COPC at copc/pointcloud.copc.laz.
• The panoramas, stitched from the recordings' camera frames: level, with north at the centre, under panorama/jpg/, placed by panorama/pano_georizon.csv. In a project of several recordings each name starts with its recording's number (s1_00040-pano.jpg). They are blurred when anonymisation is auto_anonymise, and carry depth from the point cloud for measuring in the viewer. Where the recordings walk more than one level of a building (one floor over another), each panorama carries its level, 0 the lowest, for the viewer's floor menu; panoramas on stairs and ramps carry none.
• Each recording's trajectory, trajectories/<recording>.tum: one line per pose, 100 per second, time X Y Z qx qy qz qw, with the time in Unix seconds and the position in the dataset's CRS.
• A QC report, Reports/processing/navvis_qc_report.pdf: the point cloud from above with the walked route, the fit to the GCPs per recording and how well the recordings agree where they overlap. Stretches where the ground surface looked doubtful are listed in Reports/processing/ground_check_auto_accepted.txt; check those during checkup.

Common failures#