Some burst border is larger than the actual coverage

[seongsujeong]

Checked for duplicates

Yes - I've already checked

Describe the bug

During the ANX testing, it was found that some bursts' border attribute has polygons protruding outside the area of the bounding box defined in burst DB. After investigation, I suspect some incorrect latitude / longitude values in geolocationGridPointList, from which Sentinel1BurstSlc.border is computed.
Below is the example data with issue.

SAFE: S1A_IW_SLC__1SDV_20200101T171339_20200101T171405_030610_0381C6_5514.zip
ORBIT: S1A_OPER_AUX_POEORB_OPOD_20210316T161714_V20191231T225942_20200102T005942.EOF
Burst ID: t088_186933_iw2. This is the 9th burst in the IW2 subswath in VV polarization.
Polarization: VV

Below is the plot of each burst borders in IW2 VV polarization. x / y values in the plot are longitude / latitude respectively. The burst mentioned above is labeled as 9 / 9, meaning that it is the 9th burst In the subswath.

Below is how the 9th border looks like when it is reprojected and overlaid on the corresponding bounding box. The red polygon is the burst border, and the blue one is the bounding box from burst DB.

Below is how the screenshot of the RTC product (VV pol.) suggesting that the coverage of the actual burst is well within the bounding box in burst DB.

What did you expect?

I think we need an algorithm to take care of the cases when incorrect longitude / latitude information in is in geolocationGridPointList. Also it would be necessary that any downstream workflows that make use of Sentinel1BurstSlc.border needs to be aware of this issue.

Reproducible steps

The test dataset mentioned above is available upon request.

Environment

- Version of this software [e.g. vX.Y.Z]
- Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
...

[seongsujeong]

The plot above is another type of case that SentinelBurstSlc.border gets protruded from the corresponding bounding box. Like mentioned above, the error in the polygon does not seem to affect the actual coverage of the SLC. However, the users who are making use of this polygon need to be aware of this issue.

[scottstanie]

At the suggestion of Piyush, we could use rdr2geo on some points to make a more-correct polygon:

import itertools
import subprocess
import sys
from pathlib import Path

import isce3
import numpy as np
import s1reader
from shapely import Point, Polygon

safename = (
    sys.argv[1]
    if len(sys.argv) > 1
    else "S1A_IW_SLC__1SDV_20200101T171339_20200101T171405_030610_0381C6_5514.zip"
)
# Download?
if not Path(
    "S1A_IW_SLC__1SDV_20200101T171339_20200101T171405_030610_0381C6_5514.zip"
).exists():
    subprocess.run(f"wget [https://datapool.asf.alaska.edu/SLC/SA/{safename}](https://datapool.asf.alaska.edu/SLC/SA/%7Bsafename%7D)")

orbit_file = s1reader.s1_orbit.get_orbit_file_from_dir(safename, ".")
burst = s1reader.load_bursts(safename, orbit_file, 2, burst_ids=["t088_186933_iw2"])[0]

r0 = burst.starting_range
r_end = burst.starting_range + burst.width * burst.range_pixel_spacing
ranges = np.linspace(r0, r_end, 20)

t0 = isce3.core.DateTime(burst.sensing_start) - burst.orbit.reference_epoch
t_end = isce3.core.DateTime(burst.sensing_stop) - burst.orbit.reference_epoch
times = np.linspace(t0.total_seconds(), t_end.total_seconds(), 10)

rdr_grid = burst.as_isce3_radargrid()
dop = 0.0
# Skip the DEM and use zero height. Could also just do DEM average height
dem = isce3.geometry.DEMInterpolator(0)
points = []
for t, r in itertools.product(times, ranges):
    llh = isce3.geometry.rdr2geo(
        t,
        r,
        burst.orbit,
        rdr_grid.lookside,
        dop,
        rdr_grid.wavelength,
        dem,
    )
    points.append(Point(np.degrees(llh[0]), np.degrees(llh[1])))

border_polygon = Polygon(points).convex_hull
print(border_polygon.wkt)