Workflow between SNAP and StaMPS

@katherine I’m getting the following output for step 2:


On a different note, I don’t know why but I’m getting a lot of PS.
I’m using 0.2 as amplitude dispersion threshold, when I should use 0.4, and my PS velocity map (ps_plot(‘v’)) has the following look:


Even for water surfaces I’m getting a lot of PS (blue triangle at the lower left corner of the map). It doesn’t make sense.

Are you getting similar results?

Dear juanesburgo,
My results are even worse than yours.
1/ I have noticed that the content of ALL files .par in both /diff0 and /rslc directories (having normal different names) is the same - it is just master.rslc.par file in reality.
2/ Data values in these files are also very strange. For example, heading for ascending S-1 is 106 degrees… ? (Instead of approx. 356 degrees…), radar frequency 5405 Hz. It seems to be not Hz but MHz, otherwise lambda in StaMPS is absolutely not correct)

You managed to get n_trial_wraps not zero in STEP 2 StaMPS and also just normal value of lambda! Do you use Sentinel or Envisat images?
Katherine

I’m using S-1 images.
Have you already updated SNAP?
When you go to Help->About SNAP…->S1TBX which version does it appear? Is it 5.0.0 or 5.0.1?

Thank you juanesburgo! I will try again!
Katherine

How did you get that geocoding? Or don’t you use Sentinel-1 data? All I can get is stretched image, without any position information.


If I export those points to Google Earth, then they are located somewhere near 0, 0 coordinates.

Also, even after update, topo-phase removal doesn’t work. Problem is the same. During step 3 unnaturally huge amount of scatterers is found, which is completely filtered out during step 4.

It’s hard to explain how I did but I will try my best!

  1. I did the update geo reference in SNAP.
  2. I ran mt_prep_gamma
  3. On matlab I loaded the latitude and longitude bands that I got in 1) and loaded the pscands.1.ij file that I got in 2)
  4. Based in ij coordinates I created a lonlat variable from longitude and latitude bands
  5. Then I modified ps_load_initial_gamma.m in order to read my lonlat variable

Yes, I have the same problem. I continue to have to modify the name of the bands i and q as @lveci has sugested above!

  1. How many S-1 images does your stack have?
  2. Could you show your parameters list (getparm)?

Do you rename them in file system, or using SNAP?

I have 20 slave images.
Here is my parameters. Right now almost everything except ‘unwrap_gold_n_win’ is left as default.

                      Created: '27-Dec-2016'
                   clap_alpha: 1
                    clap_beta: 0.3000
     clap_low_pass_wavelength: 800
                     clap_win: 32
                 density_rand: 20
               drop_ifg_index: []
             filter_grid_size: 50
             filter_weighting: 'P-square'
     gamma_change_convergence: 0.0050
           gamma_stdev_reject: 0
                      heading: 250.8561
              insar_processor: 'gamma'
                       lambda: 0.0555
                lonlat_offset: [0 0]
                 max_topo_err: 5
          merge_resample_size: 0
           merge_standard_dev: Inf
                 percent_rand: 20
            plot_color_scheme: 'inflation'
             plot_dem_posting: 90
        plot_pixels_scatterer: 3
          plot_scatterer_size: 120
         quick_est_gamma_flag: 'y'
            ref_centre_lonlat: [0 0]
                      ref_lat: [-Inf Inf]
                      ref_lon: [-Inf Inf]
                   ref_radius: Inf
                  scla_deramp: 'y'
              scla_drop_index: []
                  scla_method: 'L2'
               scn_deramp_ifg: []
                 scn_time_win: 365
               scn_wavelength: 100
                select_method: 'DENSITY'
              shade_rel_angle: [90 45]
                      slc_osf: 1
          small_baseline_flag: 'n'
                  subtr_tropo: 'n'
                 tropo_method: 'a_l'
                 unwrap_alpha: 8
            unwrap_gold_alpha: 0.8000
            unwrap_gold_n_win: 16
             unwrap_grid_size: 200
         unwrap_la_error_flag: 'y'
                unwrap_method: '3D'
           unwrap_patch_phase: 'n'
        unwrap_prefilter_flag: 'y'
unwrap_spatial_cost_func_flag: 'n'
              unwrap_time_win: 730
               weed_max_noise: Inf
              weed_neighbours: 'y'
            weed_standard_dev: 1
                weed_time_win: 730
          weed_zero_elevation: 'n'
1 Like

Using SNAP. It’s the safest way, I think!

Like me. I also had to change that parameter.
I never studied that step. Do you have a reason to choose 16 or it was by chance?

Then SNAP already renames all i and q bands itself

I had this error message during Step 6 :
Minimum dimension of the resampled grid (17 pixels) is less than prefilter window size (32). So according to one mainsar forum topic I have changed the value to 16.

Dear Jaroslav and juanesburgo,
I managed to fulfill export to StaMPS when I re-run again Interferogram formation and TopoPhaseRemoval for the whole co-registered stack. It is not long.
But I still have the problem with the exported data. Below are the values which are imported by StaMPS. Heading is definitely wrong. Moreover look angles are not imported… Could you, please, send me your screen of Step 1 of StaMPS? Or probably you can give me any advise.
Thank you for your time
Katherine

jaroslav
December 28
juanesburgo:

Using SNAP. It’s the safest way, I think!
Then SNAP already renames all i and q bands itself
juanesburgo:
Do you have a reason to choose 16 or it was by chance?
I had this error message during Step 6 :
Minimum dimension of the resampled grid (17 pixels) is less than prefilter window size (32). So according to one mainsar forum topic I have changed the value to 16.


Visit Topic or reply to this email to respond.

In Reply To
juanesburgo
December 28
Using SNAP. It’s the safest way, I think!

Like me. I also had to change that parameter. I never studied that step. Do you have a reason to choose 16 or it was by chance?


Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here .

All the best,
Katherine

How did you import hdr files into matlab? hdrread function didn’t work for me.

Did you change ijname=['pscands.1.ij']; line to ijname=['lonat.1.ij'];?

I didn’t get this kind of error, but for some reason your pscands.1.ij file is empty. I didn’t find, why can it come out like this though.

Dear Jaroslav,
Thank you very much for your comments, I have not noticed that this time pscands.1.ij are empty. Before updating it was OK. And the same question about heading - did you manage to get normal heading value for S-1 in Step 1 StaMPS?
Thank you for your time
Katherine

Hi all,
Maybe this helps, small Andy Hooper tutorial for Sentinel-1, he use different software for interferogram generation but also pointed out if we can export to StaMPS, this should work
http://seom.esa.int/landtraining2015/files/Day_4/D4P2a_LTC2015_Hooper.pdf
I hope it will help to correctly set the parameters
Best regards, Stanislav

You can read those files as ENVI files. There is matlab code to do that out there.

No, I didn’t.
I did this:

if exist(llname,'file')
  fid=fopen(llname,'r');
  lonlat=fread(fid,[2,inf],'float',endian);
  lonlat=lonlat';
  fclose(fid);
else
  load('~/lonlat.mat');
  %lonlat=local2llh(xy'/1000,[0;0])';
end

my modified code is between else and end.

Thank you very much Stanislav !
All the best
Katherine

Hi @ABraun ,
I started using the workflow between SNAP and stamps and I am currently facing the same problem as you did last month, namely that " Error opening file pscands.1.ij" message in the end of the mt_prep_gamma step. Did you by chance solve this problem?
Cheers,
Maryse

unfortunately not. Do you work on windows or linux?

I work on a Linux machine.
I think, that maybe the problem is due to this spelling error:


file name for zero amplitude PS: pscands.1.ij0


instead of pscands.1.ij
I think that the problem lies within the selpsc_patch script. I will try to get more information in the mainsar forum.
Maryse

alright, at least it is not platform-related.

You could be right about the variable pscands.1.ij0
But strange that it only happened to us… Please let me know if you receive an answer in the mainsar forum.