Field Geo

Aerial deliveries from Field Geo: two oblique directions and nadir, each a folder of TIFF frames with one exterior-orientation text file, plus a GeoPackage carrying every frame's footprint, capture time and camera; and alongside them the orthophoto tiles and the LiDAR tiles of the same flight.

Each half of the delivery is indexed on its own. Frames go in per direction (three sets: F, B, N), orthos under set O, point clouds under the set_name parameter. A delivery may leave any half out — but not all of them.

Folder layout#

<dataset bucket>/
├── Metadata/
│   ├── ImageFootprints/
│   │   └── <name>.gpkg                 ALL .gpkg files are read and merged
│   ├── CameraCalibration/              welcome, not read
│   └── …                               reports, SummitEV project: not read
├── FW/
│   ├── <name>_Projectiecentra_<name>.txt
│   └── tif/<frame>.tif
├── BW/
│   ├── <name>_Projectiecentra_<name>.txt
│   └── tif/<frame>.tif
├── NAD/
│   ├── <name>_Projectiecentra_<name>.txt
│   ├── RGB_tif/<frame>.tif             three-band nadir frames — note RGB_tif, not tif
│   └── RGBI_tif/<frame>.tif            four-band twins, preferred — see Infrared
├── Ortho/
│   └── RGBI_tif/<tile>.tif             note: RGBI_tif, not directly in Ortho/
├── Pointcloud/
│   └── <tile>.laz
└── Reports/                            welcome, not read

The backward base folder is looked for under these names, in this order — the first base folder containing any object wins, and candidates below it are then dead:

1. BW/

Once a base folder is chosen, an empty images folder inside it fails the run — it does not fall through to the next candidate.

The forward base folder is looked for under these names, in this order — the first base folder containing any object wins, and candidates below it are then dead:

1. FW/

Once a base folder is chosen, an empty images folder inside it fails the run — it does not fall through to the next candidate.

The nadir base folder is looked for under these names, in this order — the first base folder containing any object wins, and candidates below it are then dead:

1. NAD/

Once a base folder is chosen, an empty images folder inside it fails the run — it does not fall through to the next candidate.

The nadir_rgbi folder is looked for under these names, in this order — the first containing at least one matching file wins:

1. NAD/

The ortho folder is looked for under these names, in this order — the first containing at least one matching file wins:

1. Ortho/

The pointcloud folder is looked for under these names, in this order — the first containing at least one matching file wins:

1. Pointcloud/
2. pointcloud/
3. ingest/Pointcloud/

Each half is optional on its own, but a delivery must contain at least one of them: a bucket with no forward or backward or nadir or ortho or pointcloud content is rejected rather than processed into nothing.

Two folder names catch people out: nadir frames go in NAD/RGB_tif/, and orthos go in Ortho/RGBI_tif/; only the two oblique directions use a plain tif/. A NAD/ folder without RGB_tif/ fails validation rather than being skipped.

GeoPackage layers#

Every .gpkg directly inside Metadata/ImageFootprints/ is read and the results merged, so a delivery may split its footprints across files. Each direction needs its layer in at least one of them:

Note FWD and BWD, not FW and BW. The *_beeldmidden centre-point layers and NIR_footprints are not read (see Infrared for why the latter is not what places the four-band twins).

Required attributes on each footprint layer:

• Every .gpkg under Metadata/ImageFootprints/ must open as a GeoPackage and list its feature layers. A file that is not one, or a truncated upload, fails the delivery naming the file.
• Each delivered direction needs its footprint layer in at least one GeoPackage: FWD_footprints for FW/, BWD_footprints for BW/, NAD_footprints for NAD/. The available layer names are listed when one is missing — FW_footprints instead of FWD_footprints is the classic.
• The footprint layers must declare the dataset's coordinate reference system. Nothing is reprojected: a layer in another system would place every footprint elsewhere without anything failing.
• A photo name appearing in the same layer of more than one GeoPackage (a delivery split across files with overlap). The first row is used; the report says which names were seen twice. (a warning, not an error)
• Every footprint row's Cameranaam must name a camera body whose calibrated intrinsics are on the platform (by the serial inside the name, e.g. MM010109). A new body is added from its calibration certificate before the delivery can be processed.

The orientation file#

<direction>/<name>_Projectiecentra_<name>.txt — the _Projectiecentra_ part is what identifies it; exactly one per direction folder.

The file is a preamble (datum, projection, units, a header line) followed by one row per frame, whitespace-separated:

The preamble's length does not matter: a row is recognised by its shape (a name and six numbers), so the data may start on any line. Once the rows have started, a line that is not a row is an error rather than a dropped frame.

Photos#

Every delivered frame must be in both the orientation file and the footprint layer. Frames the metadata does not cover are reported one by one at validation, and processing tolerates a sliver of them (1 %) before it fails. Metadata rows whose frame was not delivered are counted, not failed on: a delivery clipped to an area of interest looks exactly like that.

• Each delivered direction folder must contain exactly one *_Projectiecentra_*.txt orientation file. None means nothing places the photos; several means we cannot tell which is final.
• The orientation file must read as a preamble followed by rows of <name> X Y Z Omega Phi Kappa. A damaged row after the data has started is reported, not skipped.
• Every delivered frame must have a row in its direction's orientation file and a row in its footprint layer, under its filename without extension. Processing tolerates a sliver of stragglers; the report names each one.
• Every frame's TIFF header must parse (one small ranged read per file; the pixels are not downloaded) and its pixel dimensions must be those of the camera body its footprint row names. This is what ties the calibrated intrinsics to the delivered files, and it catches a truncated or non-TIFF upload on the way.

Cameras#

Interior orientation is not in the delivery. It comes from the calibration certificate of each Phase One body, held on the platform and selected per frame by the serial inside Cameranaam:

A delivery shot with another body fails validation naming the serial; send its calibration certificate and it is added. Every frame's TIFF header is checked against its body's frame size, which is also how a truncated upload is caught.

Infrared#

Field Geo delivers each nadir frame twice: the three-band frame in NAD/RGB_tif/ and a four-band twin of the same name in NAD/RGBI_tif/ — the same picture (re-encoded, so not pixel-identical) with the near-infrared body's image registered onto it as a fourth plane. Each frame is indexed once: from its twin when one is delivered (tagged rgb, nir in its bands), otherwise from the three-band file (tagged rgb). Either way it takes the frame's orientation, footprint and camera. (NIR_footprints describes the separate infrared body's own footprint, a couple of metres off, and is therefore not used.)

The three-band folder is optional when the twins are delivered, and the twins are optional when it is; a frame present in both folders is indexed from the twin. A twin is checked exactly like a frame: it needs its orientation row and footprint, and its pixel size must match the body.

Every nadir and oblique record gets a tilepack for the viewer; a twin's tilepack carries the colour pyramid and a near-infrared group beside it, on the same grid, so the viewer can switch between them. Tenants still on the Omnibase viewer also get a deep-zoom SZI of each record's colour planes.

Orthophotos#

GeoTIFF tiles directly inside Ortho/RGBI_tif/, indexed exactly as Ortho (generic) indexes Ortho/: boundaries from the raster headers, nothing reprojected. The .tfw sidecars are not read — the tiles carry their georeferencing in GeoTIFF keys.

Georeferencing#

• Each GeoTIFF's TIFF header and first IFD must parse (only the header is read; the pixel data is not downloaded). A corrupt or truncated TIFF fails the run, naming the file. ECW files are checked separately.
• Each GeoTIFF must carry a ModelPixelScale/Tiepoint (or ModelTransformation). A file with none is not indexed: a pixel-space rectangle stamped with the dataset CRS would place the tile at the CRS origin and poison the dataset footprint. The .tfw sidecars are not read.
• Each ECW file's header must parse (magic, version, dimensions, georeference). A truncated or corrupt header fails the run, naming the file.
• Each raster's CRS (GeoTIFF GeoKeys, or the ECW header) must equal the dataset's 2D CRS. Nothing is reprojected. A mismatch, or a file with no recognised CRS, fails the run.

ECW#

ECW tiles are accepted in the same folder and checked by their own header.

Point cloud#

LAZ/LAS tiles in Pointcloud/ (or pointcloud/, ingest/Pointcloud/), indexed and merged into one COPC as for Point cloud (generic). Field Geo delivers tiles cut to a 100 m grid, so they are not re-tiled. A delivery without them is photos-only.

• The LAS public header of each point cloud file must parse (it is read from the first 64 KiB). A corrupt or truncated header fails the run, naming the file.
• Point-data record formats 0 and 2 carry no GPS time, so the merged point cloud gets no temporal index and cannot be filtered by capture time. (a warning, not an error)
• The point records must actually be there: a header can parse while the data behind it is truncated (a half-finished upload or copy). Checked for uncompressed LAS, where the declared point count and record length give an exact expected size; LAZ stores points in variable-size chunks, so the same arithmetic does not apply.

Coordinate reference system#

Nothing is reprojected. Footprints and ortho boundaries must be in the dataset's 2D CRS, projection centres in its 3D CRS. See Coordinates. The footprint layers' declared CRS is checked against the dataset's; the orientation file's preamble is not read.

Omega, phi and kappa are stored as delivered, each negated — the convention every Field Geo dataset on the platform was indexed with.

Timestamps#

Capture time is Opnamedatum plus Opnametijdstip from the footprint layer, read as UTC.

Ingest parameters#

What you get back#

• Indexed frames per direction with footprints, orientations and camera intrinsics; nadir frames from their four-band twin where delivered.
• A tilepack per frame (colour pyramid, plus an infrared group where the frame has one), and a deep-zoom SZI per frame for tenants on Omnibase.
• Indexed orthophoto tiles.
• Indexed point cloud tiles plus one merged COPC.

Common failures#