Output name errors when saving SNAP files for PyRate

s1tbx PyRate
#1

I’m trying to save SNAP files into PyRate format (SNAP v8), however there appears to be a problem with the output file names. I’ve tried using the GUI and gpt xml processing options.

input dim: 20201209_20201221_unw_tc.dim
save as: ‘Gamma for PyRate’

The results of the graph built by the GUI is attached.

but the outputs are:

  • 20190419_slc.par
  • 20190407_slc.par
  • Unw_Phase_ifg_21Dec2020_09Dec2020_VV_20190419-20190407.rslc

I used the GUI graph as the basis for the gpt xml script but I get the same outputs.

The output name I select is also ignored and the above *.rslc filename is produced. It looks like part of the default output name is linked to the *.img file instead.

The *_slc.par files should represent the two dates of the input dim, not the reference pair (20190407-20190419).

When looking at the PyRate documentation (https://geoscienceaustralia.github.io/PyRate/usage.html#configuration), it states that the naming convention required. Based on this the outputs for the above example should be:

  • 20201209_slc.par
  • 20201221_slc.par
  • 20201209-20201221.unw

Also, when the coherence file is processed (eg. 20190817_20190910_coh_tc.dim), it should have the output of 20201209-20201221.coh, instead the results are:

  • 20190419_slc.par
  • 20190407_slc.par
  • coh_VV_10Sep2019_17Aug2019.rslc

Can someone please check to see if this is a bug in SNAP?

Thanks

gui_graph.txt (596 Bytes)

#2

@mcvittal do you have an idea?

#3

Your graph has: <formatName>Gamma for PyRate</formatName> but formatName should be one of the supported file formats. In the Graph Builder “Save as” should provide a pull-down list of available formats below
the “name” box where you can enter a name for the “target” file.

On the command-line, gpt Write -h provides a sample graph with the following block:

   <parameters>
        <file>file</file>
        <formatName>string</formatName>
        <deleteOutputOnFailure>boolean</deleteOutputOnFailure>
        <writeEntireTileRows>boolean</writeEntireTileRows>
        <clearCacheAfterRowWrite>boolean</clearCacheAfterRowWrite>
      </parameters>
#4

Thanks, this is a new supported format that was released in v8 and it does appear in the pull-down list of available formats.

#5

@ABraun @mcvittal Any ideas on this problem?

#6

Hi Sarah, I tried to use Pyrate together with SNAP including the Gamma for Pyrate format conversion tool myself in gpt.
It is available since SNAP 8.0, but the available tool has still some bugs not fixed yet. Probably, because not many have used it so far.

The coherence file naming convention is one of them. You have to change them manually.
Besides some variable names in the txt files are missing or not correct.
However, using the file format .rslc is working in pyrate, you just need to adapt the input file list accordingly.

As you probably already know, documentation for pyrate can be found here (but unfortunately it is not very detailed…):

#7

Thanks, I thought this might be the case but wasn’t sure if the format of the image files were also modified correctly to suit PyRate. I’m familiar with PyRate’s workflow but as you say the documentation could be better.

#8

Does anyone have the full steps on how to prepare data for PyRate in SNAP?

#9

we hope to release a tutorial on this in the nearer future - but unil then, it would be nice if someone who managed to use the PyRate export of SNAP could share some experiences.

#10

I have tried that and can give you a list of steps needed to make the Pyrate workflow running:

  1. Export the unwrapped phase dim-files with coherence as GAMMA FOR PYRATE file
  2. Export the used DEM in a separate file as GAMMA file
    !It is very important that all files have the same raster extent (same no of rows & cols)!
  3. Change the coherence file name endings, so that Pyrate recognizes the dates (e.g. 20201209-20201221.coh)
  4. open the elevation header file (e.g. elevation.par) and change or insert the following variables:
  • replace variable name ‘range_samples’ with ‘width’
  • replace variable name ‘azimuth_lines’ with ‘nlines’
  • insert variables ‘corner_lat’, ‘corner_lon’, ‘post_lat’ and ‘post_lon’
  • and enter the fitting parameters accordingly: y_origin, x_origin, y_resolution and x_resolution
  • enter information about the geodetic datum. example from pyrate:

‘ellipsoid_name: WGS 84\n’,
‘ellipsoid_ra: 6378137.000 m\n’,
‘ellipsoid_reciprocal_flattening: 298.2572236\n’,
‘\n’,
‘datum_name: WGS 1984\n’,
‘datum_shift_dx: 0.000 m\n’,
‘datum_shift_dy: 0.000 m\n’,
‘datum_shift_dz: 0.000 m\n’,
‘datum_scale_m: 0.00000e+00\n’,
‘datum_rotation_alpha: 0.00000e+00 arc-sec\n’,
‘datum_rotation_beta: 0.00000e+00 arc-sec\n’,
‘datum_rotation_gamma: 0.00000e+00 arc-sec\n’,
‘datum_country_list Global Definition, WGS84, World\n’

  1. adjust the parameters & the used files in ifgs.txt, … accordingly in the pyrate configuration file ‘input_parameters.conf’.

I cannot guarantee, that this list is complete. I’m currently working on a script to automatize the whole process. It already works on my system and I can generate some nice results. However, it still needs some debugging…

3 Likes
Comparative analysis between stamps and PyRate
SBAS-InSar processing in SNAP
#11

thank you for sharing! We hope we can release some official guidelines on the PyRate export soon.

#12

Is this data terrain corrected? Should I assume that it goes through the usual preprocessing steps? i.e.:

  1. Apply Orbit
  2. TOPSAR Split
  3. Backgeocoding
  4. Interferogram
  5. Deburst
  6. Topophase Removal
  7. Multilook
  8. Filter
  9. SNAPHU Export
  10. Unwrapping
  11. SNAPHU Import
  12. Terrain Correct
  13. Save DEM as GAMMA; Save Unw phase, coherence as GAMMA for PyRate

I am planning on creating a script to test the workflow.

3 Likes
#14

Hi @SebBuchelt ,

Did you have the chance to write the script to automate the whole process for preparing data with SNAP for use in PyRate? I would be quite interested to use it ^^

This process assumes interferograms that were generated manually for each pair? Or it can also work with interferograms generated with the ‘Multi reference InSAR’ operator of SNAP?

Thanks