Blog · 2026-09-03
How to Evaluate an Indoor Mapping Platform with iPhone LiDAR
The iPhone LiDAR capture layer is the part of an indoor mapping platform that turns a physical interior into measured map data before route graphs, positioning, and wayfinding use it. Evaluating that layer means checking how the system scans, corrects, labels, updates, and exports geometry - not judging the final map by appearance alone.
This matters when comparing Mappedin, MapsPeople's MapsIndoors, or a custom capture pipeline. A Mappedin vs MapsPeople evaluation is not a product ranking because the capture paths start with different source material. Ask whether each method fits the available plans, site access, accuracy needs, update schedule, and target file.
What does the capture layer determine in an indoor mapping platform?
The capture layer sets the coordinate frame, geometry, labels, and history that every later feature inherits. If a doorway is misplaced, a wall is duplicated after drift, or a floor lacks sound alignment, routing and positioning cannot repair the source map. A polished renderer can only show the data it receives.
To evaluate it, follow one venue from source to published map. Find who supplies the geometry, how it is checked, when doors and restricted areas become routeable, and which file the team treats as final. Repeat that path for a changed room. These flows show day-to-day fit better than a finished map screenshot.
Deep dive: the indoor mapping industry map shows where phone capture already feeds construction, real-estate, insurance, facilities, and warehouse workflows.
Mappedin vs MapsPeople: scan-based vs CAD-based indoor mapping?
Mappedin's Scan app builds a floor plan from a fresh iPhone or iPad Pro LiDAR scan, while MapsPeople's MapsIndoors starts from floor plans a customer already maintains, including CAD files, and adds a route network for indoor wayfinding. The difference is the capture starting point, not a product ranking.
Mappedin describes this as a scan-to-floor-plan workflow. Its Scan page says users can group scans by building, upload them for desktop editing, and export SVG, PNG, USDZ, or GeoJSON. Mappedin also documents IMDF export from the wider mapping workflow.
MapsPeople lists CAD, PDF, or image files as static map sources and says indoor wayfinding needs a route network for each map. The MapsIndoors product page documents its CMS and native SDKs.
Its developer docs say an interactive map can use Google Maps or Mapbox. Mapbox's showcase says MapsPeople creates an Indoor Route Network after floor plans are in place and adds the Mapbox Directions API.
| Approach | Starting input | Tooling | Outputs or handoff | Update workflow | When it fits |
|---|---|---|---|---|---|
| Scan-based | Physical access to the current space | Mappedin Scan and its workspace | SVG, PNG, USDZ, GeoJSON, with IMDF available in the broader mapping workflow | Group or extend scans, then edit and publish the updated map | Drawings are missing or stale and the venue can be scanned |
| CAD-based | Floor plans, including CAD, PDF, or image files | MapsIndoors CMS and SDKs, with Google Maps or Mapbox | Indoor map and route network | CMS edits or latest floor-plan upload | Maintained floor plans are already the operational baseline |
| Custom capture | Camera, LiDAR depth, ARKit scene data, or RoomPlan output | A purpose-built capture app, validation layer, and export pipeline | IMDF, GeoJSON, USDZ, or another schema | Selective re-scan, versioned merge, review, and controlled publication | Capture controls, offline operation, privacy, or file meaning require product-level control |
Custom does not mean rebuilding every sensor feature. Apple's RoomPlan documentation describes structured room capture, while ARKit gives developers depth and scene reconstruction when they need more control. Deep dive: the RoomPlan production envelope explains where the framework ends and the app's own pipeline begins.
What capture accuracy does iPhone LiDAR need for indoor wayfinding?
For indoor wayfinding, set capture accuracy around the choice a user needs to make. A map can be close in distance yet fail if a doorway is cut off from the route graph. Live blue-dot error belongs to the positioning system, not the scan. Test map geometry and live positioning separately.
| Scenario | Measured accuracy | Source |
|---|---|---|
| Objects larger than 10 cm | ±1 cm absolute | Luetzenburg, Kroon & Bjørk, Nature Scientific Reports, 2021 |
| Surfaces at 0.3-3 m | 1-2 cm | Converging across studies and practitioner benchmarks |
| Building-scale capture | 10-20 cm at 95% confidence | iPhone 13 Pro comparison studies |
| Maximum sensor range | ~5 m | Apple ARKit documentation |
A peer-reviewed study measured absolute accuracy of ±1 cm on objects larger than 10 cm (Luetzenburg, Kroon & Bjørk, 2021).
Across studies and practitioner benchmarks, surfaces at 0.3-3 m converge on roughly 1-2 cm accuracy.
iPhone 13 Pro comparison studies report 10-20 cm building-scale accuracy at 95% confidence.
Apple's ARKit documentation gives the LiDAR Scanner a maximum range of about 5 m.
These numbers cover different scales. Room-scale results can support dimensioned geometry on cooperative surfaces. They do not promise that a whole-building model stays within the same tolerance as errors add up. Glass, mirrors, polished metal, dark surfaces, repeated corridors, and weak visual texture also belong in the test set.
Define acceptance from the navigation decision. A route may only need the correct level, corridor, doorway, and accessible connection. A maintenance workflow may need an asset tied to a tighter region. Write both requirements before procurement, then test the map and live location engine separately. Deep dive: the iPhone LiDAR accuracy evidence covers room, building, and material conditions.
How should a platform handle drift on long multi-room scans?
Treat long indoor scans as registration systems, not stretched room scans. The phone estimates motion frame by frame, so small pose errors build through corridors and loops. A sound workflow splits the scan, keeps overlap at transitions, detects weak tracking, closes loops, and shows remaining error before the map is accepted.
On the same hardware, an independent benchmark measured a 5 cm mean deviation and 10 cm RMSE for Polycam versus 44 cm and 56 cm for Scaniverse, a roughly 9x spread in mean deviation.
Have the operator scan a route that returns to its starting area. Compare the end geometry with fixed references, inspect room joins, and record error by segment instead of hiding it in one average. Also test interruption and relocalization. The operator should know whether capture resumed in the same coordinate frame or created a duplicate.
Operator guidance belongs here. The app can request slower movement, stronger viewing angles, overlap at doorways, or a local re-scan while the operator is still present. Confidence that appears only after upload is less useful because the site visit may already be over.
Our team ships a production LiDAR scanning app for a surveying technology company. Its capture pipeline uses RTK/NTRIP corrections, per-frame accuracy gating, and a Metal rendering pipeline handling up to 15 million points. Outdoors, an RTK correction stream anchors scans to sub-5 cm georeferenced accuracy.
The outdoor result is not an indoor accuracy claim. It taught us to reject weak frames early and check accumulated error against fixed references before accepting a capture. Deep dive: our indoor mapping account explains what changes when the GNSS anchor disappears indoors.
Which indoor map formats should the capture layer support?
Format checks should focus on preserved meaning, not the size of an export menu. IMDF and GeoJSON can carry map features. USDZ can carry scene geometry for Apple workflows. CAD files can remain the maintained drawing in a CAD-led process. SVG and PNG are useful images, but they do not by themselves prove routeable paths.
Apple describes IMDF as the format used to display indoor maps; its model includes levels, units, openings, amenities, and other indoor features. An IMDF check is more than a file-extension check. Validate IDs, coordinates, level links, openings, categories, and restrictions after export and after re-import into the target system.
Run a round-trip test with real venue data. Check units and coordinate reference, verify that doors stay attached to the right walls, and confirm that the target system can tell a room polygon from a walkable route. A correct-looking PDF or image proves presentation, not data exchange.
How should re-scan and map updates work when spaces change?
An update should replace only the changed area, keep stable IDs where it can, check affected routes, and pass an explicit review. Do not judge the workflow by its first successful import. Measure the time and proof needed to move a real physical change into every app that uses the map.
Mappedin says users can manage and group scans by building. MapsIndoors says its CMS lets users add, edit, and maintain the map. The same page says Map Update Automation starts when the user uploads the latest floor plan. For either model, ask what happens to location identifiers, external links, route restrictions, and unpublished edits when geometry changes.
A custom pipeline needs the same answers. Store scan history, isolate the changed area, compare versions, flag conflicting room or route data, and keep a rollback copy. Re-scanning an entire venue for one moved partition adds field work and registration risk.
Should indoor capture run on-device or in the cloud?
On-device processing lets crews capture offline, see quality at once, and keep closer control of raw room data. Cloud processing helps with shared editing, heavy reconstruction, central versions, and publishing across devices. Many workflows need both. The boundary should be clear and testable, not implied by an upload button.
List what leaves the phone: camera frames, depth maps, point clouds, meshes, or only checked geometry. Then record retention, encryption, access, deletion, and failure rules. A building scan can expose entrances, restricted rooms, equipment, and occupancy clues, so privacy review belongs in the capture design from the start.
Offline testing should cover more than the scan button. Check that the operator can see tracking quality, save safely, resume after interruption, and queue a result without a connection. When the network returns, syncing must preserve versions and must not silently replace a reviewed map.
What should an indoor mapping platform evaluation checklist include?
- Source of truth: Is the venue measured from the current site, digitized from maintained drawings, or assembled through both paths?
- Accuracy budget: Are room geometry, building registration, route topology, and live positioning tested as separate requirements?
- Drift controls: Can the workflow detect weak tracking, preserve room transitions, close loops, and report residual error?
- Interoperability: Has the exact IMDF, GeoJSON, USDZ, or CAD handoff passed a round-trip test in the consuming system?
- Change management: Can one changed area be re-scanned or re-imported without breaking stable identifiers and unaffected routes?
- Processing boundary: Is it clear what runs on the device, what is uploaded, what still works offline, and who can access retained data?
- Acceptance evidence: Does approval depend on measured control points and semantic checks rather than visual inspection alone?
The capture choice follows from those answers. Scan-based capture fits when the current site is the best record. CAD-based digitization fits when controlled drawings guide facility work. Custom capture fits when scanning, validation, privacy, or export behavior belongs to the product. A vendor-neutral evaluation tests every option against the same source-to-map contract.