Vansteelandt oblique

Oblique aerial photos from Vansteelandt's Leica CityMapper flights: the JPEGs of the four oblique camera heads (forward, backward, left and right) directly in an oblique folder, and one shapefile in footprints whose table holds each photo's position and orientation.

That table is the only metadata read; nothing is read from the pixels beyond the frame header.

Photos are indexed per camera head: Forward, Backward, Left and Right each become their own set.

Folder layout#

<dataset bucket>/
├── oblique/
│   ├── 047_47_122021_81832-150240.jpg
│   ├── 039_39_122007_81816-150224.jpg
│   └── 061_61_140824_81816-150224_.jpg
└── footprints/
    ├── Footprints.shp
    ├── Footprints.shx
    ├── Footprints.dbf
    ├── Footprints.prj
    └── Footprints.cpg              welcome, not read

Both folder names are exact and case-sensitive. The photos sit directly in oblique/ (subfolders are not read), and footprints/ holds exactly one shapefile; other files beside it are ignored.

Photos#

Deliver the photos as exported — do not rotate, crop or resize them. The orientation in the shapefile describes the pixels as they are: for the backward head the near ground is at the top of the photo, and the left and right heads have the horizon side on a short edge. A rotated or resized photo no longer matches its orientation and is placed wrongly in the viewer.

• Every photo is named <n>_<n>_<HHMMSS>_<serial>.jpg: two numbers, the exposure time in UTC and the camera serial (e.g. 047_47_122021_81832-150240.jpg). A _ before the extension is allowed.
• Every delivered photo must start with a JPEG marker and end with an end-of-image marker. This catches a file that is not a JPEG whatever its extension says, and the truncated upload — which a size check cannot see, since nothing knows how big the file should have been.
• The camera serial in every photo's name must be a camera head whose interior orientation we have on file, and that head's view direction must be the photo's VIEW_TYPE. A new camera is added on our side; tell us before delivering with it.
• Every photo's JPEG frame header (read from the start of the file; the pixels are not downloaded) must give its camera's dimensions — 10336 × 7788 pixels for the heads on file. A resized or cropped photo no longer matches its interior orientation.

Cameras#

The delivery carries no camera calibration, so the interior orientation of each head is kept on our side, by serial:

The principal point is the centre of the photo. A photo from a camera not in this table fails validation; tell us before delivering with a new head, ideally with its calibration report.

Footprint shapefile#

One polygon per photo — the photo's footprint on the ground — and in its table the photo's exterior orientation:

Other columns are ignored. Every photo needs a row and every row needs its photo. The polygons are stored as the photos' footprints.

• Exactly one shapefile (.shp, .shx, .dbf, .prj, one name), whose table has the columns naam, x, y, z, omega, phi, kappa, VIEW_TYPE and Flight_Dat, with one polygon row per photo (naam = the photo's file name) and every number filled in.
• Every row in the shapefile has its photo. A row without a photo means the upload is incomplete.
• The shapefile's .prj must be a coordinate reference system that can be transformed into the dataset's, and every polygon must survive the transformation. The polygons may be in another CRS than the table's coordinates (WGS 84 is fine); they are reprojected.
• Every projection centre (x, y, z) must lie within 10 km of its own footprint and between 100 and 5000 m height: the table's coordinates are in the dataset's coordinate reference system.
• Flight_Dat is the capture date as YYYYMMDD, and not in the future. With the photo name's HHMMSS it gives the capture time, in UTC.
• Footprints computed from each row's orientation and the camera are compared with the delivered polygons. Widespread disagreement means the orientations or the camera do not describe the delivered photos, and they would be placed wrongly in the viewer — worth a look before accepting. (a warning, not an error)

Orientations#

omega, phi and kappa are the photogrammetric rotation of the camera, applied in that order (ω about x, then φ about y, then κ about z), with the camera's x axis to the right of the photo, y to its top, and the camera looking along −z. They are used exactly as written; there are no per-head offsets.

As a cross-check, a footprint is computed from each row's orientation and its camera and compared with the delivered polygon. Widespread disagreement is a warning: the orientation or the camera does not describe the photo.

Coordinate reference system#

The table's x, y and z must be in the dataset's coordinate reference system (for Belgium, Lambert 72 with Ostend heights); they are stored as delivered. The polygons may be in another CRS — the .prj says which, and WGS 84 is fine — and are reprojected into the dataset's.

Timestamps#

A photo's capture time is Flight_Dat plus the HHMMSS in its name, read as UTC. The capture dates become the dataset's acquisition dates.

What you get back#

• One indexed oblique photo per delivered JPEG, with its projection centre, orientation, camera, footprint and capture time, in the set of its head.
• A tilepack per photo, and a deep-zoom SZI per photo for tenants on Omnibase.

Common failures#