Spatial reference lost after applying multitemporal compositing

Microwave Toolbox Problem Reports
#1

Hi all

I ran into a problem trying to open a multitemporal composite (lately added feature in radiometric processing) in ArcGIS/QGIS since the spatial reference (“map info” in the ENVI-hdr) got lost in in the process. So no spatial reference was assigned in the GIS when opening the IMG-files but also a GeoTiff-file export from SNAP wasn’t successful. Checking for the source of the problem, I realised that the spatial reference is already lost in the stacking process. The following two terrain-flattened and terrain corrected GRD products I wanted to stack still contained the spatial reference in the ENVI-hdr.

S1A_IW_GRDH_1SDV_20190821T053409_20190821T053434_028663_033E6E_DFEE.zip
S1A_IW_GRDH_1SDV_20190824T170816_20190824T170841_028714_034031_6FC7.zip

I used the following properties in the stacking process:
Resampling type: Bilinear Interpolation
Initial offset method: Orbit
Output extents: Maximum

Any ideas what could have gone wrong and how to solve the issue?
Thanks for your help!

#2

Has nobody else run into this issue? Or do I need to provide more specific information on the processing chain I applied to produce the terrain-flattened and terrain corrected images that served as input for the stack?

Thanks!

#3

As both are already terrain corrected, please select Product Geolocation as Initial Offset Method during the stacking.

Which operator was used to create the stack by the way?

#4

I tried it with “Product Geolocation” too and it didn’t help either…

For the stacking I used “Coregistration” > “Stack Tools” > “Create Stack”. Is that correct?

#5

Please try the Collocation operator for a test.
Both should do the job actually.

#6

I tried it with the Collocation operator. The spatial reference remains there in the IMG-files and it is therefore possible to open them in GIS software.

However, when I try to start the Multitemporal Compositing this error message appears:

image

#7

I haven’t heard of this operator, is it new?
Strange that it wants a coregistered stack.

Does it work to apply Coregistration to the terrain corrected inputs? Also with Geolocation as offset method.

#8

It must be fairly new, yes! But I couldn’t tell exactly after which update it appeared under “Radar” > “Radiometric”.

No, the spatial reference is also lost after applying “Coregistration” > “Coregistration”.

#9

I’ll try this myself…
Have you used images of different tracks?

#10

Yes. S1A_IW_GRDH_1SDV_20190821T053409_20190821T053434_028663_033E6E_DFEE.zip is from the relative orbit 66 (descending) and S1A_IW_GRDH_1SDV_20190824T170816_20190824T170841_028714_034031_6FC7.zip is from the relative orbit 117 (ascending). And just as a subnote: I used an external DEM for the TF and TC.

Thank you for spending your valuable time on the issue!

#11

It looks like that QGIS does not like product with tie point grid geocoding. We will see if we can replace the tie point grid geocoding with other geocoding. A JIRA ticket has been created for the issue ([SITBX-889] Product with tie point grid geocoding is not compatible with QGIS - JIRA). Thank you for reporting the problem

1 Like
#12

I just tested the approach with 5 products of both ascending and descending orbit.
I applied calibration and Terrain Flattening, then used “Create Stack” as suggested in the Help.

This is the result - beautiful! Great job @jun_lu

grafik
grafik1258×850 156 KB

grafik
grafik902×765 166 KB

3 Likes
Normalising Sentinel-1 Ascending and Descending Pass Values
#13

Yes! The results are beautiful. These local resolution weighting composites are great to work with and finally enable an easy combination of ascending and descending tracks! See Small et al. (2021) for more details.

But do you also have problems to open the composite (IMG-file) in a ArcGIS/QGIS?

#14

Amazing stuff - this could probably benefit from a tutorial!

1 Like
#15

The only thing which did not work was using the Copernicus DEM. It produced weird patterns, probably because of resampling issues. I remember that this was reported/demonstrated in another thread, but I can’t find it at the moment.

#16

I’m impressed. I tested it for one of the most extreme landforms (the Cuquicamata copper mine) with VHR TerraSAR-X data resampled to 5 m in combination with 30m SRTM.
Data provided by Airbus: Sample Imagery

grafik
grafik910×838 96.2 KB

This is the result

grafik
grafik917×841 150 KB

3 Likes
#17

That bug has been fixed but the module update has not been released yet.

1 Like
#18

The problem that the output of Create Stack operator is not compatible with QGIS has been fixed. The fix should be in the next release.

2 Likes
#19

Great! Thank you very much. Then I’m looking forward to the next release.

#20

It also made my work easier with easy combination of ascending and descending tracts! This post Small et al. (2021) for more details.