Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Use Cases

  • which steps are automated/what trigger rules do we need to add?

    • Identify production rule(s)

  • Solidify use cases - how will the user interact with this pipeline/process?

  • What is the operational difference between setting an AOI upon creation to either “monitoring” or “landslide”? (this goes for other natural disaster types as well, volcano, earthquake, etc)

Use Case 1: System continues forward “keep-up” production of SLC for landslide AOI.

  • User adds an AOI to the system to keep up processing on , and sets the type of AOI as “landslide”.

  • System automatically processes to SLCs upon new data acquisitions in AOI and publishes to S3.

Use Case 2: System continues forward “keep-up” production of S1-GUNW for landslide AOI.

  • User adds an AOI to the system to keep up processing on, and sets the type of AOI as “landslide”.

  • System automatically processes to L2 S1-GUNW upon new acquisitions in AOI and publishes to S3.

Use Case 3: System monitors specific areas of interest to detect potential landslide anomalies, using higher resolution time series.

  • User adds an AOI to the system to keep up processing on , and sets the type of AOI as “landslide”.

  • System automatically creates coregistered SLC stacks upon new data acquisition in the AOI.
    Note to Developer: Will need to add trigger rule upon SLC acquisition to send SLC stack (along with the corresponding “bbox”) through the TopsStack Processor PGE.

  • System automatically performs PS time series processing on SLC stack.
    Note to Developer: Will need to add trigger rule upon publishing of TopsStack Processor PGE output to send that output through StaMPS PGE.

  • System automatically applies ML to detect potential anomalies, and publishes results back to GRQ catalog
    Note to Developer: Will need to add trigger rule for this.

  • User logs into system to browse potential anomalies.

Use Case 4: System monitors specific areas to detect potential landslide anomalies, using lower resolution time series

  • User adds an AOI to the system to keep up processing on , and sets the type of AOI as “landslide”.

  • System automatically processes to L2 S1-GUNW upon new data acquisition in the AOI.
    Note to Developer: Will need to add trigger rule.

  • System automatically performs displacement time series processing on S1-GUNWs.
    Note to Developer: Will need to add trigger rule.

  • System automatically applies ML to detect potential anomalies, and publishes results back to GRQ catalog
    Note to Developer: Will need to add trigger rule for this.

  • User logs into system to browse potential anomalies.

Use Case 5: System monitors widespread areas to detect potential landslide anomalies in areas not being closely monitored.

Use Case 6:

Use Cases 5 and 6 may not be feasible within the current time frame, and can be considered future possible work.

Still need to add trigger rules for this, it’s still currently all only On-Demand.

Pipeline

The landslide anomaly detection pipeline in the figure above has two possible roots. The first, outlined by the light blue dashed line, stems from the portion of the Standard Product Pipeline similarly outlined. This option uses higher resolution time-series data generated from coregistered SLC stacks via StaMPS PS time-series processing. The second option, outlined by the dashed red line, comes from L2 S1-GUNW data products, indicated by similar red outline on the Standard Product Pipeline figure. The GUNW products are run through the MintPy PGE, and create a lower resolution displacement time-series.

For the higher resolution option, the user can select an SLC track to push through the ISCE TopsStack PGE to create a coregistered SLC stack, by searching facets (SLC, track number, region) on Tosca. The stack is then the trigger for the StaMPS (Stanford Method for Persistent Scatterers) PGE. StaMPS publishes the persistent scatterers time-series (PS time-series). The publishing of the PS time-series triggers the Tensorflow Predictor, which publishes a Landslide Anomaly Map.

For the lower resolution option, the user can define an AOI track. When the AOI track evaluator determines that the full track has been processed, it publishes a JSON file that triggers the MintPy PGE to run. The MintPy PGE then publishes a displacement time-series, which triggers the Tensorflow Predictor PGE to run and publish a Landslide Anomaly Map.

For either option, the Landslide Anomaly Map is then run through the TBD “Production Rules for Detected Anomalies” PGE. If the map contains (TBD) value over (XX) threshold, then (something happens; probably notify the user who submitted the job).

TopsStack Processor (TopsStack Processor (PGE))

Description: Creates a coregistered stack of SLCs, only within the same track over a time period

Trigger dataset/action: On-demand Action “topsStack Processor”

Inputs: SLC (facet to this via “track number”, “SLC”, “region” on Tosca. Must have only one track in SLC input), master date, and bbox (min_lat, max_lat, min_lon, max_lon) (bbox is required in multiprocessing and optional in GNU Parallel)

Outputs: directory containing coregistered SLC stack, merged geometric data, baselines, etc. More in depth description of output directory can be found on https://aria.atlassian.net/wiki/spaces/ARIA/pages/19791873/TopsStack+Processor+PGE#Output-directory-structure.

StaMPS PGE (ISCE to StaMPS PS Time Series Processing (PGE))

Description: Takes output of TopsStack Processor as input, and calculates a time series using the Persistent Scatterers method.

Trigger dataset/action: On-demand Action “ISCE STAMPS PS Processing”

Inputs: output directory from TopsStack Processor (containing SLCs, geom_master, and baselines); also need to input the following upon On-Demand job submission:

  1. range_looks

  2. azimuth_looks

  3. aspect_ratio

  4. lambda

  5. amplitude_dispersion

  6. number_patches_range

  7. number_patches_azimuth

  8. overlapping_pixels_range

  9. overlapping_pixels_azimuth

Outputs: PS time-series (output directory structure shown on https://aria.atlassian.net/wiki/spaces/ARIA/pages/25067521/ISCE+to+StaMPS+PS+Time+Series+Processing+PGE#Running-Hello-World-(HySDS); step number eight)

MintPy PGE

Description: Takes S1-GUNWs from a specific AOI track and calculates the displacement time series.

Trigger dataset/action: On demand Action “MintPy (SNWE Bounds)”, or trigger on output of AOI track enumerator

Inputs: latitude_longitude_bounds, track_number, start_date, end_date

Outputs: Displacement time-series (timeseries.h5, velocity.h5, maskTempCoh.h5)

Tensorflow Predictor PGE

Description: Takes either PS time series or MintPy time series, and calculates

Trigger dataset/action:

Inputs: Either all PS time series for a given location, or the MintPy time series (timeseries.h5, temporalCoherence.h5) )for a given location

Outputs: predicted landslide anomaly data (.pred files)

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.