search

relativeorbit / fufiters

run hyp3-isce2 via github actions
MIT License
2 stars 0 forks source link

Incorrect TANX times in SLC metadata results in incorrect bursts processed #3

Open scottyhq opened 6 months ago

scottyhq commented 6 months ago

The code here https://github.com/relativeorbit/hyp3-isce2/blob/944794013abe607be8e8689293f55f1864443282/src/hyp3_isce2/burst.py#L452-L460

Assumes that the S1 Burst Database the time elapsed from ascending node crossing (TANX) closely matches TANX per burst in the S1 SAFE xml annotation file. Each burst in a subswath has ~3s of separation, so we assume these metadata values are precise to ~1s to correctly identify a burst. This issue is documented extensively here https://github.com/isce-framework/s1-reader/issues/117

(The chosen solution in s1-reader was instead of reading tanx in the xml metata, the correct tanx per burst is computed from precise orbit files)

A misidentification case:

python -m hyp3_isce2 ++process insar_tops_fufiters \
    S1A_IW_SLC__1SDV_20200112T114125_20200112T114152_030767_038742_F6E2  \
    S1A_IW_SLC__1SDV_20200124T114124_20200124T114151_030942_038D66_CCA0  \
    --burstId 070_148383_IW1 \
    --polarization VV \
    --looks 5x1 \
    --apply-water-mask False \
    --offsets False
scottyhq commented 6 months ago

S1_reader is a pretty heavy dependency since it requires full SLCs and requires isce3 since it is setting up opera burst processing.

If I understand correctly, the code figures out the correct ascending node time from either SLC metadata (based on estimated orbit) or external more precise orbit files https://github.com/isce-framework/s1-reader/blob/bb585c77ee538324212085f4737f3d2d534ac998/src/s1reader/s1_reader.py#L549 . Then computes ESA burstID based on a formula with burst sensingTimes (https://github.com/isce-framework/s1-reader/blob/bb585c77ee538324212085f4737f3d2d534ac998/src/s1reader/s1_burst_id.py#L19)

For this project, the approach is different, matching the ESA database TANX with closest burst TANX in the SLC metadata. Turns out sometimes the TANX per burst in the SLC metadata is relative to the last orbit, so an easy fix is to adjust by the orbital period for that case:

        <azimuthTime>2024-01-15T11:41:50.791766</azimuthTime>
        <azimuthAnxTime>6.389039610552900e+03</azimuthAnxTime>
        <sensingTime>2024-01-15T11:41:51.898668</sensingTime>
        <byteOffset>129383331</byteOffset>
        <burstId absolute="111941577">148376</burstId>

T_ORBIT = (12 * 86400.0) / 175.0 = 5924s Note 6389s > T_ORBIT

fixed by https://github.com/relativeorbit/hyp3-isce2/pull/1

Leaving this issue open though for awareness because there might be other mis-matched bursts with our current approach...