As-designed models and as-built LiDAR in one coordinate frame

The problem

A construction programme needs the as-designed model and the as-built survey in the same frame, without letting a point cloud overwrite the commercial record.

Several discipline models per project; one heavy file must not stall the platform.

Models and LiDAR overlay only when they share the project coordinate system and site origin.

Authoring files are large; the coordination view has to stay usable in the browser.

Survey results remain advisory; official progress is recorded separately.

System architecture

flowchart LR
  subgraph library ["Library"]
    library_0["IFC authoring files"]
    library_1["LAS survey uploads"]
  end
  subgraph process ["Processing"]
    process_0[["Conversion job queue"]]
    process_1["View-model conversion worker"]
    process_2["LiDAR georef worker"]
  end
  subgraph coordinate ["Coordination"]
    coordinate_0["Federated browser viewer"]
    coordinate_1["Advisory progress review"]
    coordinate_2[("Official progress store")]
  end
  library_0 --> process_0
  process_0 --> process_1
  library_1 --> process_2
  process_1 --> coordinate_0
  process_2 --> coordinate_0
  process_2 --> coordinate_1
  coordinate_0 --> coordinate_1

Interaction schematic

Schematic of the interaction described above. Generic interface, no real data, no measured figures. Not a product screenshot.

Key architecture decisions

Conversion stays off the request path

IFC is stored as the authoring file and converted asynchronously into a view model the browser can load.

Parsing an authoring file in the request path, or in the browser, makes coordination unusable as models grow.

Rejected On-demand IFC parse in the API — rejected after timeout and memory incidents.

Trade-off A worker, a queue, and a version that is not viewable until conversion finishes.

The survey does not become the record

LiDAR comparison reports seen, not seen, or insufficient coverage. It does not write official progress, and the cloud is not warped onto the model.

A flight that missed a span is not evidence the span is unbuilt. Forced alignment hides a survey or model error.

Rejected Auto-update WBS from scan coverage alone — rejected for commercial and engineering sign-off reasons.

Trade-off Engineering confirmation remains a manual step before programme status can change.

What I own, wrote, and delegate

Own

Multi-tenant platform boundaries and job queues for IFC and LiDAR processing
Result contract: observed, inferred, or not observable; WBS linkage

Wrote

NestJS APIs, tenancy, and worker orchestration on RabbitMQ
Separation of advisory survey output from official progress writes

Delegate

Georeferencing algorithms and point-cloud classification internals
Front-end viewer interaction details after viewer contract was set

Scale

Multi-tenant construction platform with asynchronous conversion off the request path
IFC stored as authoring files; browser loads converted view models

Boundaries

Georeferencing and point-cloud classification algorithms were not mine; I owned queue, tenant, storage, and the result contract.
IFC converts to a view format the browser can load. Authoring stays in the original tool.

What we watch in operation

Time from upload to a viewable modelCRS mismatch between a model and its projectElements with insufficient scan coverage

Rules the design never breaks

A conversion in progress does not block other projects.
A scan result cannot write official progress.
Federated and single-model viewing use the same model placement, in the project frame.

Broader application

Programmes federating many discipline models in one coordinate frame.
Sites where an as-built survey must sit on the design without becoming the commercial record.
Multi-party projects where membership governs access to the model.