SenP oblique

Oblique aerial deliveries in the numbered Dutch folder structure. Photo footprints come from a shapefile, camera orientations from a separate plain-text file, and the two are joined on the photo name.

Photos are indexed per camera direction — each Richting becomes its own set.

Folder layout#

<dataset bucket>/
├── 05_Luchtfotografie/
│   ├── 03_Footprints/
│   │   └── 20260325_footprints.shp     + .dbf, .shx, and ideally .prj
│   └── 07_Oblieke_Luchtfotografie/
│       ├── 5040001.tif
│       └── 5050001.tif
├── 08_Direct_Referencing_Orientaties/
│   └── 20260325_eo.txt                 exactly one .txt, any name
└── 08_Laserdata/
    └── 05_LAZ_Tiles/
        ├── tile_001.laz
        └── tile_002.laz

All folder names are exact, including the numeric prefixes. The two metadata files are found by glob — *.shp and *.txt respectively — so their names are free.

A missing shapefile or a missing orientation file fails the run. A missing or empty 08_Laserdata/05_LAZ_Tiles/ skips the point cloud half without failing.

The footprint shapefile#

A standard ESRI shapefile — deliver the .shp with its .dbf and .shx alongside, and the .prj if you have one.

Datum and Tijd are concatenated and parsed together, so any unambiguous combination works.

Rows whose Richting is Nadir are skipped — this template indexes obliques only.

CRS handling#

This is the one place in this template where coordinates are transformed.

• If the shapefile carries a .prj, its declared CRS is honoured and the footprints are reprojected into the dataset's CRS.
• If it does not, the coordinates are assumed to be WGS 84 lon/lat (EPSG:4326) and reprojected from there.

That fallback matters: 2025-and-later deliveries have been shipping without a .prj while carrying lon/lat, which is why it exists. A .prj-less delivery in any other CRS will be silently misplaced. Ship the .prj.

Camera positions are a separate matter — see below.

The orientation file#

One .txt in 08_Direct_Referencing_Orientaties/.

The join is by filename: the shapefile's Foto plus .tif must appear at position 0 here. A footprint with no matching orientation row is skipped with a note; there is no percentage limit.

Example#

5040001.tif  182518.396  477934.743  312.884   0.4213  -0.1180   87.2214
5050001.tif  182519.204  477936.881  312.901  -0.0812   0.3355  177.9008

Camera geometry#

Not delivered and not configured. The camera is identified by the first three characters of the photo filename, and each head has its own calibration built in:

Focal length and principal-point offsets follow from that prefix; pixel size and frame dimensions are the same for all four heads. A filename whose prefix is none of these has no calibration to apply and will not index correctly, so keep the supplier's naming.

Coordinate reference system#

Two different rules apply in the same delivery, and it is worth being explicit:

So the orientation file must already be in the dataset's configured CRS even though the shapefile need not be. See Coordinates are not reprojected.

Ingest parameters#

Photos always take their Richting as the set name; set_name does not affect them.

What you get back#

• Indexed oblique photos, one set per camera direction, each with its footprint, camera position and calibration.
• Indexed point clouds from 08_Laserdata/05_LAZ_Tiles/.
• A single merged COPC at copc/pointcloud.copc.laz.

Uppercase .LAZ / .LAS files are accepted and renamed to lowercase in place during indexing.

Common failures#