Skip to main content

One Grid for Outdoors and Indoors

· 3 min read
Sean Gorman
Sean Gorman
Co-founder @ Zephr

Sean Gorman is a co-founder of Zephr, a positioning and navigation AI company. In a talk pre-recorded and played at the H3 Conference 2026 in New York City, he showed how Zephr uses one H3 index, at two resolutions, to organize both GNSS corrections and indoor visual map tiles for a single positioning engine.

One solver instead of a handoff​

Satellite positioning stops at the door. Indoors, GNSS signals are blocked or bounced, so the blue dot drifts, jumps or freezes. The usual fix is a separate indoor positioning system with a handoff at the entrance, which is often where the position jumps.

A phone's positioning solver normally sits in the chip's firmware as a black box. Zephr's engine, Zephyrus, takes the raw measurements off the chip and solves for position in C++ on the device. That makes room for survey-grade corrections and better ionospheric, clock and ephemeris models, and it lets other sensors feed the same PVT filter: camera motion from visual inertial odometry and visual fixes from a visual positioning system. As GNSS starts to fail, the solver leans on the other signals without switching systems.

Two services feed it. Zellige builds indoor map tiles (visual positioning feature databases) from photogrammetry, lidar and other surveys. Zap is the positioning server that pushes GNSS corrections and visual fixes to the phone.

Two resolutions of the same index​

H3 serves both halves of the system:

  • Resolution 5 (about 10 km edge) for GNSS corrections. A correction is good for about 10 km before its accuracy starts to degrade.
  • Resolution 13 (about 4 m edge) for visual map tiles. Feature databases need to sit close to the camera.

Because both come from one index, 5,764,801 resolution 13 cells nest under each resolution 5 cell.

Four patterns from one grid​

The cell as channel. Outdoors, the phone's position maps to a resolution 5 cell, correction streams are keyed by cell, and corrections are built only for cells in use. Sean showed a real SSR correction for Denver with its cell ID.

The cell as file. Indoors, a building survey is cut into map tiles, one per H3 cell, and the cell ID is the file name. Zap turns a phone's rough location into a cell ID, opens that file and matches the camera's features against it. There is no spatial database, only a file system.

The cell as frame. Each tile stores its 3D points in meters East, North and Up from the cell center, as 32-bit floats. At Earth-centered scale a 32-bit float can only move in steps of about half a meter, while inside a cell it resolves hundredths of a millimeter. Zap solves in the local frame and replies in Earth-centered coordinates.

Boundaries solved at build time. Zellige builds the tile for each survey image in its home cell, then uses gridDisk to check the neighbors one ring at a time. If the camera was within the overlap distance of a neighbor's boundary, the image is written into that tile too. Some data is stored twice, so Zap reads exactly one tile per request and never stitches tiles.

From the mall to the curb​

In the first demo, a phone moves cell to cell through a mall, changes levels on an escalator and heads out the door, where the solver rolls over to GNSS as the camera runs out of key descriptors to match.

The second was Denver International Airport, where getting off the train usually means no GNSS at all, so the track starts in visual positioning. It guides the user past the baggage carousels using landmarks such as baggage carousel 16 and the large luggage racks, out under a large concrete deck that wrecks GPS signal, and across a crosswalk to the Uber pickup point, map matching to a predetermined path along the way. Plain GPS on the same walk caught a little signal in the atrium, died under the second floor, and came back at the very end, wrong at first and then too late.

Learn more​

Jump to section


← Back to blog