Question about the filtered result about licsbas HOT 9 CLOSED

Thank you for using LiCSBAS. The big difference between the filtered and unfiltered time series is generally caused by the atmospheric noise, which is large at far place from the reference. If you select a reference point (by right drag) near the point at which the time series is shown, you will see small difference because the effect of the atmospheric noise is small.

Though I don't know why theoretically most of the deformation should concentrate at the upper part, the deformation in the lower part might be caused by atmospheric noises or orbital errors. It might be worth trying the GACOS correction in step1-3 (unless you have used it), or using an deramping option in step1-6.

from licsbas.

Thank you for using LiCSBAS. The big difference between the filtered and unfiltered time series is generally caused by the atmospheric noise, which is large at far place from the reference. If you select a reference point (by right drag) near the point at which the time series is shown, you will see small difference because the effect of the atmospheric noise is small.

Though I don't know why theoretically most of the deformation should concentrate at the upper part, the deformation in the lower part might be caused by atmospheric noises or orbital errors. It might be worth trying the GACOS correction in step1-3 (unless you have used it), or using an deramping option in step1-6.

LiCSBAS/batch_LiCSBAS.sh

Line 55 in 4cab0af

p16_deg_deramp="" # 1, bl, or 2. default: no deramp

Thanks for the reply, I followed the suggestion about changing the reference point, and it works well, thanks.

About the second question, the reason I think the most of the deformation should concentrate at the upper part is because that the earthquake occured at the top of map, and all the time-series epoches I used here are two years data after the mainshock. So it is mainly shows the postseismic activity. I will try the deramp. I used GACOS correction, but for some images, it said like that " ztd file not available for 20190219_20190225", and in the following process, those no corrected images will be removed. But when I used the GACOS website to manually check the tropospheric delay data, they actually exist, do you have any idea why some data are not available when download them automatically? and can we use the data download from the GACOS.net manually do the correction (from the website I cannot find the sltd format file)? Thanks very much.

from licsbas.

I just notice that I accidently closed the issue, sorry for that, and I reopened it. Thanks.

from licsbas.

But when I used the GACOS website to manually check the tropospheric delay data, they actually exist

What website did you see?

do you have any idea why some data are not available when download them automatically?

Most of the frames do not have full GACOS data in the LiCSAR portal and therefore auto-downloading does not work. What frame are you processing?

can we use the data download from the GACOS.net manually do the correction (from the website I cannot find the sltd format file)?

Sure. The ztd files can be used and are converted to sltd during the LiCSBAS processing.

from licsbas.

But when I used the GACOS website to manually check the tropospheric delay data, they actually exist

What website did you see?

do you have any idea why some data are not available when download them automatically?

Most of the frames do not have full GACOS data in the LiCSAR portal and therefore auto-downloading does not work. What frame are you processing?

can we use the data download from the GACOS.net manually do the correction (from the website I cannot find the sltd format file)?

Sure. The ztd files can be used and are converted to sltd during the LiCSBAS processing.

The website I saw is "http://www.gacos.net/ ", I just input the date that the log said GACOS data is not available, and it turns out I can find the them. I used two frame, "032D_09854_070505" and "156A_09814_081406_2019" . Could you tell me how to add the manually downloaded ztd file into the LiCSBAS processing, I didn't find related step in batch_config file, do I need extra step for this? Thanks very much.

from licsbas.

Just add the ztd and rsc files into the GACOS directory in your processing frame directory which have other sltd files (more specifically, into the directory specified by p03_gacosdir parameter, see below) and rerun step0-3.

from licsbas.

Thank you for using LiCSBAS. The big difference between the filtered and unfiltered time series is generally caused by the atmospheric noise, which is large at far place from the reference. If you select a reference point (by right drag) near the point at which the time series is shown, you will see small difference because the effect of the atmospheric noise is small.

Though I don't know why theoretically most of the deformation should concentrate at the upper part, the deformation in the lower part might be caused by atmospheric noises or orbital errors. It might be worth trying the GACOS correction in step1-3 (unless you have used it), or using an deramping option in step1-6.

LiCSBAS/batch_LiCSBAS.sh

Line 55 in 4cab0af

p16_deg_deramp="" # 1, bl, or 2. default: no deramp

Thanks for the reply, but I just find a new issue on the filter results. You suggested to change the reference point, and it works when I plot the descending time-series. But when I start doing the ascending time-series, the filtered and unfiltered data show highly different trend in some area, and for some area, the velocity directions are even different, even though I make the reference area and detected area quite close. I attached the time-series plot and corresponding reference area. Do you think it is normal, and would you mind to provide some suggestion about how to fix it ? thanks very much.

from licsbas.

I think it is quite normal because the absolute value of the velocity is very small (a few mm/yr) and the length of the connected network is short (<1yr) which means the uncertainty of the velocity is large. The difference seems to be within the error range. You would need to use more data to obtain a better result.
Please read my paper:
https://www.mdpi.com/2072-4292/12/3/424/htm#sec3dot5-remotesensing-12-00424

from licsbas.

I think it is quite normal because the absolute value of the velocity is very small (a few mm/yr) and the length of the connected network is short (<1yr) which means the uncertainty of the velocity is large. The difference seems to be within the error range. You would need to use more data to obtain a better result.
Please read my paper:
https://www.mdpi.com/2072-4292/12/3/424/htm#sec3dot5-remotesensing-12-00424

Thanks for the reply and suggestions. They are helpful.

from licsbas.