LiDAR and spatial capture for property measurement

"LiDAR" gets used loosely, so it helps to separate the methods it's often lumped in with. Device LiDAR — the kind in an iPhone or iPad Pro — is a direct time-of-flight sensor: it emits pulses of light and measures how long they take to bounce back, producing depth data directly rather than inferring it. Time-of-flight (ToF) is the general technique; "LiDAR" is Apple's branding for its own ToF implementation, though the terms are often used interchangeably for phone-class hardware.

Photogrammetry takes a different route: it reconstructs geometry from multiple ordinary photos of the same space, taken from different angles, using overlap between images to triangulate depth. It needs no special sensor, but it needs good, varied coverage and enough visual texture to find matching points between photos — a blank wall or a dark room can defeat it. Google's ARCore Depth API, the Android-side equivalent most phones rely on, is mostly this kind of software depth estimation from camera motion, merging in a hardware ToF reading only on the handful of Android devices that carry one.

Terrestrial laser scanning (TLS) is the professional-grade end of the same idea as phone LiDAR — a tripod-mounted scanner sending out laser pulses and building a dense point cloud — but at meaningfully tighter tolerances, over longer range, and at a cost and setup time phone capture doesn't carry. Every method here trades some combination of accuracy, cost, and convenience; none of them is a universal answer.

A raw LiDAR sensor produces a depth map or a point cloud — a set of 3D points with no inherent structure. What makes Apple's RoomPlan interesting is that it doesn't stop there: it runs a classifier over the incoming geometry and outputs a parametric CapturedRoom model — walls, doors, windows, openings, and recognized furniture as distinct, labeled objects, each carrying its own confidence score, exportable as a USDZ file. That's a structured result a downstream system can reason about element by element, rather than an undifferentiated cloud of points someone still has to interpret.

Apple's own published detection figures for RoomPlan report roughly 95% precision and recall for walls and windows, about 90% for doors, and 90–91% for furniture (at a 30% 3D intersection-over-union threshold), with a separate scan-guidance classifier reported around 90% accurate. Those are Apple's own reported figures for its own system, not an independent audit, and are worth reading with that caveat attached.

Accuracy figures for phone LiDAR vary enormously by distance, motion, and lighting, and citing one number without its conditions is misleading. A 2023 study measuring an iPad Pro's LiDAR under close, static conditions (roughly 1–1.5 meters, no movement) found sub-millimeter plane-fit accuracy, degrading to roughly a centimeter once the device was moving during capture, which is closer to how an actual room scan happens. A 2024 study comparing an iPad Pro's LiDAR against a Trimble terrestrial laser scanner found that static acquisition — multiple overlapping stationary scans — produced linear measurements off by roughly 1–2cm and small-area measurements off by around a square meter; dynamic acquisition, scanning while moving the device through the space, produced RMS error more than five times worse, which is consistent with the same pattern: motion during capture is what costs the accuracy.

At the other end of the range, a 2025 study of iPhone 14 Pro LiDAR used outdoors found it stayed reliable out to about 20 meters and usable to roughly 60 meters, with error around 0.20 meters at that outdoor range — an order of magnitude coarser than the indoor, close-range numbers above. The pattern across all of this research is consistent: phone LiDAR is genuinely useful, but its accuracy is a function of distance and motion, not a fixed spec, and it should never be quoted as a single number without saying which condition produced it. None of these figures make phone LiDAR a substitute for a terrestrial laser scanner; TLS remains the meaningfully tighter tool where that level of precision is actually required.

The same research and Apple's own documentation point to consistent failure modes: low light (RoomPlan specifies a minimum of roughly 50 lux), reflective or transparent surfaces like mirrors and glass, very dark materials that absorb rather than reflect the sensor's pulses, motion during the scan, and simply being too far from the surface being measured. Phone LiDAR is also range-limited by design — Apple rated the original iPad Pro sensor to about 5 meters, and RoomPlan is built around single rooms roughly up to 30 by 30 feet, not open, large-format spaces.

It's worth being precise about what measurement standards do and don't say, since they're frequently over-cited. ANSI Z765 sets a calculation method for a single-family home's finished square footage, but it explicitly does not prescribe how an individual room's dimensions should be measured, and it excludes multifamily housing from its scope — it's a calculation convention, not a measurement-technique standard. BOMA, meanwhile, isn't one standard: it publishes six separate ANSI floor-area standards (Z65.1 through Z65.6) for different building and space types, so a claim invoking "the BOMA standard" should specify which one. ANSI/IICRC S500 is a restoration-industry standard covering water-damage inspection and mitigation procedures — not a general measurement standard, but relevant wherever a capture supports a water-damage inspection.

Separately from those formal standards, deducting door and window openings from gross wall area — rather than pricing a wall as if it were a solid rectangle — is a widely used convention in property-estimating capture tools, which typically let a user mark wall openings specifically so they can be subtracted from the wall's square footage rather than counted as solid surface.

Spatial capture data circulates in a handful of established formats: LAS and its compressed variant LAZ (an ASPRS/OGC point-cloud standard), PLY (a general-purpose point-cloud and mesh format), E57 (an ASTM standard, E2807, built specifically for 3D imaging data interchange), and glTF (a Khronos/ISO standard for transmitting 3D models efficiently). Apple's own USDZ format is what RoomPlan exports on-device. None of these formats is universal; a capture pipeline typically has to pick one as its primary retained format and convert for specific downstream uses.

What makes a capture defensible later is less about the format and more about what metadata travels with it. The digital-evidence field has its own answer to this question — the SWGDE's published best practices for digital evidence collection call for recording the device, a timestamp, the tool version, hashes of the captured data, and the operator responsible for the capture. Applied by analogy to spatial capture (SWGDE's guidance isn't written for room scans specifically), the same discipline holds: a scan worth relying on later should carry its device, its scale reference, when it was taken, and by whom — not just the resulting numbers with no record of how they were produced.

A few questions cut through most vendor claims: What hardware does it actually require, and how many of your team's devices already have it? What's the output — a raw point cloud, a mesh, or a labeled parametric model like RoomPlan's — and does your workflow need that structure? What accuracy is claimed, and under what conditions (distance, lighting, motion) was that number produced? Does the tool retain the raw capture and its scale reference, or only a derived final number with no way to check it later? And does anything in the pipeline flag low-confidence elements for a human to review, or does everything get treated as equally certain?

PaxExact's own LiDAR and spatial capture module follows this checklist in part today, in beta: an uploaded RoomPlan JSON export or text-layer USDZ scan is retained as evidence, dimensions derived from it cite that exact file, and none of them count until a professional accepts them. A native PaxExact capture app, which would record device and capture metadata itself, is planned, not built.