LOS decomposition to EW and vertical direction

[DaisyUoE]

Hi Morishita, I am looking for a user friendly code/software to decomposition the LOS result from the LiCSBAS output. Do you have any suggestions?

Many thanks, Daisy

[yumorishita]

Is the LiCSBAS_decomposeLOS.py not user friendly for you?

[DaisyUoE]

Hi Morishita, Apology that I did not see LiCSBAS_decomposeLOS.py when I viewed the website. I had a try of this code, first I generated a .vel file, then generated a .geo.tif file, and please see attached Capture1.jpg. After that, I created a files.txt, then wrote ‘20151006_20210706.vel.geo.tif Efile1 Nfile1’, and please see attached Capture2.jpg. After all this, I ran the LiCSBAS_decomposeLOS.py, got an error of ‘Efile1: No such file’, please see attached Capture3.jpg. I thought Efile1 and Nfile1 are supposed to be the outputs? Otherwise, please advise how to generate them?

Thanks, Daisy

[yumorishita]

Please see this https://github.com/yumorishita/LiCSBAS/issues/39

[DaisyUoE]

Thanks, I have created all the files from both ascending and descending frames, now I got 'list index out of range' error. please see attached screen capture. Another thing is the descending frame has limited coverage, could this be the issue? Please see attached capture2. -Daisy

[yumorishita]

It seems that the format of files.txt is incorrect. Could you show me the contents or upload it?

[DaisyUoE]

Here it is, I was planning to upload all the geotif files that mentioned in the txt file, however, Github website do not support that file type. files.txt

[yumorishita]

The files.txt is empty. You must write your own file paths to the vel and EN geotiff files in the files.txt.

[DaisyUoE]

I do not know why it is empty on Github, not empty on my computer. Anyway, here is a screen capture of the content in files.txt

[yumorishita]

Please remove 1st and 4th lines.

[DaisyUoE]

It works perfect, I could not thanks more of your code. Thanks!!! Here is another question, what is the coordinate system of those geotiff files? Is it WGS 84? Somehow, when I load those geotiff in ArcGIS software, the square clipped area, become shorter in the EW direction.

[yumorishita]

Yes, it is WGS84.

[DaisyUoE]

I noticed that the clipped area should be 0.35 degree in square as shown in capture2.jpg for my study area. However, the result is 800*700 pixels, as shown in capture3.jpg. That is may explain in my ArcGIS project, the result area not square as I expected, even they are all in WGS84.

[yumorishita]

Can you upload the log file of step05?

[DaisyUoE]

I use batch_LiCSBAS.sh for processing, so attached is the log file of all steps. Thanks! -Daisy 202205272210batch_LiCSBAS_03_16.log

[yumorishita]

The 800x700 pixel is the size of png file including the color bar. The actual size of the result is 351x351.

[DaisyUoE]

I am back to my first confusion of why the square clipped area become shorter in the EW direction when load the geotiff in ArcGIS? Any advice please?

[yumorishita]

Can you upload the geotiff if it is not too large?

[DaisyUoE]

Github does not support geotiff file to be uploaded, is there any other way to send the geotiff to you please? Such as email address? My email address is jq.huang@ed.ac.uk

[yumorishita]

zip file can be uploaded.

[DaisyUoE]

geotiff.zip

[yumorishita]

It is because 121D_06267_131313 does not cover the entire AOI. 019D_06217_131313 would cover the area.

[DaisyUoE]

Thanks, I will try with 019D_06217_131313. The LOS velocity result from ascending frame, the file name is 20151006_20210706.vel.geo.tiff in my previous uploaded zip folder. Could you open this file in ArcGIS software please? Does it look square for you in the ArcGIS software? It definitely shorter in EW direction when I load the 20151006_20210706.vel.geo.tiff file in the ArcGIS software.

[yumorishita]

I have never used ArcGIS. I displayed the 20151006_20210706.vel.geo.tif on QGIS and it has an equal length in EW and UD in WGS84 CRS. I wonder if you displayed it in other projected CRS than WGS84 (e.g., EPSG3875). In that case, it is natural that the EW length is shorter because the unit is in meters not in degrees.

[DaisyUoE]

Good to know that the geotiff files are square, as it supposed to be. I will look into the CRS issue again in my ArcGIS project. Another question back to decompose the LOS to EW/vertical. Does the order matter in the txt.file, put the ascending, or descending velocity files in the first line?

[yumorishita]

The order does not matter.

[DaisyUoE]

Now I am trying to use 'LiCSBAS_mask_flt.py' tool to mask the velocity file, where is the mask file that I suppose to use here please?

[yumorishita]

In a results directory. Please see this page: https://github.com/yumorishita/LiCSBAS/wiki/file_structure

[DaisyUoE]

I found the mask file in the results folder under TS_XXX directory, and got the masked geotiff file by using 'LiCSBAS_mask_flt.py' tool. Thank you so much for the great technical help, and LiCSBAS software will be citied in the paper I am working on, and you will be surely acknowledge in my paper. Thanks again! -Daisy

[DaisyUoE]

I got the masked results for UD.geo.tif, and expected the extreme values will be gone after masking. Luckily I got rid of some extreme values, however, one area which at the promising location (not on the edge), the UD.geo.tif value is -200 mm/yr, at the same location the LOS value is -160 mm/yr. Is it mathematically possible that the vertical value is bigger than LOS value? Because I simply use the V_LOS×cos⁡38.5° for vertical velocity, it always end up smaller than LOS velocity.

[yumorishita]

If you project the LOS displacement to vertical, 1/cosθ must be multiplied, not cosθ, and the vertical projected displacement must be always larger than the LOS. The LOS displacement is the projection of 3D displacement along LOS and is always smaller than the absolute value of 3D displacement.

[DaisyUoE]

Got it, thanks! How about reference point? I noticed that the descending result and ascending result are using different reference point. So is it OK for the decompose step with different reference points inputs?

[yumorishita]

It would be better to use a common reference point (or area) for both ascending and descending. It can be done by using -r or --ref_geo options of LiCSBAS_cum2vel.py when computing the velocity.

[DaisyUoE]

I used the 'LiCSBAS_cum2vel.py' tool to compute the velocity for ascending to have common reference point with descending, all work smoothly. Thanks! The results of are similar, it is reassuring what I have got, and good to state in the paper that during the calculation of decompose, I have used a common reference point for inputs.

[DaisyUoE]

Hi Morishita, My supervisor has suggested that I could invite you as a co-author, and I think its great if you could make more contributions on the SBAS-InSAR processing and analysis in my study area with your expertise. Please let me know if you interested? -Daisy

[yumorishita]

Thank you for the invitation, but it would be difficult for me to make more contributions because I am no longer in an academic position. I would appreciate it if you could mention me in the acknowledgments.

[DaisyUoE]

Sure, thanks for letting me know. I have a question regard to the error bar/uncertainty of the values. Because in the EW component result, the distribution of the high EW movement location are geologically making sense, however, the magnitude of -50 to 50 mm/yr, it seems a bit fast for me.

[yumorishita]

Unfortunately, there is no function to derive the uncertainty of the decomposed deformation in LiCSBAS.

[DaisyUoE]

Is there a function to derive the uncertainty of the LOS velocity in LiCSBAS please?

[yumorishita]

LiCSBAS_cum2vel.py with the --vstd option

[DaisyUoE]

I ran the code, and it only has xxx.vel output, did not see vstd output? Please see attached screen capture.

[yumorishita]

Don't insert []. Try LiCSBAS_cum2vel.py --vstd.

[DaisyUoE]

Hi Morishita, I just slowly recover from COVID, sorry take a while to get back to work. Now I got the standard deviation in the range of 0-2.19, please see attached picture. What is the high value in the red colour mean? Does it mean it has high uncertainty in the red coloured area? What do you think about this 0-2.19 of the standard deviation in my study area, is it a good uncertainty number in general? -Daisy

[yumorishita]

The high vstd could mean nonlinear deformation. The range 0-2.19 seems to be normal for 5-6 years.

[DaisyUoE]

Great, good to know.

[DaisyUoE]

Hi Morishita, I am working on the text in method section, and looking for some parameters used in the processing. The input number of SAR images, I have found in the TS_GEOCml1clip/info folder, the 13parameters.txt file (please see attached screen capture). So the number for the processing input SAR images is 450, am I right? Thanks. -Daisy

[yumorishita]

Yes, right.

[DaisyUoE]

Hi Morishita, I am trying to output a time-series text file by using cum2tstxt.py and got an error, please see attached capture below.

[yumorishita]

https://github.com/yumorishita/LiCSBAS/issues/7

[DaisyUoE]

Thanks, that was the issue, just back from holiday, a bit blur. Another issue regard to masking, I am trying the process the descending frame covers Kathmandu. However, the mask deleted the top of the result, even in the unmasked result, the coverages is the entire valley. Please advise how to resolve this issue, please se e attached screen capture.

[yumorishita]

Show mask_ts.png, not mask_ts_mskd.png.