Your field application's map should lead straight to the work: the asset, its readings and the evidence behind an alert. 8DB's local spatial reader supplies one part of that design. It selects relevant geometry from a retained region, creating a foundation for field software that connects what is on the map to what needs attention.
In one recorded Calgary query, our experimental iOS reader selected one of 1,375 spatial cells and emitted 5,916 shapes for the downtown viewport. The retained dataset contained about 13.5 million primary records. Spatial organization gave the application a smaller place to look.
That is a useful result for teams building maps into field software. A region can stay available locally while the application selects relevant geometry. This May 2026 result came from an iOS simulator diagnostic, and the geometry query took about 783 milliseconds. It demonstrates locality; physical-device responsiveness needs its own measurement.
Where this fits among offline map tools
Offline maps already have strong foundations. MapLibre Native stores the resources for an offline region. PMTiles organizes tiles in a single archive and supports selective retrieval. OGC GeoPackage puts spatial features, tiles and attributes in a portable SQLite database suitable for limited-connectivity environments.
Our experiment explores a particular building block within 8DB, our omnimodal database: a spatial representation whose layout is directly usable by a geometry reader. The useful comparison is how each approach delivers local spatial information. This campaign provides no matched speed ranking against those alternatives.
Choose by workflow · documented capabilities, not speed rankings
Four ways to bring spatial data closer
MapLibre Native
Download a region's map resources for offline display.
Offline-pack documentationPMTiles
Keep a tile pyramid in one file; retrieve the relevant byte ranges.
Format and access modelOGC GeoPackage
Carry spatial features, tiles and attributes in a SQLite container.
Standard overviewGNSE-Spatial
Select cells, inspect binary feature bounds and reconstruct geometry for the viewport.
Calgary iOS simulator · May 2026Organize the work before the user asks
The Calgary path prepared its geometry ahead of time in GNSE-Spatial, our binary spatial format. It divided the region into cells and stored fields such as identifiers and bounding boxes in columns. A spatial ordering placed nearby records together.
The reader then used three levels of selection. First, it chose cells intersecting the viewport. Within those cells, it checked feature bounds. Finally, zoom and visible-size rules decided which kinds of shapes were worth drawing. A small building can remain available in the data while disappearing from a city-wide view where it would occupy less than a pixel.
The recorded reader accessed memory-mapped binary columns without a JSON parsing step on the frame path. Geometry still required reconstruction before emission. Memory mapping also leaves real memory and I/O costs: pages must become resident when accessed, and decoded output needs space.
The distinction matters. Selecting one cell avoided scanning the primary records in the other cells, but that selected cell still involved 190,513 primary records. One cell out of 1,375 is a selection count, not a 1,375-fold speedup or a measurement of RAM saved.
One recorded downtown query · iOS simulator · 14 May 2026
A local question inside a large dataset
1 of 1,375 cells selected. The grid illustrates the count, not Calgary's geography or relative cell sizes.
Where the geometry query spent its time
Approximately 783 ms total for this diagnostic query.
All bars start at 0; each track spans the complete 782.692 ms query. “Other” is calculated as total minus the two rounded reported components.
A result you can inspect, and a clear next improvement
The diagnostic recorded a downtown viewport at zoom level 13. It emitted 641 polygons and 5,275 lines. Of the approximately 783 milliseconds spent producing that geometry, 546 milliseconds went to culling and 225 milliseconds to way decoding; the remaining time covered other work in the query.
Those measurements make the next engineering decision concrete. The outer spatial partition is doing useful work. The next opportunity is inside the selected cell: reduce repeated culling and decode work while preserving the required geometry. A repeat-query cache was proposed in the historical report, but its expected benefit was not a measured frame-rate result.
For a field application, the right acceptance test would add repeated pans, cold starts, memory pressure and battery use on the intended phone. It would also verify the features the application needs, including relation-based geometry. The recorded fixture did not include populated topology records for those relations. Wider coverage and physical-device performance remain separate qualifications from the downtown demonstration.
One spatial view within a broader database
An inspector selects a road segment after a flood. Its shape identifies the place. A photograph shows damage, a recent reading suggests whether conditions are changing, and the previous inspection explains what was already known. The decision needs all of them.
The useful division of work is explicit:
| Question | What supplies the answer | Status |
|---|---|---|
| Which geometry is in this view? | Spatial cells, feature bounds and level-of-detail selection | Exercised in the Calgary diagnostic |
| Which observation belongs to this feature? | Stable feature identity connected to application records | Integration to demonstrate for the customer's data |
| What changed, and what should the inspector review? | Related observations, history and native query operations | Application opportunity built on the broader engine |
8DB's opportunity is to make those questions part of one local data environment. A team could spend less effort translating between a map feature, a synchronized document and a separate relationship store. That is a reason to evaluate the complete field workflow, even when an established renderer remains the right presentation layer.
8DB is built for when you need more than a basemap. A location becomes an entry point into observations, history and connected evidence. The Calgary work supplies the spatial building block; the next evaluation connects it to your operational investigation.
The 8DB code contains the spatial encoder and reader structures, including ordered primary records, boundary references and topology fields. The Calgary demonstration exercised an exported spatial representation. Combining that map with governed observations and other modalities is a further integration to validate; this rendering measurement does not establish encryption, transaction or access-control behavior for the exported files.
We explore the broader design in our article on multiple views of the same data, and the device context in our on-device intelligence article. The practical lesson from Calgary is already useful: organize a large spatial dataset so the application can ask a local question of it.
Bring the region your application needs
Send a non-sensitive example of one map feature and the information a field worker needs after selecting it. Include the target device and expected offline period. The first output is a small integration sketch separating the map reader, connected records and presentation layer, with a clear test for the proposed benefit.
Map your first local investigation with 8Braid.
Evidence scope: the numerical example is the May 14, 2026 Calgary simulator diagnostic, not a fresh phone benchmark. It reports one viewport query rather than a distribution of frame times. Full-region storage, selected records and emitted shapes are different counts. No planet-scale capacity or competitor speed advantage is inferred. Map data: © OpenStreetMap contributors, available under the Open Database License.
Evidence scope Recorded iOS simulator diagnostic · Spatial locality demonstrated · Device performance separately qualified. Explore the evidence. Methods and retained scope notes.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work