Update orbit file search to return an ANX-inclusive result

[forrestfwilliams]

Notable potential users of this API (the OPERA project and other users working with ISCE3) need their orbit files to include the ascending node crossing time to perform certain data corrections. The ascending node crossing time is the time at which the satellite platform crosses the equator from the southern to northern hemisphere. See here for the s1-reader implementation of this requirement.

In the absence of any other conflicting date range requirements, we should make returning an orbit that includes the ascending node crossing time a base requirement for the API.

[asjohnston-asf]

Two concerns:

1. I haven't heard an explanation for why ISCE3 requires the anx crossing time, where no other app I'm aware of does.

2. For recently-aquired granules for which only RESORB orbits are available, it's not always possible to find a single RESORB file that encompasses both the acquisition time and the anx crossing time.

   For example, as of 2025-05-23, the production implementation returns results for these scenes, but the proposed implementation fails to find any result. Total of 38 failures of 1043 total scenes acquired on 2025-02-20.

   S1C_WV_SLC__1SSV_20250519T235828_20250520T001156_002406_0050D0_9B31
   S1A_WV_SLC__1SSV_20250520T004258_20250520T010346_059270_075AF3_0DE2
   S1C_WV_SLC__1SSV_20250520T013042_20250520T014805_002407_0050D9_3C3E
   S1A_WV_SLC__1SSV_20250520T022018_20250520T025318_059271_075AFF_DB2B
   S1C_WV_SLC__1SSV_20250520T030835_20250520T032656_002408_0050DE_026A
   S1A_WV_SLC__1SSV_20250520T035958_20250520T042214_059272_075B08_C6DA
   S1A_WV_SLC__1SSV_20250520T055254_20250520T061115_059273_075B10_C1FD
   S1A_WV_SLC__1SSV_20250520T073337_20250520T074636_059274_075B1B_910F
   S1C_S6_SLC__1SDV_20250520T082242_20250520T082259_002411_0050EA_8059
   S1A_IW_SLC__1SDV_20250520T091235_20250520T091303_059275_075B28_CBEF
   S1A_IW_SLC__1SDV_20250520T091301_20250520T091328_059275_075B28_314E
   S1A_IW_SLC__1SDV_20250520T091326_20250520T091343_059275_075B28_153A
   S1A_WV_SLC__1SSV_20250520T091433_20250520T092042_059276_075B29_9CE2
   S1C_IW_SLC__1SDV_20250520T113958_20250520T114028_002413_0050F8_F584
   S1C_IW_SLC__1SDV_20250520T114026_20250520T114053_002413_0050F8_2F42
   S1C_IW_SLC__1SDV_20250520T114051_20250520T114118_002413_0050F8_CFDF
   S1C_IW_SLC__1SDV_20250520T114116_20250520T114143_002414_0050F8_F7CB
   S1C_IW_SLC__1SDV_20250520T114141_20250520T114218_002414_0050F8_34B2
   S1A_WV_SLC__1SSV_20250520T121418_20250520T123506_059277_075B3C_BBF8
   S1C_WV_SLC__1SSV_20250520T130308_20250520T132327_002414_0050FE_486F
   S1A_WV_SLC__1SSV_20250520T135732_20250520T141426_059278_075B46_021C
   S1C_IW_SLC__1SDV_20250520T145915_20250520T145946_002416_005104_96CD
   S1A_IW_SLC__1SDV_20250520T154757_20250520T154825_059279_075B4E_4F2D
   S1A_IW_SLC__1SDV_20250520T154823_20250520T154850_059279_075B4E_0E20
   S1A_IW_SLC__1SDV_20250520T154848_20250520T154915_059279_075B4E_3B74
   S1A_IW_SLC__1SDV_20250520T154913_20250520T154940_059280_075B4E_2A76
   S1A_IW_SLC__1SDV_20250520T154937_20250520T155004_059280_075B4E_4A10
   S1A_IW_SLC__1SDV_20250520T172809_20250520T172839_059281_075B57_2D95
   S1A_IW_SLC__1SDV_20250520T172837_20250520T172905_059281_075B57_7811
   S1C_WV_SLC__1SSV_20250520T175953_20250520T181519_002417_005111_6DB9
   S1C_IW_SLC__1SDV_20250520T181546_20250520T181617_002417_005112_544A
   S1C_IW_SLC__1SDV_20250520T181615_20250520T181642_002418_005112_A810
   S1C_IW_SLC__1SDV_20250520T181640_20250520T181707_002418_005112_ECEF
   S1A_WV_SLC__1SSV_20250520T184800_20250520T190621_059281_075B61_E299
   S1A_IW_SLC__1SDV_20250520T190648_20250520T190718_059282_075B62_C5A6
   S1A_IW_SLC__1SDV_20250520T190716_20250520T190744_059282_075B62_59C2
   S1A_WV_SLC__1SSV_20250520T204517_20250520T205817_059282_075B6F_1D9F
   S1A_WV_SLC__1SSV_20250520T235225_20250521T000426_059284_075B7D_46F2
   

[jhkennedy]

I haven't heard an explanation for why ISCE3 requires the anx crossing time, where no other app I'm aware of does.

Here's the reason given for S1Reader in this comment:

s1-reader computes it's own "ESA Burst ID"; to do that, you need the previous ascending node crossing time. This is never a problem for Precise orbits (which are 24 hours long). But the issue describes the annoying edge case where the sensing times can fall right on an edge case, and this significantly complicated the orbit selection logic.

I believe he's referring to this issue resolved by this PR (with more discussion).

For recently-aquired granules for which only RESORB orbits are available, it's not always possible to find a single RESORB file that encompasses both the acquisition time and the anx crossing time.

Yeah, that's a problem for scene name -> download for sure.

[asjohnston-asf]

s1_reader has an implementation to deal with the RESORB issue, but that's a bit more complicated and bespoke than the simple 80-20 use case s1-orbits was designed to handle

[jhkennedy]

s1_reader has an implementation to deal with the RESORB issue, but that's a bit more complicated and bespoke than the simple 80-20 use case s1-orbits was designed to handle

The s1-reader implementation is pretty much a drop-in replacement that gets you the anx crossing time included:

-    orbit_file = s1_orbits.fetch_for_scene(scene_name)
+    orbit_file = s1_reader.s1_orbit.retrieve_orbit_file(scene_name, orbit_dir='.', concatenate=True)

I personally would be fine closing this and the corresponding issue as a "won't do" and pointing people to the s1-reader implementation for ISCE3-based workflows.