opera-adt / burst_db Goto Github PK

The function in the title is to calculate the extent (bounding box) of the input burst as polygon. This function only takes the first polygon in the multi polygon input. This needs to be addressed especially for the burst (multi)polygons split on +/- 180 degree.

Checked for duplicates

Yes - I've already checked

Alternatives considered

Yes - and alternatives don't suffice

Related problems

The PR #8 includes land optimization for frame definition. It uses several reference shape files to identify the land area.
One of the reference data for the land area is Global Self-consistent, Hierarchical, High-resolution Geography (GSHHG) Database. This database includes Antarctica. based on grounding line boundary. However, in general glaciologists in Antarctica are interested not only grounded ice but also the ice ice shelf (downstream of the grounded ice that floating on, and flows into the ocean)

For OPERA project, using this reference data for Antarctica would suffice because the project does not cover Antartica. However, in case CSLC and COMPASS gets extended to Antarctica, the frame definition for this area might not be in a desired set up.
Therefore, the reference shape file for Antarctica needs to include ice shelf. It would be in lower priority than other tasks, but it needs to be in our TODO list.

Describe the feature request

• Search for reference data for Antarctica's coastline that includes ice shelves.
• Update the frame definition code to make use of the new reference data for Antarctica.

Checked for duplicates

Yes - I've already checked

Describe the bug

One of the points discussed in the PR #2 was about the across-track constraint of EPSG, which is to use the same map projection for the IW1/2/3 bursts on the same track. The reason behind this constraint is to make the along-track bursts more stitch-friendly (i.e. no reproduction necessary). One of the concerns that has been made was that it might cause the EPSG changes along-track to be less related to what it is across track.

One of the ways to investigate the influence of the EPSG constraint is to detect the number of EPSG changes along track from the DB generated with / without the constraint.

What did you expect?

1. Get the DB with the across-track EPSG constraint
2. Get the DB without the across-track EPSG constraint
3. Follow the data along track and detect the EPSG change
4. Compare the number

Reproducible steps

No response

Environment

No response

It's like that the displacement product is going to have a spacing of 30 meters. This means it's nice if the snap used in setting the bounding box is some multiple of 30. That way, adjacent bursts will line up in an even multiple, rather than one burst intersecting at some fraction of a 30m pixel.

Checked for duplicates

Yes - I've already checked

Describe the bug

With the options snap=50, margin=1000, some of the bursts work alright when processed through COMPASS.

However, here's 3 dates of burst t012_024524_iw2 with that margin:

Checking into why this might happen, the README of the ESA burst database has the following validation table:

...each of the geocoded point obtained from the annotation files is
coupled to the corresponding point from the Burst ID map. For each couple of
points the absolute distance, the distance along range, and the distance along
azimuth are computed. The results of the validation are as follows:.
For the IW Burst ID map (validation over 6600 products):

The key point: there was a -3127 difference between their burst database geometry and the actual location of one of the acquired bursts.

What did you expect?

One fix might be to use 4000 for the default margin, as is in #2 .

Reproducible steps

No response

Environment

No response