Coordinate system confusion / reference point correction

[Carolina Hurtado]

Hello,

I have a couple of questions regarding the comparison/validation between InSAR with GNSS stations. This may be a little bit basic but I am getting more and more confused but I am guessing that many experts here may shed some light on the matter.

I processed the InSAR time series with MintPy and exported the results to shapefile to use them on QGIS. QGIS information shows that the Coordinate Reference System is EPSG:4326 - WGS 84. NGL provides information (velocities and time series) on IGS20.

My understandings is that WGS84 and IGS20 differences are negligible. 

However, to compare the results from InSAR and GNSS one must add back the reference point velocity/displacement to the time series (in InSAR the reference point has a 0 mm/y velocity, then one must match the velocities to the real reference point velocity) so InSAR results became absolute after this correction. I use a GNSS location as reference point to be able to make this correction.

My confussions are these. 

1) If I add back the GNSS reference point contribution (from NGL) to the InSAR results (from MintPy), these results are absolute in WGS84 or in IGS20? Then, the comparison between the InSAR results to NGL results after the reference point correction is valid, or should the GNSS time series transformed to WGS84?

2) If I have several GNSS for validation, I can remove the GNSS reference point contribution from the other GNSS and the results from the other GNSS stations would be relative to the GNSS reference point, right? If I take this approach, I assume that regional and global processes (e.g., plate motion and GIA) are being removed from the GNSS, so the remaining is local, BUT, plate motion and GIA may still being in the InSAR results even if these are relative to the reference point? So, this approach makes sense?

Note that I am using the words results and contribution and not rates, velocities or displacements. I do so because I have done reference point corrections separetely with rates and with displacement time series and have different results, which I am guessing come from the linear trends assumption that one often uses. But in most InSAR papers the reference point correction or the difference in coordinate systems is not mentioned.

Thanks for any clarification!

[Yuan-Kai Liu]

To answer your questions:

Adding/subtracting an arbitrary velocity number from InSAR velocity field isn't changing your reference frame! This adding/subtracting operation has several reasons behind it. Could be noise of phase delays, the major reason is that InSAR is a interferometric measurements, modulo of 2pi, thus unwrapped phase or the derived velocity is all relative spatially.

to compare the results from InSAR and GNSS one must add back the reference point velocity/displacement to the time series (in InSAR the reference point has a 0 mm/y velocity, then one must match the velocities to the real reference point velocity) so InSAR results became absolute after this correction. I use a GNSS location as reference point to be able to make this correction.

No, adding or subtracting a velocity number (which you get from a GPS station) from the whole InSAR velocity field doesn't put your InSAR velocity field to the absolute reference frame. I assume you mean IGS20 when you say absolute.

1) If I add back the GNSS reference point contribution (from NGL) to the InSAR results (from MintPy), these results are absolute in WGS84 or in IGS20? Then, the comparison between the InSAR results to NGL results after the reference point correction is valid, or should the GNSS time series transformed to WGS84?

Assume your GPS data from Nevada is in IGS20.

If you did not do any plate-motion adjustment in your InSAR velocity from MintPy, then it is with respect to your satellite orbit, which means it is ITRF2014 (or comparative to IGS14).

So I think you can compare them as they are, maybe pin InSAR to one of the GPS station, as you did.

But that pinning action is not changing the reference frame.

2) If I have several GNSS for validation, I can remove the GNSS reference point contribution from the other GNSS and the results from the other GNSS stations would be relative to the GNSS reference point, right? 

I think right. whatever is zeroed out, that is your new reference.

I assume that regional and global processes (e.g., plate motion and GIA) are being removed from the GNSS, so the remaining is local,

No, the plate motion and GIA cannot be removed from the whole network by adding/subtracting a velocity number taken from some location. Their effects manifests as a deformation field in space. You must subtract a "field" to account for that.

BUT, plate motion and GIA may still being in the InSAR results even if these are relative to the reference point? So, this approach makes sense?

Correct. If you only add/subtract a constant from the whole dataset, they are still there. The effects remain in your GPS network, remains in your InSAR velocity field. So if you want to remove plate motion or remove GIA from your datasets (both InSAR and GPS), but all you do is just adding/subtracting a constant number everywhere, it makes no sense at all. What you need is a "field".

Note that I am using the words results and contribution and not rates, velocities or displacements. I do so because I have done reference point corrections separetely with rates and with displacement time series and have different results, 

They should be the same! Removing a number from velocity should be the same as taking our a linear trend from the timesereis data (slope being the velocity number).

But in most InSAR papers the reference point correction or the difference in coordinate systems is not mentioned.

Taking a refernce point has being there since the invention of InSAR, I don't see the problem of it. As I said, do it in velocity or do it in timesereis should be the same result.

[Yuan-Kai Liu]

More comment on the time-series stuff:

I should say, subtracting a reference station's velocity from a velocity field is mathematically equivalent to subtracting its displacement time series, assuming a purely linear trend in data. Maybe the discrepancies between the two approaches arise from some highly non-linear signals (such as weird assymetric seasonal variations, step offsets, or deformation transients) present in the time series that a single linear rate does not capture. That what I guess, not sure.

[Yuan-Kai Liu]

Further comment on Reference Frame/System:

First, make clear that standard WGS84 in QGIS (code of EPSG:4326) is purely a geographic coordinate system based on a reference ellipsoid, a shape. It helps to define where a pixel/station is located (latitude, longitude, and ellipsoidal height), but it carries no information about time or crustal motion. It is not a dynamic velocity reference frame. In contrast, InSAR velocity fields exported from MintPy are intrinsically expressed in the satellite's orbit frame, which is anchored to a global terrestrial reference frame (typically ITRF2014/IGS14 or ITRF2020/IGS20, depending on the precise orbit files used). Because NGL GNSS solutions are defined in IGS20, and the frame offset and velocity drift between ITRF2014 and IGS20 is negligible for regional deformation studies (< 1 mm/yr), 

thus, your raw InSAR velocity field and the NGL GNSS data are already in compatible global frames.

More on plate motion:

Reference frame transformations or unmodeled long-wavelength motions (such as plate motion or GIA) manifest as a 3D Helmert transformation, which projects onto the satellite Line-of-Sight (LOS) as a smooth spatial gradient or ramp. Correcting for plate velocity in MintPy predicts this LOS gradient and transforms the data from a global frame ( as we said, ITRF) to a plate-fixed frame.  And that is why people can still do a polyfiting to remove/subtract a whatever polynomial ramp in between InSAR field and a GPS network. Because it is an regionally empirical (or maybe efficient?) way to approximate this Helmert trasnformation!

In contrast, selecting a reference point or subtracting a single reference GNSS station merely shifts the spatial field by a constant scalar (a mean bias in a scatter plot if you plot both datasets against each other in x-y axes). This constant shift changes neither the reference frame nor the spatial gradient. Because spatial gradients represent strain—and thus stress in the lithosphere—they carry primary geophysical significance, whereas the reference point offset is trivial.

+Kai

[Yuan-Kai Liu]

oh and if there are other people wants to chime in, please do and correct me if I said something wrong about these geodetic reference frame/system.

I have been thinking about this everytime people ask me on the plate motion thing, and things in Mintpy. 

Everytime i need to organize myself and think about it and think about how to explain it. So anyway. welcome more feedback