I am running change detection on 12 S1 images and I have noticed that some images don’t completley overlap/geographically match each other. You can see it in the image attached where the shapefile is used as reference. (December 2014 below, RGB, and June 2015 above, C11 band). You can see also in the left the preprocessing chain I have followed for all the images. I used a wkt file for reprojection with Nearest Neighbour, and Bilinear interpolation for the RD correction. I didn’t use any DEM since my area is mostly flat. Is there something wrong in the preprocessing?
It’s like there are two groups. Images from May 2015 to September 2015 overlap fine with each other, but not with images from November 2014 to January 2015. Images from Nov to January overlap fine with each other though.
All images are SLC IW dual pol and from the same orbit/path. Additionally, I’ve just seen that the grids usually don’t match. Is that normal?
There we some geolocation accuracy updates throughout the year (Mai, June 2015), you can find them if you follow reports and presentations from most recent workshops regarding the S1. This would confirm your theory of overlaps.
As well I would recommend the Terrain -Correction via a DEM provided by SNAP, instead the Ellip.RD and reprojection if possible. The DEM could solve the accuracy, not only because your region is flat but it actually deals with the position on the geoid where you still have elevation even if your region is flat.
Could lead to more precise results if you are prioritizing the location accuracy.
Additionally it would seem reasonable to collocate your processing results into one file instead of the subset, but that is just my personal preference.
That’s a very interesting detail you bring up. Can you point to any specific documents or presentations where this is mentioned or described? Would like to know more about this.
As Suprd suggested, using Terrain correction instead of ellipsoid RD + reproject fixed it. Thank you sooooo much. However, the grids still don’t match, although I don’t think it will be an issue for my purpose.
That CEOS Workshop seems really usefull. Thanks again!
Good to hear that its working. Also in your graph, don’t put a reproject after the RD TC. You can do the projection in the same RD step.
Even for flat areas, the RD will correct the positions using the orbits, the dem and as suprd mentioned the gravitational model.
It seems there are still issues with the geocoding of Sentinel 1 images. I switched to another study area and performed the same Terrein correction using the 1-sec SRTM, but the images have a small offset. The image below shows the radar image in red, and in the background a Landsat 8 image (which I presume it is well projected). All images are in the same CRS. You can use the split road to see the 500 m offset.
S1A_IW_SLC__1SDV_20150315T181803_20150315T181831_005046_006551_421B
is the first image of my time series, and S1A_IW_SLC__1SDV_20151204T181806_20151204T181833_008896_00CB99_1BC3
is the last. I have every other image in between for the same path, and they all match each other and thus have this 500 m offset.
I have many Landsat 5, 7 and 8 from USGS and they all match each other also.
I substituted the Terrain Correction Operator for Sar-simulation, GCP-selection, and SARsim-Terrain-correction operators and managed to improve the situation, but it is still not perfect. 150 m offset.
We seem to have the same issue, but our images are Terraincorrected with a 20m DEM. When looking at a time series of images in a time series, they “jump around”
You can see that here in this video: https://youtu.be/EVBlQ02ihWw
Exactly the same processing chain with Radarsat images does not give this issue.
At another location (the last two years being Sentinel-1 after minute 1:03) this effect is not seen either … Here it is very smooth: https://www.youtube.com/watch?v=38S7VGncI74
I assume the first video sequence contains images from quite a few different orbit tracks. Have you tried to group the images by track and build one sequence per track? Do they also jump around?
Do the Radarsat images have different orbit tracks as well?
That area seem to have quite mountainous terrain, which makes images from different tracks look very different.
The area of the second sequence looks much flatter. Does this second sequence contain images from different tracks?
I will have to examine this track issue, but TerrainCorrection with a high quality DEM should correct these such that they fit better than they do regardless of the track?
The mountains and look angles make it look jumpier than it is, but if you look at the coast line, it is moving around too much. We had once a similar issue with Radarsat, where it turned out that the orbit parameters delivered were not good and had to be updated … there is no known issue with orbit parameters and Sentinel?
If it is just an issue with inconsistent use of height information, a sequence of images with unique orbit track should not show jumpiness. The geocoding of each one of the images will be equally inaccurate.
If the jumpiness is still there, then there is another unrelated issue.
Yes indeed the coast line moves as well. AFAIK most of the S1 images (could be all by now?) delivered via the Sentinel Hub have been processed with Restituted Orbits, which are already very accurate. If you need more accuracy, you can update the product with the Precise Orbits (Apply Orbit File in SNAP), but you will need to wait 20 days after image acquisition for the precise orbits to be published.
