Problems when running back geocoding/ESD on S1 SLC data

Sure, it’s possible. I just thought that the more “complicated” one would make use of the internal parallelisation much more. snap seems to be taking a loooong time

Without ESD, very small misregistration will be translated in phase jumps between bursts. In case of stationary scenario, you can use the spectral seperation between burst on the overlapping area to find the optimal misfit between bursts and correct these phase jumps.

In the case of a single burst, you don’t meet the problem of these phase jumps (since there’s only one burst).

I agree with you, however, what about the flat area and undulated area, is that the same case, because in the case of undulated area many parameters could affect the corr. , But do you have any article refer to one burst corr. I myself didn’t find, It would be great to add up it in here.

So I am just following your recommendation for error tracing and creating that simplified graph. It is however not quite clear to me, how do I know the bursts I select for one acquisition’s subswath are also there in the other acquisition, since the images do not line up perfectly. For example I selected now IW3 burst 7-12 for one acquisition and burst 3-10 IW3 for the other acquisition. Is snap so “smart” to only show me the area where both scenes overlap? thanks for your quick response by the way!

I’m not sure why undulated areas should be more problematic in the TOPSAR acquisition mode than another.

I don’t have in mind any article about single burst coregistration. But note that ESD is there to correct a problem that arises when stitching bursts all together. This problem is not present when there’s only one burst.

Please take a look at eh threads within this topic,

Interferometric processing of products with one burst overlap

Also have a look at this tutorial,

Step by step InSAR processing

When you read these threads carefully, you’ll find the source of your error is the unmatched image selections, it means, both image should be belonged to the same slice number and orbit number, taking in account the orbit direction.

This is the source of your error.

Basically the arrival time of the signal to the antenna is different according to the objects’ characteristics, putting in mind that there are different passes, and the signal couldn’t be collected in the same pass by different antenna, adding to that the change of incidence angle, all of that and other parameters could lead to higher need to fine corr. in undulating land rather than the flat area. In case it’s one burst or multiple bursts, similar to ERS1/2 and ENVISAT, I found in my results that applying fine corr. .affects positively the results of the InSAR. (personal opinion)

The relative orbit number is the same for both acquisitions, as well as slice number.

If this is your case,

Your study area should be located in the same bursts, not as you mentioned,

But how can they be in the same bursts, if the number of bursts is not the same for both scenes? And in snap, I so far only found the way of visually doing the selection fo bursts in snap in the TOPSAR-Split step. So


I hope it’s possible to see what I mean from the screen shots. I selected burst 7-10 now for both scenes, but if you look at the region, they cover a “completely” different area.

Would you please to share the image name, orbit number, slice number, and the place of the study area, in this case I could give try.

Thanks so much for your help! Study area is around Beira/ Mozambique and images are
S1B_IW_SLC__1SDV_20190319T161451_20190319T161521_015425_01CE3C_AB83
S1A_IW_SLC__1SDV_20190313T161522_20190313T161557_026321_02F156_A63C

So this is the problem, the two images frame don’t much each other, that’s why you found the difference between the bursts number cover the same area,

Please take a look carefully to the meaning of this thread I mentioned above to you,

S1 Dataset

Now your mission is to find a pair with the same cycle number or slightly different, in your case the cycle number of the first one is 94 and the other one is 164, they have the same slice number, but the frame doesn’t cover the same area or slightly different.

For instance I found these pairs for you, check the slice number of both, cycle number and the orbit,

S1A_IW_SLC__1SDV_20190326T030904_20190326T030932_026503_02F802_B076

S1A_IW_SLC__1SDV_20190407T030904_20190407T030932_026678_02FE78_59C0

1 Like

Hi all,

I’m attempting to make a Land Subsidence map for my dissertation, I’m relatively new to remote sensing and working with snap and just come upon a error.

When processing my graph it came up with an error stating: 0, I then attempted to follow each of the steps manually but when I came onto ESD the error came up again.

Does anyone know how to solve this error or experienced a problem like this before?

My datasets are

S1A_IW_SLC__1SDV_20190226T155558_20190226T155626_026102_02E983_A328
S1A_IW_SLC__1SDV_20180219T155552_20180219T155619_020677_0236B3_59E1

Kind Regards

Jake

you can also use the “S1 TOPS Coregistration with ESD” module to prepare the two-product-stack.

Besides that, a one year temporal baseline is quite large…

thanks for your investigation into this. So just for clarification, what is the relative orbit number for? If I search for data @ the Copernicus open access hub I can also only put relative orbit number, not absolute. So somehow it would make sense if the relative orbit number should match for interferometry?

I have started the processing again yesterday using my original pair, but with the simplified graph and only my selected bursts for one swath. that ESD error so far didn’t show up again. Still I am amazed, that since 24h processing time, it is only at 30% and the processing server has 16 cores and 40GB RAM.

I will have a look at the links you provided. This sentinel data processing seems much more complicated than TSX or PALSAR data which I have been processing in the past.

did you reduce the number of bursts in the Split operator? It is shown here: The Order of DEM Creating Steps

Again, for image pairs, I recommend the TOPS Coregistration with ESD

TSX and ALOS PALSAR are acquired in StripMap mode while Sentinel-1 is acquired in TOPS mode. This brings new challenges regarding the processing of swaths and bursts.

If your reply was directed to me: yes, I selected only bursts 7-12 for one acquisition and burst 3-10 for the other, only subswath IW3.
And mu intention was to do the Coregistration with the ESD, but as I mentioned in my initial post, the ESD failed, returning zero match. Which was possibly due to non overlapping bursts that were selected. However, from Falah’s recommendation of simplifying my graph and doing the burst selection, ESD step now seems to work. But still veeeery slow.

From InSAR processing of other datasets I am used to being able to highly automate the processing chain with scripting, but with the sentinel and snaps I am quite lost still :slight_smile: This is sort of just a try with one image, or now even just a tiny portion of this image. But how can one even process a timeseries with intention of PS analysis for example? I imagine this taking ages if one doesnt have access to some supercomputing center …?

However backgeocoding and ESD , works fine fore me, for image pairs, the above graph is used to process many pairs,

I’d like to draw your attention, to the post I explained the selection of matched pairs , Also it is quite clear explained by @ABraun but still you insist to process unmatched pair,
Concerning the orbit as it is mentioned in access hub the number ranged between 1-175,

Concerning your demand of PSI, this topic heavily discussed in SNAP to stamps,

Try up to process the pair , I supposed to you, and you’ll find out the difference,