Repository navigation
Sentinel-1 RTC - step changes in terrain correction / projection #404
Description
Activity
Thanks for pointing out this shift, we're diving into it now
Reacted by harryC-space-intelligenceOur partner CATALYST discovered and fixed an issue with the Sentinel-1 RTC processing pipeline. The pixel shift issue affected scenes after October 2024. All the affected scenes were reprocessed over the weekend and are now corrected. Thank you for surfacing this data issue!
Thanks Taylor Corbett (@TaylorCorbett), that's great to hear the issue is both identifiable and fixable. We really appreciate the effort to re-process the data.
I'd like to understand a little more if possible:
-
did CATALYST look for and/or find the issue in any other areas apart from the example I identified above? I've seen alignment shifts elsewhere occurring at different time points - I will look for another example this morning.
-
do we have any indication of what the underlying cause was? Asking in case this could help identify other issue areas from the metadata / acquisition patterns.
-
Here is another example, this time in Kenya around May 2022. lat/lon (-3.808283,38.647986)
A notable difference to the Philippines example is that it coincides with a shift in the Sentinel-1 image footprints - the relative orbit is constant but the location of the slices changes.
To reproduce:
import planetary_computer import pystac_client bbox=[ 38.641,-3.812,38.656,-3.802 ] rtc_items = catalog.search( collections=["sentinel-1-rtc"], bbox = bbox, datetime="2021-01-01/2023-01-01", query = {"sar:instrument_mode":{"eq":"IW"}, "sar:polarizations":{"eq":["VV","VH"]}, "sat:relative_orbit":{"eq":57}} ).item_collection() ds = odc.stac.load(rtc_items, bands = ["vv"], groupby="solar_day", bbox = bbox, ) # mask out a few spots of no-data ds = ds.where(ds>0) baseline = ds.isel(time=slice(None,10)).mean(dim="time") deltas = np.abs( ds.isel(time=slice(10, None)) - baseline ).mean(dim=["x","y"]) deltas.vv.plot(marker=".", lw=0) plt.title("Average absolute shift in VV - Kenya")
The plot produced currently looks like
My question is now essentially - is this the same issue as the Philippines example? And if so, does this get us any closer to proactively identifying all the instances of the issue?
Thanks for finding those issues. We have been investigating each of them and this is what we have found so far:
- During our initial investigation into the issue raised on Jan 23rd 2025, we tested several different location. We found that those tested areas had similar behavior to what was identified in the original Philippines AOI (a shift occurring around late October 2024).
- The underlying cause was a bug that was introduced during a system update. That bug was limited in scope to only affecting images collected after late October 2024 and has since been rectified with all affected data reprocessed as Taylor Corbett (@TaylorCorbett) mentioned.
- We do not believe that the issue you have identified here in Kenya is the same as in the Philippines. We ran your script on a sample of ~100 random AOIs across the world and did not see this issue replicated in those areas. Therefore, this issue doesn't appear to be systematic like the previous one.
I hope this answer your questions. We are taking a deeper dive into the issue you have identified for the Kenya's AOI to try to identify the root cause. I will update you as soon as we know more.
Guillaume Morin (@gmorin) Thanks for the info - and good to hear also that the issue we see in Kenya is more limited in scope. Will be interesting to understand what's behind it.
We have concluded our investigation and has you suspected this is related to the change in footprints.
When we looked at the data from ESA before we applied the Radiometric Terrain Correction we noticed a much bigger than anticipated change in azimuth positioning after the change in footprints.
Our (limited) understanding is that the shift is an artefact of the SAR focusing of each burst before they are assembled into a GRD product. To be more precise we believe that the change in azimuth is caused by the adjustment of the doppler centroid to smooth the transition between burst in the GRD composites.
To summarize the shift you observed in the RTC is actually from the ESA’s product and there is not much we can do to fix that issue without a major rework of the processing chain.
Thanks for the update Guillaume Morin (@gmorin), we appreciate the effort to understand the source of the realignment!
Do you know if this azimuth shift is recorded anywhere in the metadata?
Perhaps it is something we can try to detect via the image footprints but it would be good to know if there is anything more accurate.
Just wondering, did you guys come up with a good logic to exclude these "shifted" S1-scenes? Since I have also ran into a couple of them and still haven't yet figure out a good way to flag them (for removal).
We have found several instances of a sudden and persistent shift in the precise geolocation of Sentinel-1 RTC data.
Example - area of the Philippines, shift occurs towards the end of 2024
The issue presents itself as a small translation of the image - in this case about 20m (2 pixels) in the y direction. The red dashed line in the plot is fixed between the two images. ( around lat/lon 7.1296108,126.3043144)
We have observed that the shift occurs across whole scenes (i.e. we are sure it is not due to actual ground changes).
To Reproduce
This produces the following plot, which confirmed for us it is a persistent alteration in either radiometric terrain correction or reprojection:
We cannot see any obvious changes to the satellite viewing pattern that would be an underlying cause, and the shift does not appear to be present in the GRD collection.
Consequence
We are monitoring changes in backscatter over time - as such we require precise coregistration of the full timeseries and these shifts can cause false changes to appear across entire scenes.
Solution?
We can't tell exactly what the underlying issue is, but it appears that the processing pipeline for the RTC data may have slightly changed, or the DEM may have been switched.
Ideally, the full collection should have the same pre-processing applied, so that time series analysis can be done precisely down to the pixel level.