← back to the archiveCover illustration for “A moving dot is making a claim about time”
VIDEOday 104·2d ago·by Andy Padia

A moving dot is making a claim about time

God’s Eye View makes spatial data compelling. Its most useful design lesson is to distinguish observations, interpolation and unavailable information on the map itself.

original on Instagram · open source ↗

TL;DR: I want a moving dot to explain whether it was observed, estimated or simply left on screen. Bilawal Sidhu’s God’s Eye View is a useful reference for anyone designing maps, operational dashboards or AI interfaces that combine information arriving at different speeds.

Sidhu’s short introduction presents an open-source spatial interface combining aircraft, vessels and other public data. The appeal is immediate: separate feeds become a world you can navigate. The design question appears a moment later. What, exactly, does the movement certify?

The project documentation provides a revealing answer. It describes interpolating between flight fixes and using dead reckoning to fill gaps. It also distinguishes simulated road vehicles from live traffic-flow information. A smooth interface can contain several different kinds of evidence at once.

That distinction is the part I would carry into another product. Animation describes how the interface changes between observations. It cannot, by itself, establish that another observation occurred.

Give the observation its own clock

Imagine a delivery dashboard. A vehicle reports a location at 10:00. The interface estimates movement along a road until 10:01. Then the connection drops. This is an illustrative scenario, but it exposes a choice every such dashboard has to make.

Leaving the vehicle in motion could suggest evidence the system no longer has. Freezing it without explanation could suggest that the driver stopped. Removing it could suggest that the delivery disappeared. All three can be wrong interpretations of the same missing update.

I would keep the last observed location visible, distinguish any estimated continuation, and show the observation time beside the selected vehicle. When the estimate exceeds the product’s useful horizon, the display should say that a current position is unavailable. The threshold should follow the decision being supported: an exploratory map and a dispatch operation have different tolerances.

A timestamp hidden in a settings panel does little for the person making that decision. The uncertainty belongs where the visual claim is being made.

The same rule applies to an AI summary above the map. If the underlying layer is old, a sentence in the present tense should not silently make it fresh. A description can inherit the layer’s age and still sound confident.

Review the gap as carefully as the happy path

For a practical design review, I would replay one sequence containing a fresh observation, an estimated interval and a failed update. Ask a colleague what they believe happened at each point. Their interpretation is the test; how elegant the animation looks is a separate question.

The reel is a product introduction, and the repository is documentation rather than independent validation. I haven’t installed or benchmarked the system. Provider coverage, quotas and update behaviour also constrain what any installation can show.

Those limitations make the design lesson more useful. The interface earns trust by making its evidence legible even when the feed is incomplete.

Every moving dot should carry an answer to: when did we last actually observe this?

#ai#Data
← older drop
Give the free course a deliverable
newer drop →
Before I delegate, I want to know who pays the agent

related drops

explore all 329 drops →
← back to the archiveday 106