Skip to content

Comparison: stack each side's layers in the map's z-index order - #564

Merged
BhattaraiSijan merged 1 commit into
developmentfrom
hotfix/comparison-layer-order
Oct 8, 2026
Merged

BhattaraiSijan merged 1 commit into
developmentfrom
hotfix/comparison-layer-order

Conversation

@sandesh-sp

Copy link
Copy Markdown
Collaborator

Problem

In comparison mode, layer ordering was ignored: vector layers were drawn underneath raster layers on both sides of the divider (e.g. Air4US with the AQS vector layers over TEMPO HCHO, comparing Feb 27 vs Feb 28, 2025).

Cause

The Comparison tool hands core its visible layers in config order, which is top-first. deck.gl renders index 0 at the bottom, and _comparisonClonesFor cloned layers in the order it was given, so each side's stack came out inverted.

Fix

DeckGLAdapter._comparisonClonesFor now walks the layer registry, which is already sorted by z-index, and keeps the requested ids. The caller's list decides which layers each side draws; the engine decides their stacking, so both sides match the primary map, including after a user reorders layers.

Testing

  • Loaded the Air4US mission with three AQS vector layers and the TEMPO raster, enabled a Feb 27 / Feb 28 dates comparison, and confirmed the vector points render above the raster.
  • No automated coverage exists for the adapter's comparison path.

The Comparison tool lists layers top-first, while deck.gl draws index 0 at
the bottom, so cloning in the caller's order inverted the stack and buried
vector layers under rasters. Each side now draws its layers in the
registry's z-index order, matching the primary map.
@BhattaraiSijan
BhattaraiSijan merged commit 3ab99c6 into development Oct 8, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants