[Bug]: Temporal aggregation window for now image may include more years than expected

[Uttkarsh779]

Pre-submission Checklist

• I searched existing issues and this is not a duplicate
• I can reproduce this bug consistently

Component / Module

Layer Generation (/computing)

Severity

Medium (feature partially broken, workaround exists)

Bug Description

While reviewing the change detection pipeline, I noticed that the now image is constructed using l1_asset_remapped[3:], which includes all assets from index 3 to the end of the list.

For time ranges longer than 6 years, this results in the now image being computed from more than 3 years of data.

I would like to confirm whether this behavior is intentional.

Steps to Reproduce

Consider a pixel whose classes are:

2018=1
2019=6
2020=1
2021=1
2022=1
2023=1
2024=6
2025=6

Using [3:]:

mode(1,1,1,6,6) = 1

Using [-3:]:

mode(6,6,6) = 6

The resulting class differs depending on the aggregation window.

Questions
Is the use of l1_asset_remapped[3:] intentional?
Should now represent all years after the first three years?
Or should it represent the final three years only?
Is there any specification or design document describing the intended temporal aggregation logic?

Expected Behavior

For an 8-year period:

2018
2019
2020
2021
2022
2023
2024
2025
An alternative interpretation could be:

then = mode(2018, 2019, 2020)
now = mode(2023, 2024, 2025)

Actual Behavior

For an 8-year period:

2018
2019
2020
2021
2022
2023
2024
2025

Current implementation produces:

then = mode(2018, 2019, 2020)
now = mode(2021, 2022, 2023, 2024, 2025)

Environment Details

• OS: Ubuntu 24.04 (WSL2)
• Python version: 3.10.x (Conda environment)
• Django version: 5.2.x
• Celery version: 5.6.x
• Deployment: Local development environment (WSL2 + Docker services)

Logs / Error Messages

No response

Screenshots / Screen Recordings

No response

Additional Context

No response