Documentation

How this works, and what to expect

Bedrock turns a drone LiDAR flight into drafter-ready deliverables and publishes them where the whole team can see them. This page is the honest version: what each stage does, what the output is good for, and where it is not to be trusted.

Job lifecycle

1

Requested

A job is created on New job with its number, site, coordinate system and — importantly — the deliverables it owes. Declaring that at the start is what lets every later screen say "three still outstanding" instead of quietly showing whatever happens to exist. The raw capture is linked in Drive, not uploaded: a flight is tens of gigabytes.

2

Processing

The rig pulls the capture and works through the pipeline below, reporting each stage back as it goes. Long stages show a progress bar on the job card and on Results. A stage that cannot honestly report a percentage shows an indeterminate bar rather than a number nobody measured.

3

Partial

Artifacts publish as they finish, so the surface and contours are usable while the photogrammetric ortho is still running — that one takes hours. A job sits at partial until everything asked for exists.

4

Complete

Every requested deliverable is published. The job keeps its viewer, its accuracy report and its raw dataset permanently — it becomes the archive entry, not a folder somebody has to find again.

The pipeline

Everything is derived from the colorized point cloud unless it says otherwise. That is the deliberate choice: coverage then depends on where the sensor flew, not on whether enough photos overlapped.

Stage	What it does	Produces
Ingest	Reads the LAZ, resolves the coordinate system from the file header, and reprojects a working copy.	normalised cloud, job bounds
Rasters	Projects the cloud straight down into image space — colour, intensity and surface elevation.	RGB ortho, intensity, DSM
Ground	PDAL SMRF classification separates bare earth from vegetation and structures.	classified ground LAZ
Surface	Grids the ground returns, then triangulates. Contours are smoothed and clipped to real data.	DTM, hillshade, TIN, contours
Photo ortho	Optional, and separate: OpenDroneMap stitches the drone photos. Hours on a GPU box, and it needs good photo coverage — the LiDAR rasters do not.	photogrammetric ortho
Package	Assembles the CAD set — DXF linework, LandXML surface, PNEZD points — with a `.prj` and insertion notes.	Carlson / IntelliCAD zip
Publish	Uploads artifacts and the web layers the viewer streams, then bumps the job's data version so no browser can hold a stale layer.	everything on Results & Dataset

Deliverables

Chosen per job at intake. The catalogue below is live — it is the same list the New job form offers and the same one Results measures against.

Accuracy, and where not to trust it

The bare-earth surface is machine-classified. Where a job has field shots, every one is compared against the lowest classified ground return beneath it and published as a per-job accuracy report — every control point listed individually, plus summaries by surface type.
Hard surfaces are the strong case; canopy is the weak one. On job 2915 control agreed to 0.18 ft RMSE while all shots together came to 0.66 ft. That spread is the story: crews put topo where the ground is rough and vegetated, which is exactly where a two-return sensor gets fewest chances at bare earth. Trust the surface on pavement; verify it under cover.
The LiDAR rasters are a DSM-based projection, not a true ortho. Tall vertical faces can lean and dense canopy hides what is under it. Fine for hard-surface planimetrics; check anything beneath trees against the cloud.
Anything on a *-LIDAR layer was traced by machine. Those layers are separate on purpose. Correct them and promote onto the standard layers, so it stays obvious what a human has checked.
This is a QC check, not a certification. The comparison is against the job's own field shots — survey observations, not independent published control.

Coordinate systems

Deliverables come out in the job's own State Plane zone in US survey feet, so they drop onto existing linework with no reprojection and no scaling. The zone is recorded per job and shown on Results and Dataset.

Fill the coordinate system in at intake when you know it. Neighbouring zones overlap numerically — a Georgia West easting and northing also validate inside the Alabama West envelope, and projecting one with the other's parameters lands the site in the wrong state rather than somewhere obviously broken. It has happened: a crew file went in 135 miles west of the site, latitude intact, every point inside a plausible boundary. The job's own map pin is what settles it, and a declared CRS removes the doubt entirely.

Field-to-finish

When a crew point file exists for the job, its F2F linework renders in the viewer on top of everything else — strings, polygons and every shot, coloured by category. It is drawn by the same engine the job map uses, reading the same field code dictionary and the same category palette. Nothing about the colours or the linework rules is reinvented here; change a code in Base Station and it changes here too.

Shots from neighbouring jobs are filtered out by default — the flight area is the job — and can be shown with the adjacent jobs toggle.

API

Endpoint	Purpose
`GET /api/jobs`	Every job, merged from the catalogue and storage.
`POST /api/jobs`	Onboard a job. Requires the access key.
`GET /api/jobs/:id`	One job with its deliverable ledger and artifact listing.
`PATCH /api/jobs/:id`	Edit the record or the requested deliverables.
`POST /api/jobs/:id/progress`	The rig reports a stage: state, percent, message.
`GET /api/artifacts/:job`	List a job's published files.
`GET /api/artifacts/:job/:name`	Stream one file. Supports Range and ETag.

Background: the original June 2026 scope brief is kept for history. It describes the research case for the system rather than the system as built.