You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]
...
The text was updated successfully, but these errors were encountered:
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.
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 ingeolocationGridPointList
, from whichSentinel1BurstSlc.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 ofSentinel1BurstSlc.border
needs to be aware of this issue.Reproducible steps
The test dataset mentioned above is available upon request.
Environment
The text was updated successfully, but these errors were encountered: