Concepts

These conventions hold across dataset types. They are the parts that do not change from one delivery format to the next — everything specific to a particular dataset type lives on that dataset type's own page.

Coordinates#

Unless a dataset type's page says otherwise, the coordinates you deliver are used as-is. Nothing is reprojected, and nothing is inferred from a .prj sidecar or a CRS record inside a LAS header. A few dataset types compare an embedded CRS in the file (GeoTIFF GeoKeys, ECW GDT names) to the dataset's 2D CRS and fail the run on a mismatch — those pages say so.

A dataset carries two coordinate reference systems:

For Dutch datasets these are typically EPSG:7415 (Amersfoort / RD New + NAP height) and EPSG:28992 (Amersfoort / RD New).

For most dataset types, delivering in the wrong CRS does not error. The data indexes cleanly and then appears in the wrong place on the map, which is a much more expensive mistake to find than a failed run. Check the dataset's CRS before you export.

A few dataset types do transform coordinates — typically where the source format carries its own CRS, or where positions come from a GNSS network in a known frame. Where that applies, the dataset type's page says so and states which source systems it accepts.

Rotation angles#

Pose files are normally heading/pitch/roll (often labelled pan/tilt/roll). Deliver the angles your capture system produces, in the order your dataset type's page documents — do not pre-convert to another convention.

Angles are always degrees, never radians.

Heights#

height_above_ground is an ingest parameter, configured once on the dataset, not a column in your pose file. It describes the height of the camera above the road or ground surface and is used for viewer positioning.

The Z in your pose file is the absolute height in the dataset's CRS — for EPSG:7415, metres relative to NAP — not a height above ground.

Depth#

When a delivery has both panoramas and a point cloud, each photo's tilepack also gets depth from that point cloud, so a viewer can measure in the photo. There is nothing extra to upload for it. A photo gets depth when:

• the point cloud is in the same coordinate system and vertical datum as the photo positions — the dataset's (see Coordinates);

• the point cloud has points within 42 m of where the photo was taken;

• if the point cloud carries Adjusted Standard GPS time, some of those points were captured within a minute of the photo. Deliver photo capture times on the same clock as the scanner's: a photo whose time is off by an hour or a time zone gets no depth. A point cloud without GPS time, or with GPS week seconds, is matched by distance alone — then a car parked during another pass can show up in a photo's depth.

  A dataset type whose scan need not be taken with its photos matches by distance alone whatever the GPS time says; its page says so.

A photo without depth still gets its tilepack. A point cloud that gives no depth at all is not a delivery error; the photos simply have none.

Filenames#

Every dataset type resolves the names in your metadata file against a real listing of the bucket. Matching is case-sensitive and exact.

Which extensions a dataset type accepts, and whether it appends one for you, is part of that dataset type's contract and is documented on its page. Do not assume .jpg and .jpeg are interchangeable — for some dataset types they are not, and this is a common cause of a delivery indexing far fewer files than expected.

Strictness#

Dataset types differ in how much missing or unexpected data they tolerate. Some abort on the first missing file; some allow a proportion of them; some warn and carry on. Some treat files you did not mention in your metadata as an error, others ignore them.

The difference matters when you are deciding whether a partial delivery is worth uploading, so each dataset type's page states its own rules explicitly. Check there before assuming a near-complete delivery will go through.

Sets#

Indexed files are grouped into sets, which is how a viewer separates one capture run from another.

What a set corresponds to is decided by the dataset type — a session folder, a camera direction, a flight, or an ingest parameter you set on the dataset. Each dataset type's page says which.

Re-running#

Indexing is repeatable. Re-running processing replaces the dataset's previous records with a fresh set rather than appending to them, so fixing a bad metadata file and re-running is the normal repair path. You do not need to have the dataset recreated.

Some dataset types additionally write a marker once a unit of work is finished, so a re-run skips what already succeeded. Where that applies, the dataset type's page explains how to force a reprocess.