mai about gmtsar

[Xiaohua-Eric-Xu]

Try MAI_processing.csh, or if you are an experienced user, run split_aperture.

[KIKINEO]

Try MAI_processing.csh, or if you are an experienced user, run split_aperture.

Dear Professor Xu, thank you for providing the program MAI_processing.csh. I have tried to use it recently and got some results. I have some questions and would like to seek your advice.

1. According to my understanding, does this program only process a single strip? My usage is to run this program under each F1F2...strip folder after the processing of the double gauge difference. Is the usage correct?

2. Through the above steps, I finally obtained the results of each band and displayed them on Google Earth, as shown in the figure below. Is the obvious band color jump because the cpt of each sub-strip is different?
   

3. Another very important question is how to splice the data processed by MAI_processing.csh, I am looking forward to your reply, thank you very much~ @Xiaohua-Eric-Xu

[Xiaohua-Eric-Xu]

Do note MAI measures any type of mis-registration. It could be from 1) real azimuthal motion, 2) error due to inaccurate orbit or xcorr solutions; or 3) ionospheric distortion. For such errors, a simple way is to figure out the jump between the subswaths and shift then paste them together. After that, you could further remove a trend to flatten the results (exclude the deformation area due to the earthquake). Or you could chose to correct every error source but that requires some further understanding of the correction methods and GMTSAR code/scripts. Also, sometimes the strong shift from earthquakes could bias coregistration.

[KIKINEO]

Do note MAI measures any type of mis-registration. It could be from 1) real azimuthal motion, 2) error due to inaccurate orbit or xcorr solutions; or 3) ionospheric distortion. For such errors, a simple way is to figure out the jump between the subswaths and shift then paste them together. After that, you could further remove a trend to flatten the results (exclude the deformation area due to the earthquake). Or you could chose to correct every error source but that requires some further understanding of the correction methods and GMTSAR code/scripts. Also, sometimes the strong shift from earthquakes could bias coregistration.

Thank you very much for your reply. Forgive me for my shallow understanding of the source of the error. As you mentioned, find out the jumps between the strips and paste them. I still don’t know enough about this work. I can ask you to give me some information. Specific method and example steps?
Whether the job of creating paste is done by this commandgmt grdpaste But when I try it always showsgrdpaste [ERROR]: Grids do not share a common edge!

[Xiaohua-Eric-Xu]

You could use merge_swath and correct_merge_offset.csh. Though I wrote the script but I never really tried this before so could not guarantee a good solution. Do note merge_swath takes in 3 at a time so for ALOS2 you may need to run it twice.

[KIKINEO]

You could use merge_swath and correct_merge_offset.csh. Though I wrote the script but I never really tried this before so could not guarantee a good solution. Do note merge_swath takes in 3 at a time so for ALOS2 you may need to run it twice.

Wow, that's really cool, with your help I made a nice attempt, as shown in the picture below, I spliced the F2F3F4 strips.

In addition, Professor Xu, I am trying to geocode the merged deformation file, using proj_ra2ll.csh, there is a trans.dat file in the input option, this file is generated in each sub-strip of MAI processing, but they Existing independently in the topo folder of F2F3F4, there is no complete trans.dat file for proj_ra2ll.csh to input, so I chose a trans.dat coded after the merge of F1F2F3F4F5 strips generated under the merge file during the dinsar process The file has been input, but the result after running is not ideal, as shown in the figure below, is there a problem with the trans.dat file I input, do you have any comments on this? Many thanks!, and look forward to your reply~

[Xiaohua-Eric-Xu]

Hi @KIKINEO , after you run merge_swath, there should be a new PRM file generated. With that PRM, you could generate a new trans.dat with gmt grd2xyz --FORMAT_FLOAT_OUT=%lf dem.grd -s | SAT_llt2rat $your_PRM 1 -bod > trans.dat. Do note your dem.grd needs to cover the whole frame. This should be the one in the merge directory though. For the image you attached, which one is the new solution? The one on top seems to be a result using a wrong trans.dat.

[KIKINEO]

Hi @KIKINEO , after you run merge_swath, there should be a new PRM file generated. With that PRM, you could generate a new trans.dat with gmt grd2xyz --FORMAT_FLOAT_OUT=%lf dem.grd -s | SAT_llt2rat $your_PRM 1 -bod > trans.dat. Do note your dem.grd needs to cover the whole frame. This should be the one in the merge directory though. For the image you attached, which one is the new solution? The one on top seems to be a result using a wrong trans.dat.

I'm sorry to bother you again Prof. Xu, I tried the merge_swath command and the script only generates a merged grid file in the current directory, but there is no corresponding PRM file, as shown below.Do you see any problems in the screenshots I showed?

terminal

inputlist

dir

merge_log

[Xiaohua-Eric-Xu]

try merge_swath inputlist merge.grd merge_PRM .

[KIKINEO]

try merge_swath inputlist merge.grd merge_PRM .

Thank you so much! It works~😀