InSAR velocity maps of the vertical displacements

1,312 views
Skip to first unread message

Malvas

unread,
Feb 21, 2021, 8:16:04 PM2/21/21
to MintPy
Hi Yunjun,

I would like to get the velocity map of the vertical displacement of my AOI (I don't know if MintPy can do it. Does it?). If I try to write my own script, how can I get the values of the LOS velocity for the decomposition?

I would appreciate your help!

Best,
Alejandra

Russell Grew

unread,
Feb 21, 2021, 8:38:49 PM2/21/21
to MintPy
Hi Alejandra,

The KMZ raster output shows velocity by default. See https://mintpy.readthedocs.io/en/latest/google_earth/

For the individual points you can use the save_qgis.py script to prepare a shapefile which contains a VEL field. See https://mintpy.readthedocs.io/en/latest/QGIS/

Good luck.

Alejandra

unread,
Feb 21, 2021, 9:13:59 PM2/21/21
to min...@googlegroups.com
Hi Russell, 

thanks for answering. Maybe you mean the LOS velocity. However, I am interested in the velocity of the vertical (component) displacement, which results from a decomposition of the LOS. 

Best regards, 
Alejandra


--
You received this message because you are subscribed to a topic in the Google Groups "MintPy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mintpy/gDUoLOwqy7c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mintpy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mintpy/b9c30bea-30f0-457f-bb9c-15091e01d5b7n%40googlegroups.com.

Russell Grew

unread,
Feb 21, 2021, 9:23:38 PM2/21/21
to MintPy
Interesting.

I have been assuming this could be crudely done with cos(34°), here for Sentinel-1A, though I agree it would be nice to have in the software.

Let's see what the advice is.

Zhang Yunjun

unread,
Feb 21, 2021, 10:16:24 PM2/21/21
to MintPy
Hi Alejandra,

If you have both ascending and descending tracks, you could use asc_desc2horz_vert.py for decomposition, as described in Wright et al. (2004).

If you only have one track, projecting LOS into vertical direction has a strong assumption of no horizontal motion, which may not be true in reality. Thus, mintpy does not produce this by default. If you still want to do it anyway, you could try image_math.py with the equation that Russel described above (V_u = V_los / cos(inc_angle)), which ignores the spatial variation of the incidence angle (~4 deg in the case of Sentinel-1), or write function/script yourself with the language you prefer, here (https://github.com/insarlab/MintPy-tutorial#3-read--write-data-files) is some example of data IO.

Yunjun

Alejandra

unread,
Feb 22, 2021, 7:25:37 PM2/22/21
to min...@googlegroups.com
Hi Yunjun,
Thanks a lot for the tips and ideas! I will take a look at the script and at the article. I will comment here as soon as I have any results or questions.

Best regards,
Alejandra

Message has been deleted

Malvas

unread,
Mar 3, 2021, 6:11:16 PM3/3/21
to MintPy
Hi Yunjun,

In my case study several events occurred during the period of my stack of interferograms, which I processed with ISCE. There is displacement before and after these events. It means that there is not a deformation with a linear trend during the whole stack. Since I want to analyze the deformation before and after these events, I am wondering if it is maybe possible to define the exact "sub-periods" to analyze using MintPy and to use asc_desc2horz_vert.py for decomposition for these defined "sub-periods". For example: in one year (whole stack) three events occurred in March, June and October respectively. Is it possible to process the "sub-periods" January-March, March-June, June-Oct separately and for these subperiods calculate the decomposed displacement with the same whole year stack as input in MintPy or should I run the process separately from the very beginning of the whole process (to stack each "sub-period" with ISCE)?

I would appreciate any hint about it

Best regards,
Alejandra

Zhang Yunjun

unread,
Mar 4, 2021, 11:26:21 PM3/4/21
to MintPy
Hi Alejandra,

Yes, you could use mintpy.velocity.start/endDate options to estimate the velocity for your time period of interest. This also can be done by running timeseries2velocity.py

If the volcanic events are destructive, a.k.a., causing local decorrelation from large tephra/ash deposit, I would also recommend you to use mintpy.network.start/endDate to limit the dates you want to derive the time-series before and after the destructive events. This helps to reduce the decorrelation impact, as shown in section 4 of my preprint here (https://www.essoar.org/doi/10.1002/essoar.10506213.1). If you plan to have multiple time-series with different time periods from the same interferogram stack, you might want to create multiple "mintpy" folders: each for one time-series file, to avoid confusion.

Cheers,
Yunjun

Cheng-Han Lin

unread,
Apr 19, 2021, 12:09:43 PM4/19/21
to MintPy
Hi Yunjun,

I have tried using asc_desc2horz_vert.py for estimating the velocity in the horizontal and vertical directions with both ascending and descending time-series products. Based on the first trial on the process, the spatial resolutions of both tracks were given as below:

file1: A_geo/geo_velocity_msk.h5, Y/X_STEP: -0.0005747486522222158 / 0.0008458199692072122 m
file2: D_geo/geo_velocity_msk.h5, Y/X_STEP: -0.0005834540542291136 / 0.000710619066755942 m

Thus, I used geocode.py to re-sample the products with the consistent resolution of 0.000462963. My problem is that can I consider the value of 0.000462963 (degree?) corresponding to 50 meters on equator in lat/lon coordinates?  If so, what is the meaning of the 'm' in the information above ( Y/X_STEP: -0.0005747486522222158 / 0.0008458199692072122 m). I would appreciate if you could give any hint about the problem.

Best,

Cheng-Han (Stephan)

Malvas

unread,
Apr 19, 2021, 9:11:10 PM4/19/21
to MintPy
Hi Yunjun,

I did not get any notification about this reply. I read it just now. Thanks a lot for the hints and for sharing your preprint!

I just have a question, if I have the estimated velocity of the vertical component (by using asc_desc2horz_vert.py ), is it possible to get the time series with MintPy?

Best regards,
Alejandra

Zhang Yunjun

unread,
Apr 19, 2021, 9:30:40 PM4/19/21
to MintPy
Hi Cheng-Han,

The "m" is a typo in the printout msg (I will fix it in the next commit), it should be "degrees" based on your provided info. Your choice of 0.000462963 looks good to me.

Thanks for pointing it out!

Yunjun

Zhang Yunjun

unread,
Apr 19, 2021, 9:37:34 PM4/19/21
to MintPy
Hi Alejandra,

I guess you meant "one vertical time-series from the asc.  and desc. time-series"? No, this is not implemented in MintPy. This is an ill-posed problem because the ascending and descending time-series do not have the exact same acquisition date/time. 

Samsonov and d'Oreye (2012) provided a solution, in case anyone is interested. Contributions are welcomed.

Samsonov, S., and N. d'Oreye (2012), Multidimensional time-series analysis of ground deformation from multiple InSAR data sets applied to Virunga Volcanic Province, Geophysical Journal International, 191(3), 1095-1108, doi:10.1111/j.1365-246X.2012.05669.x.

Regards,
Yunjun

Deha Agus Umarhadi

unread,
Apr 19, 2021, 9:55:41 PM4/19/21
to MintPy
Hi Yunjun,

I wanna ask a basic question regarding mintpy.velocity.start/endDate 
For instance, I process a stack of images of 2015-2020. Then I want to see the velocity from 2018-2020.
Is there any difference in the results if I also process the images of 2018-2020 (does not include 2015-2017 images) from the beginning separately?

Really appreciate your answer.

Regards,
Deha

Zhang Yunjun

unread,
Apr 19, 2021, 10:48:17 PM4/19/21
to min...@googlegroups.com
Hi Deha,

The raw time-series should be the almost same if your area of interest is coherent (a.k.a. decorrelation mitigation due to network inversion is minimal). I say “almost” because of the assumptions in the network inversion (phase triangulation). They are described in detailed in the equation (1) related text in Yunjun et al. (2019).

As for the velocity, longer time-series works better (more robust) for DEM error correction, thus more accurate final displacement time-series and velocity. But this impact should be negligible if you have enough acquisitions, let’s say >20 images (I did not have an exact number). 

I hope this helps,
Yunjun

You received this message because you are subscribed to the Google Groups "MintPy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mintpy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mintpy/b5f8e34c-51e9-483f-835d-245069318dacn%40googlegroups.com.

Deha Agus Umarhadi

unread,
Apr 20, 2021, 5:52:35 AM4/20/21
to MintPy
Thanks a lot, Yunjun

Best,
Deha
Message has been deleted

Malvas

unread,
Apr 20, 2021, 10:49:08 PM4/20/21
to MintPy
Hi Yunjun,

I mean the time series of the vertical component, which is derived by using the ascending and descending tracks. But, yes, of course, what you say makes sense. Because the estimated vertical (or horizontal) component is derived from both ascending and descending observations, it implies what you say, which is crucial for time series: there is not the same acquisition time. I wanted to know this because it might be useful to compare GNSS with InSAR in terms of time series for a same component, for example to compare the vertical component of GNSS for a point with the (near-)vertical component of the InSAR measurements for the same point.

Thanks for sharing Samsonov's article. I will take a look at it.

Best regards,
Alejandra

Sven Borgstrom

unread,
Apr 21, 2021, 4:10:10 AM4/21/21
to MintPy
Hi Yunjun,
what Alejandra said is, in my opinion, a crucial point.
In my area of interest we have a network of many continuos GPS stations, so such a comparison, I mean in terms of time series, would be really interesting.
I saw in the literature and there are some groups working on linear interpolation of both asc and desc data to get same dates for a reasonable comparison. I suppose this makes sense when dealing with areas with no sudden and strong deformation during satellite revisiting time.
What do you think? I'm not an InSAR expert, just a user so your point of view would be really valuable for not experts (like me ;))
In this regard, what about the possibility to implement linear interpolation in MintPy?
Cheers,
Sven.

Zhang Yunjun

unread,
Apr 22, 2021, 12:04:05 AM4/22/21
to MintPy
Hi Alejandra and Sven,

The "business" of InSAR and GPS, in my opinion, highly depends on the purpose: calibration/validation or integration. For Cal/Val purpose, it's definitely a good idea to project the 3D or 2D (horizontal) GPS into the 1D line-of-right of radar, and compare the LOS GPS with LOS InSAR; instead of the other way around. This is because both interpolation and projecting single track LOS into 3D are "making up" data, which adds extra unnecessary assumptions/complications and is overkill for cal/val in my opinion. As for the single LOS comparison btw. GPS and InSAR time-series, the jupyter notebook of Fig. 8 in Yunjun et al.. (2019) are available on GitHub (https://github.com/geodesymiami/Yunjun_et_al-2019-MintPy), there is more detailed information there if one is interested.

For integration purposes, there are many ways to do it, including but not limited to Samsonov et al. (2012). This is still an active area of research and I still see new papers coming out for it. So it's up to the personal taste, or "geophysical sense of smell" as my colleague said. I don't have active projects on this topic, so it's not on my personal to-do list. Nonetheless, all the needed data and metadata are preserved in the HDF5 files, so this should not stop anyone from trying/implementing.

Regards,
Yunjun
Message has been deleted

Malvas

unread,
Apr 26, 2021, 8:43:28 PM4/26/21
to MintPy
Hi Yunjun,

Thanks a lot for the clear explanation. It makes sense going from 3D/2D GPS to LOS rather than from LOS to 3D/2D. I carried out a test with the code you mentioned (your jupyter notebook of Fig. 8 in Yunjun et al.. (2019)). I got this error when running it with my data: ValueError: datetime.datetime(2015, 9, 22, 0, 0) is not in list.
The code did not find this datetime because all the InSAR-datetimes have a time (acquisition time) different to zero. To solve this issue, I included a for-loop in the script insar_vs_gps.py after the line 234 (section # 2.4 reference insar and gps to a common date), in order to "cut" the time from the date:
for i in range(len(insar_date)):
                insar_date[i] = dt.combine(insar_date[i], time.min)

Maybe that can help anyone who gets this issue.

Best regards,
Alejandra

Zhang Yunjun

unread,
Apr 27, 2021, 2:48:39 PM4/27/21
to MintPy
Thank you Alejandra for sharing.

The detailed time info is added recently to the timeseries object in mintpy, which is not necessary while comparing InSAR with GPS. I like your solution to insar_vs_gps.py, could you maybe issue a pull request on GitHub for it?

Best regards,
Yunjun

Malvas

unread,
Apr 28, 2021, 5:48:49 PM4/28/21
to MintPy
Hi Yunjun,

Sure! I will do it.

Best regards,
Alejandra

Matt Cook

unread,
Jul 14, 2021, 7:47:21 PM7/14/21
to MintPy
Hi all,

I had a similar issue to Cheng-Han. The spatial resolutions of the two data sets were as follows:

file1: Richardson_Asc/mintpy/geo_velocity_msk.h5, Y/X_STEP: -0.00047546108019406395 / 0.00036893183426578105 degrees
file2: Richardson/mintpy/geo_velocity_msk.h5, Y/X_STEP: -0.00047348617413722044 / 0.0003991965001701011 degrees

But I am wondering how you do you decide on a suitable spatial resolution to resample the geo_velocity_msk.h5 files too? 

Thanks,

Matt

Zhang Yunjun

unread,
Jul 15, 2021, 12:04:05 AM7/15/21
to MintPy
Hi Matt,

Here (https://github.com/insarlab/MintPy/blob/eeb2290e5ed31c4b3d721740fd9076a33fdc4171/mintpy/geocode.py#L40) is the simple reference between the resolution in degrees and in meters on the equator. I usually choose an output resolution from there that is close to the ground pixel size in the radar coordinate.

The ground pixel size in the range and azimuth direction in meters can be converted from attributes RANGE/AZIMUTH_PIXEL_SIZE via the following functions (https://github.com/insarlab/MintPy/blob/eeb2290e5ed31c4b3d721740fd9076a33fdc4171/mintpy/utils/utils0.py#L174). The explanation of the attributes are here: https://mintpy.readthedocs.io/en/latest/api/attributes/.

from mintpy.utils import readfile, utils as ut
atr = readfile.read_attribute('velocity.h5')
rg_step = ut.range_ground_resolution(atr)
az_step = ut.azimuth_ground_resolution(atr)

I hope this is clear.
Yunjun

Matt Cook

unread,
Jul 15, 2021, 5:03:14 AM7/15/21
to MintPy
Hi Yunjun,

Thank you for the clear explanation! It all makes a lot more sense now. 

Kind regards,

Matt
Reply all
Reply to author
Forward
0 new messages