Burst inconsistency when unpacking scenes across dates of stack about isce2

[shitong01]

FYI, a temporary resolve we made for this is in extract_stack_valid_region through editing extractCommonValidRegion.py, where it identifies the common bursts between master-slave date pairs for run_6_merge to include after coregistration. However, the current implementation decides the bounds for extraction based on overlaps of each local master-slave pair and does not do it globally (slave-slave) for all dates across the whole stack.

Edited extractCommonValidRegion.py:
https://github.com/earthobservatory/isce2/blob/d3ae179f05d9f3f625dd60e45870ccdd63acb087/contrib/stack/topsStack/extractCommonValidRegion.py

Diffs:
https://github.com/isce-framework/isce2/compare/v2.3.3...earthobservatory:gekko-stack-processor?expand=1#diff-6e3ba28d77dfe64d6eba790b5577f105

^ This change checks for and only includes valid common overlap bursts amongst all dates (Globally) and creates metadata that is used for merging the valid selection in run_6_merge.

[piyushrpt]

The solution you present to handle it during merging is a good one. I would make that an option as described later.

From the plots, the bounding box does exactly what it is supposed to do - cover the area that was requested completely; so things are working as expected. The issue you bring up is more of a convenience.

There are 2 options:

1. The issues you are pointing out can be managed entirely by setting up the right bbox to begin with. This is probably best handled as a pre-processing option that refines the bbox rather than complicating the workflows. From the screenshots, it is clear that if the bbox was setup right - this issue would not have occurred. I would recommend just making these kinds of plots right up front, which ISCE's sentinel-1 parser allows you to easily do and then refine the bbox before deploying the stack processing.

This should probably be done all the time- the same case can occur with a single burst showing up in another swath in some scenes - say at the east/west edge like the one you pointed out earlier - http://earthdef.caltech.edu/boards/4/topics/3283?r=3289#message-3289? There are tools like plotBursts.py which have all the components needed to put together such a preprocessing tool. We often just do this manually for a date, and draw the bbox such that the edges are not too close to the burst boundaries and also pick desired swaths. However, this can be easily automated as well. You only need the annotation files for doing this. It would be even better, if you contribute back such capability.

2. The second option is what you present which is also a good one. You are probably working in regions with consistent coverage and have small regions of interest. For larger and wider area stacks over Asia / S America / Africa, the chances of having inconsistent spatial coverage is high and users would want to get as much coverage as possible and handle missing data at the time-series stage. Reference date is typically picked with best spatial coverage and all other images are coregistered to it with slices missing at the top and bottom. I would say that the easiest thing to do would be able add global common bursts as an option for extracting valid region but not make it mandatory as there are other use cases where that behavior is not desired.

[jdmillstein]

Hi - I am having this exact issue but the modification of [extractCommonValidRegion.py] doesn't render a fix. Do you have any other suggestions, as my bounding box is at a really weird angle to form a good bbox.