A single 3D model can be downloaded as one asset. A neighborhood, factory, campus, or planet cannot. Large spatial content requires a hierarchy that lets clients discover what exists, choose an appropriate level of detail, request only visible regions, and release data as the camera moves. The spatial API is not merely a file server; it coordinates metadata, access, versions, and queries around the streaming representation.
3D Tiles and glTF address complementary needs. glTF is a delivery format for individual 3D scenes and models. A tile hierarchy organizes many payloads across space and levels of detail. A product may also need semantic entities, search, annotations, and edits that do not belong inside immutable render assets. The architecture should connect these layers without forcing them into one giant format.
Separate catalog, hierarchy, payload, and domain state
The catalog describes available datasets, coverage, time, ownership, licensing, and versions. The hierarchy organizes spatial regions and refinement. Payloads contain renderable geometry, textures, and metadata. Domain state contains durable entities such as assets, issues, annotations, work orders, or gameplay objects. Each layer has a different lifecycle and caching strategy.
A client can discover a dataset through the catalog, stream its hierarchy for visualization, and query domain entities for interaction. Updating an annotation should not require regenerating a city mesh. Reprocessing geometry should not change stable business IDs. Links and metadata connect the layers.
Hierarchical level of detail
A tile hierarchy allows a coarse representation to stand in for many detailed children. The client selects tiles based on camera position, screen-space error, performance budget, and visibility. Refinement can replace a parent or add detail to it. The server or manifest must provide bounds and geometric error information that support consistent selection.
Level of detail is more than polygon count. Textures, materials, metadata, and feature density also affect cost. A distant city block may need a simplified mesh and atlas texture, while a nearby facade needs separate features and higher resolution. Build the pipeline around target experiences and devices rather than producing every level at maximum fidelity.
Use glTF as an asset building block
glTF is designed for efficient transmission and loading of 3D scenes and models. It can package meshes, materials, textures, animations, and extensible metadata. In a streaming system, glTF or binary glTF payloads can represent tile content, individual assets, or downloadable detail. Keep coordinate, unit, and orientation conventions consistent through ingestion.
Optimize assets before delivery: remove unused data, compress geometry and textures where supported, generate tangents only when needed, and validate materials on target renderers. Preserve source provenance and content hashes so the pipeline can reproduce and cache outputs. Runtime fixes for malformed assets become unmaintainable at scale.
Metadata and feature identity
Visualization becomes an application when users can select a building, pipe, room, tree, or machine and retrieve meaningful information. Streaming payloads may carry feature metadata or identifiers, but the durable record should live in a queryable domain service. The render feature ID maps to a stable domain ID and dataset version.
This mapping must survive tiling and level-of-detail changes. One real-world object may be represented differently in parent and child tiles. Define whether selection resolves to the object, the rendered fragment, or a grouped feature. Keep the API response clear about which identity was returned.
Spatial queries beside the renderer
Render hierarchies are optimized for visibility, not every analytic question. Provide services for bounding-box search, point containment, nearest feature, ray intersection, attribute filtering, and time or version selection. Some queries can use the same spatial index that built the tiles; others may use a database or specialized acceleration structure.
Clients should not have to download hidden geometry to answer a simple query. A field application can request assets near a location, then stream only the corresponding visual context. A review tool can search annotations by status without traversing every tile. Keep query results connected to render IDs so the client can highlight the right feature.
Caching, versions, and invalidation
Large content must be cacheable. Use immutable URLs or versioned keys for tile manifests and payloads. Content hashes make safe long-lived caching possible. A small catalog or alias can point clients to the current dataset version. Do not overwrite a payload at the same URL and expect every CDN and device cache to update immediately.
For frequently changing overlays, separate dynamic data from the static base layer. Vehicles, alerts, and edits can arrive through lightweight APIs or streams while terrain and buildings remain cached. When a new base version is published, include compatibility metadata so clients know whether overlay mappings remain valid.
Access control and signed delivery
Private spatial datasets may reveal facilities, operations, or personal environments. Authorization should apply to the catalog, hierarchy, payloads, and query services. Short-lived signed URLs can deliver large immutable assets after the application verifies access. Avoid embedding permanent broad-scope credentials in a client.
Tile-level authorization can be expensive, so design dataset partitions around real access boundaries. Log access at a useful granularity without recording every camera movement as sensitive telemetry. Revocation and version retirement should be planned before data is distributed to offline clients.
Observability and budgets
Measure time to first meaningful view, requested and decoded bytes, active tiles, cache hit rate, memory, frame time, and failed payloads. Break metrics down by dataset version, device class, and network condition. A beautiful desktop demo may hide a poor mobile experience caused by large textures or too many small requests.
Budgets should be explicit: maximum visible triangles, texture memory, concurrent requests, decoded payload size, and metadata count. The selection algorithm can adapt to stay within budget, but the content pipeline must also produce levels that make adaptation possible.
Conclusion
World-scale 3D delivery works when the system separates discovery, hierarchical refinement, render payloads, and durable domain state. 3D Tiles provides a practical structure for streaming; glTF provides an efficient asset foundation; spatial services provide search and interaction. Versioned immutable content, stable feature IDs, and measurable budgets turn a collection of models into a dependable spatial platform.
Build a repeatable ingestion pipeline
Ingestion begins by validating source rights, coordinate systems, units, timestamps, and expected coverage. Normalize assets into a controlled intermediate representation before tiling. Record every transformation—reprojection, mesh repair, decimation, texture conversion, metadata join, and feature-ID assignment—so the output can be reproduced from source data.
Generate bounds and statistics during processing. Detect empty tiles, extreme geometric error, missing textures, invalid materials, feature-ID collisions, and discontinuities between neighboring regions. A preview environment should let reviewers compare source and output at several levels of detail before publication.
Publish the hierarchy and payloads as an immutable version. The catalog points to that version only after automated checks and review pass. If a defect is found, publish a corrected version and retire the alias; do not mutate cached payloads in place. Keep source and pipeline version metadata so regressions can be traced.
Define the client delivery contract
A well-defined client contract lets a browser, mobile renderer, game engine, or headset use the same dataset while choosing a device-appropriate level of detail. It also leaves room to replace the tiling pipeline without changing the product’s domain API.
- Catalog response with dataset ID, version, extent, time coverage, rights, and entry point.
- Immutable hierarchy and payload URLs with cache validators or content hashes.
- Feature-ID mapping from render metadata to stable domain resources.
- Query endpoints for nearby, intersecting, selected, and time-filtered entities.
- Capability hints for compression, texture formats, metadata, and maximum detail.
- Clear errors for unauthorized, retired, unavailable, or incompatible dataset versions.
- Telemetry fields that measure bytes, decode time, cache behavior, and visible quality.