Investigate potential data correlation between overlapping frames on the same track when performing the decomposition.

[andwatson]

A given pixel may have velocities from two frames on the same track, which are currently treated as independent.
Given that the underlying data is the same, we need to set some sort of correlation between these observations.

[ditafaith]

@andwatson I am sorry if this question not related to.
The Licsbas results mostly *.geotif UD and EW from the *.h5 file.
Is it possible to extract time series at desired point to compare with GNSS vertical ?
or is there any other technique says to convert GNSS vertical to LOS direction in terms of comparison to each other.

[andwatson]

LiCSBAS can output displacement time series in the satellite line-of-sight for any pixel in the processed frame. If you want to compare these to GNSS displacement series, then I would project your GNSS displacements into the satellite LOS using the heading and azimuth angles (/ ENU component files in LiCSBAS).

Otherwise, if you have overlapping InSAR frames, you can look at decomposing those into Vertical and Horizontal motion and then comparing that to the GNSS.

[ditafaith]

Yes, I did to decompose the vertical one and E-W using licsbas_decompose command, however there is not possible to extract time series of vertical since the result is geotif.
Regarding your sentence "then I would project your GNSS displacements into the satellite LOS using the heading and azimuth angles (/ ENU component files in LiCSBAS", is there any sample or code to perform this task ?

[andwatson]

Apologies for the misunderstanding - the licsbas decomposition is just of the velocities (to my knowledge), not the displacements, so if you wanted to decomposed the displacements you would need to write something to do so. The difficulty is that the ascending and descending frame likely have displacement observations at different dates, so I think you'd need to look into binning them somehow (I've thought about this but never tried).

As for projecting into LOS, I don't have code for working with GNSS data, but the basic idea is:

gnss_los = (gnss_E.*compE(:,:,ii)) + (gnss_N.*compN(:,:,ii));

This is from the ref_to_gnss_fields. The LiCSBAS ENU files tell you how much of the motion in a given direction going into the LOS. So if you have vertical GNSS displacements, then you just need to multiply them by U.geo, or you can sum all three components into LOS.

[ditafaith]

Thanks for fruitful discussion. Since I get N, E, U file, it is possible to transform GNSS velocities
I will use 3 frames from LiCSSAR to cover the whole island and only have one GPS chosen as a reference/ fixed point, which is not deformed. Is it possible to combine results from 3 frames and refer to 1 reference point ?
Following the method from Weiss (2020), it said "each frame has its own independent reference point for velocity determination". If my understanding is correct, since there are many GPS stations, then it is used for each frame, then plot all results with same color range value, is it correct ?

Since licsbas decomposition results are not possible to extract the vertical and east-west time series, I would like to know, if there is possible to decompose LOS velocity fields into XYZ format. The goal is to generate strain from InSAR.

[andwatson]

Okay so working through these:

Single GNSS velocity that is within all three frame
In this case, you can tie all three InSAR velocities to that GNSS velocities by shifting the InSAR velocities by the difference between the GNSS velocities and the average of the InSAR velocities in some radius around the station (to reduce noise).

Single GNSS velocity in only two of the frames
In this case you could do the above for the two frames that overlap the station, and then for the third you'd minimise the difference between that frame and another frame (in same LOS) for a given area, which will standardise the references between the two.

GNSS weekly solutions
You could actually reference every interferogram to the GNSS displacement series:
https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2021JB022579?saml_referrer

In the case of Weiss (2020), a second-order polynomial is used to tie each InSAR frame velocity to the interpolated GNSS velocity fields, which helps mitigate long-wavelength error sources in the InSAR (e.g. tropospheric, ionospheric), and gives you greater consistency between overlapping frames, which is good for decomposition.

As for decomposing, you can decompose LOS asc and desc vels from licsbas into vertical and E-W. Normally we use GNSS to constrain the N-S, as you need as many data sources as outputs (so two look directions can't give you three components), and InSAR is more insensitive to N-S.

[ditafaith]

Thank you for giving me more pieces of literature.
Indeed, many works explained to constrain N-S from GPS, also in case of Weiss (2020). Is there any recommendation tool to perform this task ?

I am sorry my bad to understanding, "by shifting the InSAR velocities by the difference between the GNSS velocities and the average of the InSAR velocities". Do you mean like the picture as below ? if yes, what should I do to interpolate inside the circle ?

x

[andwatson]

In the setup shown, you won't be able to perform a decomposition as you only have a single look direction. If you have frames descending frames, then the removal of the GNSS North is handled by this software.

As for in that setup, I would reference Frame-1 by subtracting the difference between the LOS-projected GNSS velocity, and the average of the InSAR velocities within that circle. You could then attempt to reference Frame-2 to Frame-1 (and so on) by minimising the difference between the overlapping velocities. Given the difference in look angles within the overlap, you may need to minimise this difference (I think the Weiss 2020 Turkey paper discusses this when using across-track differences to assess uncertainties). Also note that any across track ramps from absolute plate motion will accumulate in doing so, so you may want to remove these first.

[ditafaith]

Thank you for your valuable explanation.