feat(widgets): Add OverviewMapWidget for spatial navigation

[aivis-sjlee]

Closes #9977

Background

Large-scale image viewers and GIS applications require spatial context while zoomed in. Users often lose awareness of their position within the overall view. An overview map (minimap) provides a thumbnail of the entire content with a highlighted box showing the current viewport, enabling quick navigation by clicking on the minimap.

Change List

• Add OverviewMapWidget class in @deck.gl/widgets
  • Auto-captures deck canvas as thumbnail (or accepts custom thumbnailUrl)
  • Displays viewport box indicating current view position
  • Click-to-navigate: click anywhere on minimap to pan main view
  • Collapsible toggle between expanded and minimized state
  • Supports both OrthographicView and WebMercatorViewport
• Add React wrapper OverviewMapWidget in @deck.gl/react
• Add CSS styles for the widget in stylesheet.css
• Add unit tests for OverviewMapWidget
• Update widgets example to include OverviewMapWidget
• Export as experimental (_OverviewMapWidget) following deck.gl conventions

[chrisgervang]

I'm curious why this is useful when changing viewState also changes that outer bounds of the overview. Is the captured canvas not a mirror image of the zoomed in viewport?

Could you please share a screen recording or GIF of how auto-update is intended to work?

[aivis-sjlee]

Hi @chrisgervang and @felixpalmer ,

Thank you for the insightful feedback. After reflecting on your comments and testing in various environments, I completely agree with the point that the current capture logic has a fundamental flaw: consistency.

I initially aimed for a dynamic synchronization between the map and the overview, but as you pointed out, capturing the current canvas while zoomed in makes the "Overview" lose its purpose as a reference point. If the background image changes its bounds along with the main view, it’s no longer an "overview," but just a blurry mirror.

The Dilemma: My goal for this widget was to provide a "batteries-included" solution that differs from the Multi-view approach in two ways:

Performance: Avoiding the overhead of rendering all layers twice.

Ease of Use: A simple plug-and-play widget without boilerplate for coordinate transformation or layer duplication.

The Conflict: However, I’m now facing a technical conflict:

If I only capture once at the start, it likely won't capture the "full extent" of the map.

If I create a hidden off-screen canvas to render the full extent, it starts to consume the same resources as a second view, which contradicts the "performance" advantage I intended.

If I continue with the current captureOverview at intervals, it remains functionally inconsistent when zoomed in.

Conclusion: This PR currently has conflicting goals. While the widget provides great UX benefits (built-in click-to-navigate, easy positioning, etc.), the underlying method for generating the background image needs more thought.

I might need to reconsider whether this widget should: a) Require a mandatory thumbnailUrl from the user for a static background. b) Or, find a more efficient way to capture the "home" view without the heavy lifting of a full second view.

I'll take some time to think more deeply about how to balance "Ease of use" and "Functional correctness." I’d appreciate any further thoughts on whether a "static-capture-at-home-view" approach would be acceptable, or if we should pivot the implementation entirely.

[felixpalmer]

Interesting proposal, just trying to understand how is this better than using a second view to draw a minimap? https://deck.gl/examples/multi-view, could you comment @aivis-sjlee ?