Forum Replies Created
-
Posts
-
Please refer to this post that discussed the exact same problem
https://www.sarproz.com/groups/sarproz-group/forum/topic/sentinel-1a-co-registration-problem/
The message tries to be self-explanatory.
In some cases, one cannot achieve a perfect “burst alignment” for TOPS. Burst alignment here means the following:
Say, line no. 100 of the master image comes from burst 1; then line 100 of slave image must also come from burst 1. If it comes from burst 2 you will see noisy lines in the interferogram (because the signals from burst 1 and burst 2 are not coherent).
In most cases, this alignment can be achieved for every line.
In a few cases, you cannot perfectly achieve this, and there will be a couple of lines having a problem of alignment.
Usually, this would only cause a few noisy lines in the interferogram. You can check your interferogram and see if this is true.
If we want to understand what is happening in this particular case, please send in the full log.
yuxiao
In your data:
20161007T051857_20161007T051924 means the data is taken at 2016-10-07 05:18~05:19 UTC.
In your orbit:
20161007T112543_V20160916T225943_20160918T005943 means the orbits cover the period from 2016-09-16 22:59 UTC to 2016-09-18 00:59 UTC. 20161007 merely means the date that this orbit file is released (usually 21 days after the data acquisition).
Q
If it is a common shift for ALL the points, then please check well your reference point (assuming your reflectivity map is geocoded correctly).
If the shifts for different points are different, then, as discussed above, it is highly likely a height estimation error issue. The right approach should be to estimate the point height as good as possible. In the previous discussions, those are suggestions on how to do this under varies situations.
Q
Did you “set orbits” again after you downloaded the orbits manually and placed in corresponding folders?
Please note that S1A(S1B) means either ORBITS/S1A/2018/05/…. or ORBITS/S1B/2019/12/….
If it still does not work please print-screen me the path of the orbits.
Q
Let me add a little bit more of my own understanding.
First of all, the shift is caused by the fact that the height of that point you try to estimate (using PSI) is not corrected. You said it is DEM error, but the better saying should be “height estimation error”.
In Sentinel-1 data, the normal baseline is very small, hence the height ambiguity is very large, thus the estimation of height will have a larger error (variance). As Dr. Perissin said, when you are working with distributed terrain and mainly focus on the movement, a comprise could be to use the external DEM and do not estimate point height.
In the urban area, since you do not have a DSM (please note the difference between DTM and DSM), then it is generally not a good idea to use the external height as the point height value. This is well explained in the reference Dr. Perissin provided.
Q
First of all, Sentinel-TOPS can only be processed one subswath at a time for now.
In the second place, there are always a few lines at the border that might be out of the area (just a few lines). The system will automatically adjust the area so that a common area is selected.
As long as you can extract and coregister fine you can ignore this warning.
Q
Hello,
The FTP site is working well. There is either a network blocking issue (not necessarily from your side) or there also might be a proxy issue (if for any chances you are using a proxy).
I would try to test the following to rule out problems:
1. try to connect using a client, i.e., filezilla, and check if the connection works;
2. If you have matlab, try to use the ftp() command to connect and see if you can connect;
3. Try with another machine with another IP to make sure this is a network problem instead of a software problem.yuxiao
Could you please send me the new lasterror.mat and log regarding the orbits downloading issue? – and before that, please update to the newest version of sarproz. I see in the previous log that you are using an old version from September last year. Please make sure you are using the newest version of sarproz.
yuxiao
Hello,
Can you go to your browser and enter the following url:
ftp://johndoe:psinsar12138@128.46.174.159/data/S1A/
And see if you can connect. If you can, also try to go into the folder and randomly download a few orbits.
If you cannot connect it means something is still blocking your ftp protocol. If you can connect, then let me know and I will try to understand what is happening.
Thanks,
YuxiaoUpdate your software to the newest version first, please.
YQ
TerraSAR stripmap doesn’t require deramping.
If you are working with TerraSAR ScanSAR/TOPS mode, I don’t think sarproz support those formats yet.
YQ
For Sentinel, Deramp is automatically done (during coregistration).
yuxiao
Hello Steffan,
Could you send the log of this new one to me as well? I will start to investigate from there. I will probably ask for more files but I will check see the log first for signs.
Thanks!
yuxiao
Hello Steffan,
Thanks for the post.
The first few azimuth ramps seem very likely to be caused by the initial coregistration accuracy not good enough. In the next paragraph, I will explain how to tackle this problem.
I am not sure about the ramps on the range direction, though. It might be orbital errors, but we need to check the logs.
The blank interferogram and the one with serious discontinuities are definitely wrong. At this moment it would be good to send me the site.log (please try to do an initial check and make sure the logs including the coregistration part are there. I need the log to start understanding what is going on).
Abou the azimuth ramps, in the coregistration option for Sentinel-1 TOPS, if you click “coregistration parameters”, there is going to be an option called “Orbits Only”. This is a newly implemented method for TOPS that should improve the coregistration results. See https://www.sarproz.com/groups/sarproz-group/forum/topic/new-update-in-sentinel-tops-module/
You can email me at qyuxiao#sarproz.com
yuxiao