A dataset lists its date as last month. The map renders, the features look plausible, and a team builds an analysis on it. Somewhere in that dataset are buildings surveyed six years ago, roads last verified before a highway was rerouted, and business listings whose operators closed during a period nobody re-checked.
None of that contradicts the published date. The published date describes when a file was assembled and made available. It says nothing about when the world it describes was observed, and those two moments can be separated by years.
Staleness is not a single number attached to a dataset. It is a distribution across records, and treating it as a scalar is how a map ends up confidently wrong in exactly the places where being wrong matters.
A dataset has many clocks, and the published one is the least useful
At least four distinct times exist for any given record, and most pipelines carry only one of them.
Observation time is when the phenomenon was actually seen: the imagery acquisition date, the day a surveyor stood in the street, the moment a contributor recorded a point on a phone. This is the only timestamp that describes the world rather than the pipeline, and it is the one most often discarded.
Processing time is when the raw observation became a record: when imagery was classified, when a model inferred footprints, when a submission was validated and merged. For derived products this can lag observation by months, and it can differ per record within one release because inputs arrive on different schedules.
Publication time is when the file or endpoint became available. This is the date in the catalogue, the release version, the thing an analyst quotes when asked how current the data is. It is a property of the distribution process and can be entirely disconnected from the other two: a release published this quarter can consist mostly of observations from several years ago, and often does, because a release is an assembly of whatever was already available.
Retrieval time is when a system fetched it. This one is generally known accurately, since the fetching system controls it, and it is also the one that matters least. A record downloaded this morning is not fresh. It is a recently transferred copy of something that may be very old.
The gap between observation and retrieval is the real age of the information. Almost every metadata standard reports publication, because publication is the only one the publisher directly controls. Anyone reasoning about currency needs the first number and is usually handed the third.
Layers age at wildly different rates
Treating a stack of layers as equally current is a category error, because the phenomena underneath them change on completely different timescales.
Terrain and elevation change slowly, outside landslides, quarrying, coastal erosion, and large scale earthworks. A digital elevation model from several years ago is usually fine, and its age is rarely the limiting factor in an analysis.
Administrative boundaries change occasionally and discontinuously. They can be stable for years and then move in a single legal act, and the change is total rather than gradual. Age alone does not indicate whether a boundary file is right; what matters is whether a redistricting or reorganisation has occurred since.
Road networks change continuously at the margins, mostly through new development, and occasionally in ways that break routing entirely: a new interchange, a permanent closure, a one way conversion. The topology is more fragile than the geometry, and a small change in the wrong place invalidates a large number of computed routes.
Buildings change fast in growing places and slowly in settled ones, which is the uneven ageing problem in its purest form.
Business and point of interest data ages fastest of all. Names, operators, opening hours, and existence itself churn on a timescale of months in commercial districts. A points of interest layer that is two years old is not slightly degraded, it is substantially fiction in the categories that turn over most.
Live feeds, such as vessel or aircraft positions, weather, and hazard alerts, age in minutes. Mixing them with anything above requires care, because a decision joining a five minute old position to a five year old building layer inherits the worse of the two, not the better.
The design consequence is that a system should never present one freshness figure for a composite product. Each layer should carry its own, and any derived figure should carry the age of its oldest meaningful input.
Staleness is uneven inside a single dataset
Even within one layer, from one publisher, staleness varies enormously, and it varies in a way that is structured rather than random.
Contributed data is remapped where contributors are. Areas with active mapping communities get revisited, corrected, and enriched repeatedly. Areas without them get one initial import, often years ago, and nothing since. The dataset presents both as current, because the release date is a property of the release.
Official data follows survey programmes and procurement cycles, which are typically organised by administrative unit and funded unevenly. Two adjacent districts can differ by several years in their last update purely because they fall under different authorities with different budgets.
Derived data follows imagery availability. Persistently cloudy regions get fewer usable acquisitions, so their derived layers update less often, and the ones with the most cloud are frequently the ones with the most rapid land cover change.
Commercial and crowd contributed points of interest follow commercial attention. Dense urban cores with many users get constant correction. Peripheral areas get almost none.
Each of these mechanisms produces the same pattern: the parts of the map that get attention stay current, and the parts that do not fall progressively further behind while looking identical. The uniform styling of a map is not just an aesthetic choice, it is an active claim of uniformity that the data does not support.
The fast growing area problem
The uneven ageing pattern has a specific consequence that deserves separating out, because it inverts the usefulness of the map exactly where it is needed most.
Places that change fastest are the places where current information has the highest value: new development on an urban fringe, an area rebuilding after a disaster, a corridor along new infrastructure, an informal settlement expanding month by month. These are precisely the places a site selection, logistics, or risk analysis would want to look at, because everywhere else is stable and already understood.
They are also the places where any given snapshot decays fastest. A footprint layer captured before a subdivision was built shows empty land where there are now hundreds of houses. A road network from before an access road was cut shows an unreachable parcel. A points of interest layer from before a new commercial strip opened shows a service desert.
So the error is largest where change is fastest, and change is fastest where the analysis is most consequential. Worse, the failure looks like the coverage failure it resembles: the analysis will report nothing there, and nothing there is indistinguishable from not surveyed and from genuinely empty.
There is no clever fix inside a stale dataset. The realistic responses are to detect the discrepancy using something that updates faster, such as recent imagery or a live derived signal, to flag the area as changing rather than empty, and to be explicit that the answer for that area is lower confidence than the answer for a settled neighbourhood two kilometres away.
Detecting staleness from within the data
Publishers do not always provide a usable observation date, and even when they do it is often one date for an entire release. Several signals let a consumer estimate real currency from the data itself.
- Known recent construction. Pick features that certainly exist and are certainly recent, ideally verified from another source, and check whether the dataset contains them. Their absence dates the layer more reliably than any metadata field.
- Version and edit timestamps where the format carries them. Contributed data usually records when each object was last touched. The distribution of those timestamps across an area, particularly the median and the tail, tells far more than a release date.
- Cross layer inconsistency. A road that ends at nothing, a building that overlaps a road, a boundary that cuts through a structure. These usually mean two layers were captured at different times and one of them has moved on.
- Attribute decay patterns. In business data, a rising share of records with no recent verification, or clusters of records all sharing an identical last checked date, indicates a single bulk import that was never revisited.
- Comparison against a fast moving proxy. Night lights, imagery derived built up area, or activity signals will not tell what changed, but a large divergence between a proxy and the static layer localises where the static layer has fallen behind.
None of these is exact. Together they turn currency from an assumption into an estimate, which is the difference between an analysis that can state its limits and one that cannot.
Carry an observation timestamp per record
The structural fix is to make time a property of records rather than of datasets, and to preserve it through every transformation.
At ingestion, capture the best available observation time for each record, along with the retrieval time and the source. Where the source provides only a dataset level date, store that as a fallback and mark it as such, because a record whose date was inherited from a release should not be treated the same as one that carries its own.
Never overwrite that value when the record is reprocessed. A reprocessing run has a new processing time, which is a different field. Collapsing them makes stale records look fresh, which is the exact failure the whole exercise is meant to prevent, and it is a very common one: an ETL job that stamps every output row with the current timestamp destroys the age information of everything it touches, permanently and silently.
For derived records, propagate the oldest contributing observation time rather than the newest, and preserve the range if more than one input contributed. A figure joining a recent road network to an old building layer is as old as the building layer for any purpose that depends on buildings.
Expose it in responses. A record that ships with its own observation date lets a caller apply its own tolerance, and different callers have wildly different tolerances: a strategic siting study can live with data from a few years ago, and a delivery routing decision cannot.
Where a per record date genuinely does not exist, say so explicitly rather than substituting the dataset date. Unknown is a legitimate value and it is more useful than a plausible wrong one, because a caller can decide what to do with unknown and cannot decide anything about a date that looks real.
What to do when the data will not tell you
Some sources provide no usable temporal information at all, and will not start doing so because a downstream consumer wants it. The question is what a serious system does with them.
The first option is to date them externally. If a source publishes on a known cadence, and a copy was fetched on a known date, then a conservative bound can be constructed and recorded: the data is at least as old as the release, plus the typical lag between observation and release for that publisher. A documented bound is not precision, but it is a defensible statement.
The second is to scope their use. A layer with unknown currency can still be fine for context, for background rendering, or for a stable phenomenon. It should not be the thing a threshold is evaluated against. Restricting an undated source to roles where age does not drive the outcome is a real engineering decision and should be recorded as one.
The third is to schedule verification. Sampling a small number of records against imagery or a live source on a regular basis gives an empirical decay estimate over time, and after a few cycles it becomes possible to say how quickly a particular source drifts rather than guessing.
The last is to be willing to drop it. A source that cannot be dated, cannot be verified, and drives a decision is a liability, and the fact that it was already integrated is not an argument for keeping it.
The uncomfortable part
Publishing per record staleness makes a product look worse before it makes it better. A map with an age field invites the question of why some areas are years old, and the honest answer is usually that nobody has surveyed them and nobody is going to soon.
The alternative is not a fresher map. It is the same map with the question suppressed, and a user who assumes uniform currency because nothing suggested otherwise. That user will eventually make a decision in a fast changing area, discover the gap, and conclude that the whole dataset is unreliable rather than that one part of it is old.
The useful reframing is that age is a feature, not an apology. Knowing that a district was last observed four years ago is actionable: it tells a team to commission a check, to weight the result lower, or to route the decision to somebody with local knowledge. Not knowing is not actionable at all, and the absence of the field is not the absence of the problem.