VPS
One photo of the Austin skyline, taken out of a window. Run against a 3D scan of the city. The system handed back the balcony the photo was taken from.
When that clip went around, most of the reaction was about privacy, which is fair enough. Any skyline photo from your window is giving away your address.
The infrastructure read is the one that matters more. Nobody scanned that balcony. Nobody sent a capture crew. Nobody scheduled a survey window or bought a rig. The 3D data already existed, built for something else entirely, and it turned out to be a positioning map nobody had switched on.
That is the argument of this post. If your organization holds photorealistic 3D tiles, Gaussian splats, textured meshes, point clouds, or a georeferenced digital twin, you are very likely holding a visual positioning system that has never been turned on. Not raw material for one. The map itself.
A visual positioning system uses a device camera to work out its precise position and orientation by comparing what the camera sees against a digital map of a place. Six degrees of freedom means position in x, y and z plus orientation in roll, pitch and yaw. Not "somewhere in building 4." Where you are standing, and which way you are facing.
Spatial Insiders, covering the Austin test, called it GPS for cameras. That is the right handle for most people.
Numbers, because vague accuracy claims are worthless. Sub-5 cm median 6-DoF. Under 1 cm drift at 10 m. Roughly two seconds for a cold-start cloud query. Tens of milliseconds on device: 38 ms on Apple Silicon, 52 ms on a Snapdragon 8 Gen 3.
No markers on the wall. No BLE hardware in the ceiling. No QR sticker farm slowly peeling off a bulkhead.
GPS runs out exactly where the work happens. In an urban canyon, satellite signals bounce off glass and steel before they reach the receiver. Researchers at Hong Kong Polytechnic measured a low-cost receiver in that environment at a mean error of 31.02 m with a standard deviation of 37.69 m, and a worst case of 177.59 m. That is not positioning. That is a rough guess about which block you are on. Indoors it stops working altogether, which is where most industrial assets live.
The second failure is quieter and more expensive. A team decides it needs camera-based positioning, and the default assumption is that positioning requires a fresh proprietary capture. So they schedule a re-survey of a facility they already scanned. Survey-grade capture rigs have historically run $50,000 and up, before you count the crew, the access permits, the downtime and the weeks of turnaround.
Both failures get solved with the same wrong answer: capture it again, properly this time.
Except you already captured it properly. The city has a photogrammetry program. The plant has a digital twin. The campus has a drone reconstruction from the last capital project. Somebody has already spent the money.
MultiSet is map-agnostic. Any 3D representation of a place can become a map a device localizes against. Four families cover almost everything real teams hold.
Google's Photorealistic 3D Tiles cover more than 2,500 cities across 49 countries, delivered in the OGC 3D Tiles format and streamed through Cesium ion and, as of mid-2026, through ArcGIS Online and ArcGIS Pro. Municipal programs are the same shape of asset. Japan's Project PLATEAU has published 3D city models for roughly 250 cities as open data. If you own tiles, or hold a license that permits building a derived positioning map, this is a starting point, not a picture.
Radiance fields reproduce a place with photographic realism, and the 2023 SIGGRAPH work on 3D Gaussian splatting made them render in real time at 30 fps and above. MultiSet shipped the first 3DGS-to-VPS pipeline. One requirement worth stating plainly: the splat has to be metric-scaled, one unit to one meter. A splat you can look at but cannot localize against is a dead asset.
GLB, PLY and OBJ meshes out of photogrammetry, reality capture, CAD and BIM workflows. Esri I3S integrated mesh. Drone photogrammetry from the last site survey. If it carries texture and real-world scale, it qualifies.
E57 from Matterport, Leica, NavVis, FARO and XGRIDS. Raw LiDAR. Drone point clouds, which typically land at 1 to 3 cm horizontal accuracy with RTK ground control. This is the most common starting point for industrial sites, because most of them already have one sitting on a server.
Already georeferenced? Better. When your data carries a real-world coordinate reference, the positioning map arrives aligned on day one and sits alongside the GIS layers you already run.
Here is the part most teams get wrong when they reason about this from first principles. They assume the hard problem is matching an RGB camera frame against a LiDAR point cloud, or against a splat, at query time. Cross-modal matching in real time is genuinely hard, and if that were the architecture, accuracy would swing wildly depending on what captured the map.
That is not the architecture.
We do not match LiDAR to RGB or splat to RGB at query time. We close the modality gap at map-build time.
Whatever the source, it is converted offline into one common tile-based VPS representation that stores derived visual and geometric features rather than raw sensor data. Matching at runtime is same-domain by construction. The practical consequence is the whole reuse thesis: accuracy tracks the quality and coverage of the reconstruction, not the logo on the device that produced it.
It also means sources mix. A city tile set outdoors, a terrestrial scan of the lobby, a phone capture of the mechanical room three floors up. Different devices, different file types, different years, stitched into one coordinate frame and queried as one map. For anyone reusing what they already hold, that matters more than support for any single format, because real organizations never have one clean dataset. They have seven partial ones collected by different teams for different reasons.
Step 1. Send the data you have. Upload tiles, splats, meshes or scans in a common format, with the coverage area and where it sits on Earth. Every upload is authenticated and bound to your account. No proprietary capture app. No required hardware.
Step 2. The map gets built and georeferenced. Your data becomes a positioning-ready map. The Georeference API ties it to WGS84 using three or more control points, each pairing a map-local position with latitude, longitude and altitude. The solver returns origin and heading along with horizontal RMSE, per-point residuals, automatic outlier rejection at a 2.5 m default threshold, and a gravity tilt check so a subtly rolled map gets caught before it ships. MapSet stitches separate maps into one coordinate frame, and GravityAligned merge handles same-plane joins.
Step 3. Localize from an ordinary camera frame. Your application sends a frame and receives a 6-DoF pose. The default engine returns in roughly two seconds. Deep Search widens the map region searched for up to 15% higher recall at three to four seconds, selectable per query, which matters in large repetitive spaces where every aisle looks like every other aisle. GeoHint narrows the search using a GPS prior when one is available. SDKs cover Unity, iOS, Android, WebXR, Meta Quest, Meta Ray-Ban and ROS 2.
Real-world accuracy. Sub-5 cm median 6-DoF, under 1 cm drift at 10 m, in a coordinate reference you can hand to another system without a translation layer.
Content that stays put. Anchors, navigation paths and AR work instructions authored once stay locked to the world. When the space changes, Map Versioning and partial map updates refresh only the section that moved. You re-scan the space. You do not re-author the content.
GIS and twin alignment. Once georeferenced, every pose lands in the same coordinate reference that facility drawings, asset registries and field mapping systems already use. This is the bridge, and it is the reason the reuse path is usually better than a fresh capture: your existing data is already in your existing coordinate system.
City-scale AR. Persistent overlays, tourism and information layers anchored to real streets, built on the tiles a city already published.
Wayfinding and navigation. Turn-by-turn guidance in dense downtowns, multi-floor campuses and interiors where GNSS has nothing to offer.
Digital twins. The twin shows you the asset. Localization is what lets a person or a machine stand in front of the real one. Twin platforms make reality visible. Visual positioning makes it operational.
Field inspection and asset management. A Fortune 100 industrial customer running MultiSet in private cloud production reports 2.5x technician productivity on asset finding and a 4x reduction in mean time to repair on critical incidents. Those gains come from removing the search, not from the headset.
Robotics and drones. Absolute pose against a shared map, which is what corrects the drift that on-board odometry accumulates over a long run.
Location-based experiences. Play and events that treat a real place as the board, without installing anything in it.
Spatial Insiders covered the test and described it plainly: a skyline photo matched against a 3D scan of Austin, resolving to the exact balcony the camera had been standing on. They also drew the boundary correctly, which most coverage of this does not. Maps are private to each customer account. There is no shared public world index quietly absorbing everyone's scans. The version that traveled furthest came from Bilawal Sidhu, who advises us.
The part worth holding onto is not the accuracy number. It is the provenance. That Austin scan was not built to be a positioning map. Nothing about the capture was designed for localization. It worked anyway. That is what you should expect once the modality gap is closed at map-build time rather than at query time, and it is the clearest demonstration of this post's argument I can point you at.
No system is magic, and the honest limits are worth more to you than another paragraph of benefits.
Cameras need light and they need permission. In a genuinely dark space, or one where cameras are not allowed, this is the wrong tool and passive RF tagging is the right one.
Coverage is bounded by your source data. If the reconstruction stops at the fence line, so does positioning. A city tile set that captures rooftops beautifully and alleys poorly will localize accordingly.
And scale matters more than format. A splat or mesh with no metric scale is not usable until it has one. That is a five-minute fix, but it is a fix, not a nothing.
Reuse also inherits age. A map built from a three-year-old reconstruction of a floor that has since been reconfigured will localize you confidently into a room that no longer exists in that shape. Partial map updates make the correction cheap. Somebody still has to notice it is needed.
MultiSet builds a scan-agnostic visual positioning system: centimeter-accurate 6-DoF localization for phones, headsets, smart glasses, robots and drones on a shared coordinate system. Deploy it in public cloud, a dedicated instance, your own VPC, on premise, or fully air-gapped. Your maps stay private to your account. There is no shared public world map and no requirement to contribute to one.
Two outside checks, for whatever they are worth to you. AWE named MultiSet the 2026 Auggie Award winner for Best Developer Tool. And AREA's 2025 enterprise VPS study, which tested six global vendors, gave MultiSet perfect scores in environmental resilience, map-to-map navigation and developer support, and described it in their words as "the most robust solution" of the six.
Across the platform: 16M+ sq ft mapped, 3,400+ locations, 116+ countries, 500K+ device interactions.
Worth saying plainly, because spatial pilots get scoped as quarter-long programs by default. There is nothing to capture here, so there is nothing to schedule. Three days is a realistic end to end.
Day 1. Pull one dataset you already own covering a space you care about. Confirm it is metric-scaled, note its coordinate reference, confirm your licensing permits building a derived positioning map from it. Upload it.
Day 2. Pick three or more control points with known real-world coordinates and georeference the map. Then localize against it from a phone, standing in the actual space. This is the step that settles the argument internally, because it either works in your building or it does not, and you will know inside an hour.
Day 3. Wire it into one workflow with a real outcome attached. Asset finding is usually the fastest to measure, because the baseline is already sitting in your work order history.
If it runs longer than that, the delay is almost always data access or procurement. It is not the technology.
If your data exports as 3D tiles, a textured mesh, a point cloud, an E57 or a metric-scaled splat, it comes straight in. The cases that do need new capture are coverage gaps and reconstructions too coarse to match against, not format mismatches.
On-device SLAM tracks relative motion very well and drifts, because nothing is correcting it against the world. Markers are excellent control points and terrible infrastructure, because somebody has to install and maintain every one of them. VPS returns absolute pose against a shared map, so drift gets corrected rather than accumulated. In production the useful framing is not either-or: tracking propagates, VPS corrects.
You do. Your maps are private to your account, and you choose where they live, including inside your own network with no outbound connection. Separately, confirm your own rights to any third-party geospatial data before building a positioning map from it.
The interesting thing about the Austin test was never that a photo can find a balcony. It was that nobody had to go to the balcony first.
Most organizations that need positioning have already paid for the map. It is sitting in a bucket, rendered in a viewer, described in a capital project closeout document, doing one job when it could be doing two.
Reconstruction is a feature. Localization is infrastructure. If you already have the first, you are much closer to the second than you think.
Start free on the developer portal, or book a 30-minute call and bring a sample of the 3D data you already own. We will tell you honestly whether it will localize, and what it would take if it will not.
Related reading: scan-agnostic 3D mapping, 3DGS to VPS, choosing a scanner for VPS mapping, and the developer docs.
