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,
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 
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,
I think you are misunderstanding me. So as from the product metadata , there is a orbit_cycle, rel_orbit, abs_orbit as well as slice number. When I search for data products in the hub, I can give the relative orbit number of products. So for my undertanding, if you can search for same relative orbit number, it would make sense, that these products with matching relative orbit numbers are suited for interferometry. Otherwise, why wouldn’t one be able to search for a matching cycle number if this is required?
And I am not insisting on processing wrong pairs. But since the bursts of my intial selected dataset that does have the same relative orbit, but not cycle number, as you pointed out and in the current processing the ESD step did not fail, I am letting it run now, to see what it turns out to be.
For the question I am trying to answer with my InSAR processing, the time span of the image is also relevant. THat is why your provided pair is not suited for my purpose. I am trying to see if there is another pair that matches all criteria
@mdelgado developed a python script for these tasks: Snap2stamps package: a free tool to automate the SNAP-StaMPS Workflow
If you want to automate your preprocessing (generating stacks and interferograms), this is the tool of your choice.
2 Likes
I listed some recommendations on the search for images here: Same sub-swath is expected
The question about relative orbit and absolute orbit is also answered there.
Also I explained in here
Also please have a look at this tutorial, it explains in details the parameters of searching S1 data,
Sorry, if I still don’t understand correctly: But does this mean that if path=track=relative orbit # is the same for two scenes they are suited for interferometry for sentinel1 (as would be the case for other datasets)? Because as mentioned earlier, this is the case for my initial dataset , where just cycle # differs.
Thanks so much by the way for clarifying these simple steps so patiently!
Thanks for the link. I have taken webinars from RUS before, very nicely explained. My graph steps are the same as explained in the tutorial link you posted.
I am just still confused as to why you mentioned that interferometry is not possible for matching relative orbit number pairs. Since in that tutorial they also search for images with the same relative orbit number and there is no mention of cycle number. And when I just checked with the products they used in this tutorial cycle number actually does not match (they use 67 and 68), however slice # and relative orbit number match (as is the case for my scenes). So I think the processing should work out in the end (keeping my fingers crossed!)
thank you for pointing me to this! My worries were also regarding processing times actually. If one small subset already takes several days …
Dear Falah, I did get it! If track/relative orbit/path number are matching, then you can do interferometry. So as I pointed out before, for my two scenes S1B_IW_SLC__1SDV_20190319T161451_20190319T161521_015425_01CE3C_AB83
S1A_IW_SLC__1SDV_20190313T161522_20190313T161557_026321_02F156_A63C
they both have relative orbit number 174 and slice number 1, just the cycle number differs. So interferometry should be possible with these! However, you pointed out earlier that these scenes do not cover the same area and interferometry thus would not be possible. This was confusing me as it is not true.
yes, you can use them then. They can have a shift along-track though.
1 Like