Unexplained shift observed for one of the subswaths

Dear developers,

we encountered a problem when processing the S1 product: S1A_IW_SLC__1SDV_20151125T164618_20151125T164645_008763_00C7CB_0C97.zip
that we have not seen before. Although, no error or warning was reported by the gpt, we observe in our results a shift (approx 4km) in the range direction (see first fig below) only for data coming from subswath-2 (data in the other subswaths is as expected). If we apply exactly the same processing to the product of 1 cycle before (S1A_IW_SLC__1SDV_20151113T164619_20151113T164646_008588_00C2EF_B1F9.zip) we do not have this issue and everything looks fine.

So does anyone have an idea what is going on here? Thanks alot in advance!


Our processing steps are as follows:
TOPSAR-Split --> ApplyOrbit --> Back-Geocoding --> TOPSAR Deburst --> TerrainCorrection --> SubSet (many)

Screenshot with 4km shift for subswath 2 data:

Screenshot with same processing of data from the previous cycle without shift:

Hi @marpet, could you possibly also look into this other issue which I posted last week. I suspect it could have something to do with the particular placement of the sub-swatch in the specific product mentioned (subswath 2 sticks out to the top wrt subswaths 1 and 3), but for sure the toolbox should be robust for such cases…

Thanks alot,

Hi, I’m not an Sentinel-1 expert, but I would agree that this should not happen.
I’ll try to get one.

Can I have the graph.xml?

Otherwise I have only speculations.

(Having said that, you could be checking the original products location, simply resample to smaller resolution and reproject.)

Sorry for the delay on this. Like most I haven’t been able to use scihub for a while to download this data.

However, I couldn’t reproduce the problem. I’ve tried the product 0C97 on its own without backgeocoding and I’ve tried it backgeocoded with B1F9. Exported to Google Earth and I don’t see a shift.

I’m using the current development branch. It could be the problem was cause by something that has been fixed since your version. A module update for fixes since 2.0 will be available this week.

Hi Luis,

thanks for checking this. Did you try to reproduce our issue via GUI or GPT? We are always using GPT and are still forced to use Version 1.1.2. because of another issue already reported on the STEP forum, so we are actually quite interested to know how you managed to successfully process the data, using the new release, at all? We are aware that in principle older versions are not supported but I will sent you a separate email on this topic later today.

But back to the issue discussed in this topic: In another test we did, we noticed that if we switch the products being used as master and slave in the BackGeocoding step the shifting issue is removed. So there really is something fishy going on here…

Best regards,