cd ~/
MappingChange DetectionMaintenanceVPSMeta

Keeping Maps Fresh: The Temporal Challenge

Maps go stale as the world changes. Strategies for detecting and handling changes in visual positioning.

Evyatar Bluzer
4 min read

New buildings go up, old ones get demolished, stores rebrand, signs change, seasons cycle. Every one of those events quietly invalidates some piece of a VPS map, and the map has no way of knowing on its own. Keeping maps fresh has turned out to be one of the harder operational problems we deal with.

How fast do maps go stale?

Take a map captured in January 2021 that is still serving queries in December 2021. In between, construction changed the building facade, seasonal foliage blocked features, street furniture moved, and business signs got updated. If more than 30% of the features changed, localization may fail outright.

Change Detection

At query time

When a user query does not match the map well, the mismatch itself is the signal (the pipeline already flags a changed scene as a possibly stale map). A low inlier ratio means something changed. Inconsistent matches point to partial changes. High reprojection error suggests a systematic shift. The catch is that query-time detection can tell you the map is stale but cannot fix anything while the user is standing there waiting for a pose.

Stale map detection and re-captureSequence diagram with four lifelines: user query, VPS service, map, and mapping operations. A highlighted note on the VPS lifeline marks the stale signal; one arrow returns a degraded answer to the user, and two arrows carry the flagged area through operations back to the map. User queryVPS serviceMap (captured January)Mapping operations query image match features now: lower confidence score,GPS fallback if it drops too far,request for updated imagery area flagged stale later: re-capture, SfM and MVS,QA checks, then publishStale signal: low inlier ratio,inconsistent matches,high reprojection errorRe-capture queue, prioritized:high traffic, AR experience sites,user reports, expected value
One stale map, two responses: the query that fails on it gets a lower confidence score or a GPS fallback on the spot, while the area joins a prioritized re-capture queue and only returns to the map after SfM, MVS and QA.

Proactive monitoring

The alternative is to go looking. We schedule re-capture for high-value areas, collect user images (with consent) as passive monitoring, and compare new captures against the existing map.

Automated analysis

Ground truth is scarce, so we lean on proxies: feature stability (which features persist across time), semantic consistency (does the building still look like a building), and geometric consistency (does the structure match what we expect).

Handling Changes

Graceful degradation

When a map is stale, we return a lower confidence score, fall back to GPS if confidence drops too far, and suggest the user contribute updated imagery. Not glamorous, but it keeps the experience from breaking.

Multi-temporal maps

Store multiple versions of the same place: seasonal variants (winter vs summer), time-of-day variants (day vs night), and historical versions for change tracking. Each query matches against the appropriate variant. Storing several copies of the same street feels wasteful right up until you watch a summer map fail all winter.

Continuous refinement

Maps also update incrementally. New observations refine existing structure, change detection triggers re-mapping, and automated quality checks run before anything gets published.

Economic Considerations

Re-mapping costs real money: capture (vehicles, people, storage), processing (compute for SfM and MVS), and validation (QA and review). The quality-versus-coverage economics of the first capture apply to every re-capture, so we prioritize. High-traffic areas get updated frequently, popular AR experience locations jump the queue, user-reported staleness triggers a review, and budget gets allocated by expected value.

The Seasonal Problem

Seasonal changes are predictable but dramatic. Deciduous trees go from full foliage to bare branches, snow cover completely changes how a place looks, and the sun angle throws different shadows across the year. Each of the options hurts somewhere. Seasonal map variants are expensive and multiply storage. Season-invariant features are still a research direction. Semantic matching means matching the building rather than the texture. We are currently exploring season-invariant feature learning.

Success Metrics

We track map age distribution (how old are our maps), change rate by area (how fast do different regions change), localization success against map age (is there a correlation), and user-reported staleness incidents. The target is under 5% of queries affected by stale maps. Whether the world cooperates is another matter.

Comments