Press Release
MultiSet AI has released v2.3.3. Until now, a device had to be told which map it was standing in. v2.3.3 lets it ask with a coordinate. Send a latitude and longitude, and the platform finds the map that covers that spot and returns a pose against it. The release also reads a laser scan's survey grid at upload, merges scans that never overlap into one MapSet, answers clients built on the open OSCP GeoPose protocol, exports every map as USDZ for NVIDIA Isaac Sim and Omniverse, and turns any map into a link anyone can open.
v2.3.3 shipped on 19 September 2026.
Every localization call has carried a mapCode. That puts a lookup problem on the application. A navigation app covering forty buildings ships a directory of forty codes and a way to pick one. A robot arriving at a new site needs someone to tell it which map it is on.
v2.3.3 removes the lookup. Pass geoLocation with a WGS-84 latitude and longitude in place of mapCode, and Map Query resolves the nearest map whose footprint is in range, 25 m by default and adjustable with geoSearchRadius. If that map belongs to a MapSet, the whole set is queried. The response names the map it used in resolvedFrom, with the distance, so the application always knows what it localized against.
The footprint is new too. Every georeferenced map now carries a geo-fence, a GeoJSON polygon that follows the shape of the scan rather than a circle around it. Nobody draws it. It is generated once a map is active and has coordinates and a heading, and it refreshes when either changes. A point inside the fence is 0 m away.
For sessions that localize continuously, GET /v1/vps/map/nearby does the lookup once. It ranks the candidate maps around a coordinate and groups them by what you would actually query, so three floors in one MapSet come back as one entry. Where fences overlap, every candidate is listed and nothing is picked silently. Resolve once, cache the code, and query at frame rate.
What this opens up: one build that works across a customer's whole portfolio, outdoor-to-indoor handoff without a site picker, and drones and robots that arrive by GPS and localize without a human in the loop.
Industrial sites are surveyed in their own coordinate systems. A national grid, a state plane in US survey feet, a private plant grid tied to control monuments. The laser scans that come out of those surveys carry that grid. Some files say so in their metadata, many do not.
v2.3.3 lets you declare it. An E57 upload now accepts source.metadata.crs in one of two forms:
The map georeferences itself from that declaration, with its origin and heading set on upload. The declaration wins over anything the file claims, which closes the case of a scan whose own coordinate metadata is empty. The result is also checked against the location you pinned, and a suspicious gap is flagged on the map. Common grids are in the Developer Portal. Helmert transforms go through the API.
Heights get the same care. Survey heights are usually orthometric, measured from the geoid. GPS and MultiSet georeferencing use ellipsoidal heights. The gap between them is not small: 46 m in Bavaria, -90 m in Bengaluru. Declare verticalEpsg for orthometric heights and the conversion is done for you. Two related fixes ship alongside. The satellite viewer now places scans at ellipsoidal height, and the iOS SDK now sends ellipsoidal altitude with geoHint.
The upshot for a plant owner: the scan you already paid for arrives in the frame your asset register already uses. No hand-computed offsets, no second alignment pass.
A MapSet has always been built by matching imagery between maps. That works when scans overlap. Large sites do not always cooperate. A conveyor corridor and a tank farm a kilometre apart share no imagery at all, yet they sit in the same survey frame.
v2.3.3 uses that frame. POST /v1/vps/map-set/from-georeference builds a MapSet from georeferenced E57 maps that share a source frame, the same EPSG code or the same Helmert transform. Placement comes from the survey, so it is exact rather than estimated, and no overlap is needed.
Sites grow, and the set grows with them. Add maps later with PUT /v1/vps/map-set/{mapSetId}/from-georeference. Maps already in the set never move, and a batch is all or nothing, so a bad file cannot leave the set half-updated. A separate origin endpoint corrects the set's anchor and heading if the survey is revised.
Open AR Cloud's OSCP GeoPose protocol defines a vendor-neutral way for a client to send an image and a location and get a global pose back. v2.3.3 implements it at POST /v1/vps/map/geopose, versions 1.0 and 2.0.
A client already written for the protocol can localize against MultiSet maps without a line of MultiSet-specific code. It sends its location reading, the geo-fence picks the map, and the answer carries the same localization quality and the same metering as Map Query. Teams that want to pin a map can still pass mapCode or mapSetCode.
For platforms that support several positioning providers behind one interface, MultiSet is now one of them. Your platform, your customer, our infrastructure.
Robots are trained in simulation before they touch a real floor. The simulation is only as useful as the scene is faithful to the site.
Every map now exports a textured USDZ mesh, ready for NVIDIA Isaac Sim and Omniverse. In the Developer Portal, open any map or MapSet and select Download on the USDZ Mesh row. It sits alongside the formats already there: the textured and raw GLB meshes, the map.pcd point cloud, and the high-fidelity and compressed Gaussian Splats.
That closes a loop for Physical AI teams. One capture now gives the VPS map the robot localizes against, the splat people walk through, the point cloud the survey team uses, and the simulation scene the robot trains in. Plan a route on the digital twin of the actual facility, then deploy against the map built from the same capture.
A capture has lived inside the account that made it. Showing it to a plant manager, a client or an executive meant a screen share or a login they did not have.
v2.3.3 adds share links. Select Share on any map or MapSet in the Developer Portal and you get a public URL that opens in a browser, with no MultiSet account and nothing to install. The mesh is always included. Add the Gaussian Splat and the 360° tour where the map has them. The recipient sees the scan and nothing else: no dashboard, no other maps, no credentials.
You decide how long it lives. Links expire after 7 days by default, or on a date you choose, or never. A one-time link stops working after it is opened once. Each active link shows how often it has been opened and when, and Revoke ends it at once for everyone, including anyone who has it open. The link itself is the credential, so treat it like one. Share links are available on every plan.
Here is what a recipient sees, a brewery floor mapped with MultiSet, first as the 3D mesh and then as the 360° tour.
v2.3.3 restructures the iOS Swift Native SDK. The AR layer, built on ARKit, RealityKit, SwiftUI and CoreLocation, now ships as source in MultiSetAR/ alongside the xcframework. Teams can read it, step through it and adapt it to their own app instead of working around a closed view. References to MultiSetSDK.MultiSetARView are removed.
MultiSet and MultiSetCallback are now marked @MainActor. The compiler now enforces what UI code already needed: calls and callbacks on the main thread.
Pose consistency checking, the filter that compares each localization result against the device's own AR trajectory and discards the ones that contradict it, now defaults to off. Turn it on with poseConsistencyCheck and set the tolerance with poseConsistencyThreshold.
The SDK also sends ellipsoidal altitude with geoHint, so height hints on iOS match the datum the maps are georeferenced in. Setup needs iOS 16 or later and an ARKit device. The sample app, configuration and callbacks are in the iOS docs.
v2.3.3 is live on MultiSet's public cloud and rolling out to private-cloud, self-hosted and on-device customers on each environment's normal cadence.
The new endpoints and fields are additive. Map Query still takes mapCode exactly as before, and existing MapSets are unchanged. Coordinate lookup, CRS declaration, georeference merging and OSCP are there when you call them. Geo-fences are generated for every map that is active and has coordinates and a heading, and geoFenceReady on any map confirms it has one. USDZ and share links are in the Developer Portal today. iOS apps upgrading the SDK should check for MultiSetARView references and main-thread calls, per the iOS section above.
For how session, map and global coordinates relate, see Session Space, Map Space, Global Space. Full details in the v2.3.3 changelog.
Yes. Since v2.3.3, Map Query accepts geoLocation, a WGS-84 latitude and longitude, in place of mapCode. The platform finds the nearest active georeferenced map whose geo-fence is in range, 25 m by default, and returns a pose against it along with the map it used.
Any projected grid with an EPSG code, such as ETRS89 / UTM, British National Grid, Swiss LV95 or a US state plane, with an optional vertical EPSG code for orthometric heights. Private site grids are declared as a 7-parameter Helmert transform to WGS-84. The map is georeferenced from the declaration on upload.
Yes, when both are georeferenced E57 maps in the same survey frame. The from-georeference MapSet endpoint places each map from the frame itself, so no overlap or image matching is needed. More maps can be added later without moving the ones already in the set.
Yes. POST /v1/vps/map/geopose implements Open AR Cloud's OSCP GeoPose protocol, versions 1.0 and 2.0, with the same localization quality and metering as Map Query.
Yes. Every map and MapSet exports a textured USDZ mesh from the Developer Portal, compatible with NVIDIA Isaac Sim and Omniverse.
