Reading the Globe: Sources, Layers, and Ownership
God's Eye View's central engineering problem is not drawing many markers; it is combining unlike public sources without making them look like one uniform kind of truth. This chapter traces that problem from the provider ladder to the browser layer and its lifecycle. By the end, you should be able to follow a visible object back to its source, understand what a credential changes, and see why ownership and attribution are functional parts of the globe rather than housekeeping around it.
A layer is a claim about a source
A layer is easiest to understand as a packaged claim about where information came from and how it may be used. The aircraft layer says something different from the earthquake layer, even before either one draws an icon. One consumes aircraft state vectors; the other represents seismic reports. A radio layer is a directory of broadcasters, while a submarine-cable layer is a bundled geographic dataset. A traffic layer can place simulated vehicles on real OpenStreetMap roads, with optional live flow speeds affecting the simulation. A CCTV layer can show public frames, but its camera pose begins as a published or estimated position that the operator may calibrate.
The common globe hides those distinctions just enough to make exploration easy. The source model has to put them back.
A useful classification has four questions. Is this an observation, a directory, a static extract, or a model? Is it current, cached, stale, or reconstructed? Is its geography global, viewport-bounded, or tied to one public provider? And what license or attribution follows it into the scene? These questions are more useful than memorizing the application's full layer list because they predict what a new or unfamiliar layer can responsibly say.
An aircraft position is an observation delivered through a feed, but even that word needs qualification. The source updates periodically, the application may cache a successful response, and the browser may interpolate or dead-reckon between fixes. The result can be a useful moving representation without being a continuous measurement. An earthquake record is also source-backed, but its map symbol does not imply that every surrounding area has been surveyed. A static datacenter extract establishes mapped context, not current network activity.
The traffic layer makes the difference especially visible. Without a TomTom key, God's Eye View runs a built-in simulation: vehicles move on real road geometry, but individual positions are not live observations. With the optional provider, live flow tiles can drive speed and congestion coloring. That adds another source of evidence about aggregate traffic conditions; it does not magically turn the simulated dots into observed vehicles. The same screen can therefore show real roads, provider-backed flow, and a modeled population at once.
CCTV has a related but different boundary. Public camera catalogs and frames can be projected into a 3D city, which is more spatially informative than placing a thumbnail in a conventional panel. Yet the camera's orientation and coverage are not necessarily supplied as authoritative geometry. The project describes these poses as estimated priors and lets the user calibrate them by dragging a gizmo on the camera. The projection is useful precisely because it is inspectable and adjustable; it is not a guarantee that the camera sees every point inside the rendered frustum.
Space Missions makes the distinction between source and presentation explicit. Launch Library 2 supplies recent launch, payload, stage, recovery, and orbit metadata, but it does not normally provide continuous ascent telemetry. When trajectory samples are missing, the application can render a smooth launch-to-insertion path labeled RECONSTRUCTED ESTIMATE. That path can explain the mission's geometry and make a replay possible. It cannot prove where the vehicle was at each intermediate moment. A planned orbit recorded on a failed launch is not evidence that the payload reached orbit, so the runtime suppresses live or estimated orbital treatment for failed records.
This classification also explains why absence is dangerous. A map view can be empty because a feed is loading, because a provider is unavailable, because the layer only queried the current viewport, because an object is behind the globe, or because the rendering budget selected other labels. None of those conditions means that the underlying object does not exist. God's Eye View's status vocabulary—loading, degraded, stale, fallback, unavailable—exists to keep those situations from collapsing into a falsely confident blank or zero.
The provider ladder adds a second dimension: capability and access. The keyless baseline uses Esri satellite imagery and a keyless terrain path, with OSM available as a fallback or explicit road-oriented source. Richer Google Photorealistic 3D can arrive through an eligible Cesium ion route or through the direct, metered Google path; ion-hosted Bing imagery also requires an ion token. Optional keys can add live vessel data, NASA active fires, TomTom flow, or voice control. The application can therefore start with no credentials while still offering a higher ceiling to an operator who accepts provider terms and quotas.
A key changes what the application may request, not what the world is. It can make a provider available, raise an allowance, or enable a paid capability. It does not certify the resulting data, remove source coverage gaps, or turn a modeled layer into an observation. That is why key state and feed health are shown separately. A missing FIRMS key is a deliberate KEY REQUIRED condition; it is not the same as a failed earthquake feed. A Google 3D route that has a configured key but fails to load should point toward restrictions, quota, or connectivity, not tell the operator to add a credential that is already present.
The ladder is therefore not a ranking from bad to good. It is a set of operating conditions. A keyless Esri view may be the honest and practical choice for a first exploration. A direct Google route may provide more detailed 3D cities but introduce billing and key-restriction obligations. OSM may be the correct fallback when a richer imagery service is unreachable. Choosing among them changes the visual context, the cost, and sometimes the vertical surface used for placement; it does not erase the need to interpret the data source.
The same principle applies to licensing. God's Eye View's code is MIT-licensed, but the repository explicitly carves third-party data and visual assets out of that grant. OpenStreetMap-derived datasets carry ODbL obligations. TeleGeography's submarine-cable map is identified as noncommercial unless separately licensed. Google, Esri, TfL, OpenSky, and other providers retain their own terms. The in-app attribution line and data-attribution panel are not decorative credits added after the map works. They tell the reader which public or proprietary source is responsible for a visible surface and which permission governs reuse.
From provider feed to visible object
The source distinction becomes operational through a chain of owners. At the far end, a provider returns data—or fails to. In the middle, a local server route handles the problems a browser should not handle directly: CORS, private credentials, response-size limits, caching, request coalescing, retries, stale responses, and source-specific normalization. At the browser end, a data layer turns normalized records into Cesium entities, shared overlay entries, selection context, and user-facing statistics.
That chain is intentionally not one large “load everything” function. The reusable application has four construction phases: scene, controls, data, and tools. The scene owns the viewer and initial map presentation. Controls own styles and camera presentation. Data registers layers and restores their state. Tools add scenes, annotations, voice, and page-level listeners. Later phases receive earlier components rather than discovering them through global imports. A component can be synchronous or asynchronous, but it receives the shared cancellation signal and can register cleanup as soon as it acquires a resource.
The order matters at failure time. If a data constructor starts an operation and then fails, the application does not simply abandon the viewer. It aborts the shared signal and runs the same cleanup path used by explicit destruction. Teardown proceeds in the reverse ownership order: tools first, then controls, data, and scene. Controls must be able to cancel restoration while the data manager and viewer still exist. A repeated start() returns the same startup promise; a repeated destroy() returns the same teardown promise. These details turn lifecycle into a contract instead of a collection of hopeful conventions.
Each production data layer follows a similar public shape: initialize its resources, enable or disable its presentation, update its data, destroy what it owns, and expose statistics. Some layers also expose detectable objects, selectable context, tracking, or parameter controls. The layer owns the meaning of its records and the mechanics of its source-specific presentation. The data manager owns the shared visibility transaction and periodic refresh. This division prevents a fast UI click, a slow provider response, and a later refresh from independently deciding what “on” means.
Consider a layer toggle. Enabling is not considered complete merely because an initialization call returned. The manager can initialize the module, apply pending parameters, enable it, run its first update, settle the lifecycle state, and only then arm periodic refresh. A failure in initialization, enabling, or the first update triggers cleanup and reports failure. A slow or cancelled transition remains visibly transitional rather than flipping the control to a settled state early. If a newer absolute visibility request arrives while an older one is waiting, the older operation is superseded and its late result cannot publish itself as the final state.
Periodic refresh is a separate responsibility. Once a layer is enabled, a feed update can be refreshing while visibility remains authoritatively on. The manager records that work and asks the scene for a render when the update changes what is displayed. If the producer returns stale data, a fallback, or an error after keeping its last records, the manager can present the specific condition without pretending that the layer has disappeared. That separation is what allows a cached aircraft snapshot to remain visible while still being labeled stale, and what lets a source-specific outage remain distinct from a user turning the layer off.
The browser presentation has two related routes. Some information belongs in Cesium-native geometry: a point, billboard, ground primitive, orbit ring, or camera frustum needs to exist in the 3D scene for depth, picking, or terrain interaction. Other source results are transformed into user-facing labels, cards, or status text by browser presentation components. The source still supplies the meaning and state; rendering decides how it can be inspected at the current camera and scale. Keeping those responsibilities separate lets cross-layer presentation become consistent without making the source records identical.
That ownership model explains why the application can add a new CCTV city pack or a new data layer without rewriting the globe. A camera pack supplies a clean catalog, attribution, and server-registered frame URLs. A new layer supplies its source adapter, lifecycle, statistics, and—if needed—bounded selection or presentation behavior. The application supplies the viewer, data manager, context store, and render operations. Reusable infrastructure exports receive those callbacks instead of creating a second viewer, context store, or render scheduler. Cesium remains an external shared dependency so a consumer does not accidentally render with a different library instance from the one used by the viewer.
The boundaries also tell you where an extension does not belong. A private API credential belongs in the server provider, not in a browser layer. A source-specific retry policy belongs with that provider or layer, not in a generic overlay painter. A cross-layer collision rule belongs in the shared host, not duplicated in every label module. A durable option must be registered with the application's serialization rules, while derived health, caches, temporary mode ownership, and playback should not be smuggled into a share link as if they were user intent.
This is why source ownership and lifecycle ownership are inseparable. If a layer cannot say who owns its socket, timer, cached response, Cesium entity, overlay entry, and selection record, it cannot reliably answer what remains after disable, refresh, cancellation, or replacement. God's Eye View's explicit boundaries are not an aesthetic preference for modular code. They are the mechanism that keeps a visible relationship traceable: from source, through transformation, to the object a reader sees.
The next problem follows naturally. Even when a layer has a clear source and a clean lifecycle, its data may arrive only every few seconds and use a different vertical reference from the rendered world. The application must decide what position to draw between source updates, how long to coast when the feed goes quiet, and how to keep a grounded aircraft from sinking into the 3D tiles. The globe's ownership chain makes those decisions possible; the motion model determines what the reader actually sees.