Add Sentinel-1D support

[dbekaert]

Summary

Adds Sentinel-1D support across the pipeline: AUX_CAL downloads, DAAC metadata schema, and SLC validation.

Changes

AUX_CAL downloads (localize_aux_cal.py)

• S1A/S1B: continue using ASF CloudFront bundles as baseline
• All missions (S1A–D): supplement from ESA SAR-MPC API (https://sar-mpc.eu/api/v1/) to pick up newer files and S1C/S1D entries
• Handles pagination and skip-if-exists caching

SLC validation (localize_slc.py)

• Added S1D_MIN_DATE (2026-04-17) placeholder to reject uncalibrated S1D acquisitions, mirroring the existing S1C_MIN_DATE check
• Updated error messages to include S1D

Metadata (daac_ingest_schema.json)

• Added Sentinel-1D to platform enum

Tests (test_localize_slc.py)

• Added test for S1D minimum date validation
• Updated error match patterns

Upstream dependencies

• s1_orbits: Already supports S1D via S1[ABCD] regex — no changes needed
• ISCE2: Requires S1D track number offset (42) in Sentinel1.py — see isce2#28123 (pending merge)

Notes

• S1D_MIN_DATE is a placeholder — update once S1D calibration is officially confirmed by ESA
• S1D orbit offset (42) is based on the commissioning orbit and may change when S1D moves to its final orbit (expected summer 2026)

[dbekaert]

ASF/DAAC Ingest Coordination
@asjohnston-asf — heads up on a potential ingest concern.

This PR adds "Sentinel-1D" (and "Sentinel-1C") to the platform enum in the producer-side DAAC ingest schema (daac_ingest_schema.json). When S1D products are generated, the JSON metadata will include "platform": ["Sentinel-1D", ...].

Question: Does ASF's receiving-side ingest validation / CMR collection configuration already support Sentinel-1D as a valid platform value? If not, S1D products would pass our local schema validation but could fail on ingest.

Specifically wondering about:

Server-side schema validation of the platform field
CMR collection metadata for the GUNW product suite
Any downstream search/discovery services that filter by platform

[dbekaert]

@cmarshak Can you keep an eye on this? We should do a test when the dependencies are ready.

[jhkennedy]

It appears ISCE2 is dead; see:
conda-forge/isce2-feedstock#86

Edit: looks like issues were just "temporarily" disabled due to spam:
isce-framework/isce2#28120

I have an open PR to the conda-forge recipe that will enable S1D support by patching the build (dirty):

So, if that PR is merged, DockerizedTopsApp could process S1D by changing the isce2 dependency in the environment file to:

- "isce2[version='==2.6.4', build_number='>=3']"

@cmarshak do you know the status of ISCE2? Any chance we could get S1D support merged and released?

[cmarshak]

I will have to ask - I have no idea. I don't think there is any active support of ISCE2.

[cmarshak]

I am manually adding in the file that @jacquelynsmale has in PR to ISCE2. I am hoping that this would be a temporary fix and then we can move forward more stably once the S1D pattern is officially released in ISCE2.

[cmarshak]

I am fine merging this as long as we agree to delete these lines once ISCE2 is released (would be separate PR):

DockerizedTopsApp/Dockerfile

Lines 36 to 39 in 5dc0498

	# TODO: Remove this when ISCE2 releases S1D Fixes
	RUN TARGET_DIR=$(conda run -n topsapp_env python -c "import isce; import os; print(os.path.dirname(isce.__file__))") && \
	curl -sSL -o "${TARGET_DIR}/components/isceobj/Sensor/TOPS/Sentinel1.py" \
	https://raw.githubusercontent.com/isce-framework/isce2/7bd57893ed9ae2d7ac0f7dd0e06625e337b0b993/components/isceobj/Sensor/TOPS/Sentinel1.py

[cmarshak]

Also, my understanding in talking with @mgovorcin is that S1D is "officially" calibrated, but the data doesn't look quite right yet.

[jhkennedy]

I released ISCE2 v2.6.5 with support for S1D and S1C post-orbit repositioning, and just merged the conda-forge PR.

So updating to v2.6.5+ should be all that's needed.

[cmspeed]

@jhkennedy and @cmarshak – Would it be possible to bump the ISCE2 version to v2.6.5 in the docker image so that S1D jobs can be deployed on HyP3? I'm happy to make the changes if that is helpful, but not entirely sure what is needed to cut a new docker image in this case.