Concepts
These conventions hold across ingest templates. They are the parts that do not change from one delivery format to the next — everything specific to a particular template lives on that template's own page.
Coordinates#
Unless a template'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 templates 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:
| Used for | |
|---|---|
| 3D SRID | camera and scanner positions — the X, Y, Z in your pose file |
| 2D SRID | footprints and boundaries — point-cloud extents, image footprints |
For Dutch datasets these are typically EPSG:7415 (Amersfoort / RD New + NAP height) and EPSG:28992 (Amersfoort / RD New).
For most templates, 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 templates 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 template'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 template'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.
Filenames#
Every template resolves the names in your metadata file against a real listing of the bucket. Matching is case-sensitive and exact.
Which extensions a template accepts, and whether it appends one for you, is part
of that template's contract and is documented on its page. Do not assume .jpg
and .jpeg are interchangeable — for some templates they are not, and this is a
common cause of a delivery indexing far fewer files than expected.
Strictness#
Templates 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 template'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 template — a session folder, a camera direction, a flight, or an ingest parameter you set on the dataset. Each template's page says which.
Re-running#
Indexing is repeatable. Re-running a template 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 templates additionally write a marker once a unit of work is finished, so a re-run skips what already succeeded. Where that applies, the template's page explains how to force a reprocess.