Please try the Collocation operator for a test.
Both should do the job actually.
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:
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.
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”.
I’ll try this myself…
Have you used images of different tracks?
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!
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
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
3 Likes
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?
Amazing stuff - this could probably benefit from a tutorial!
1 Like
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.
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
This is the result
3 Likes
That bug has been fixed but the module update has not been released yet.
1 Like
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
Great! Thank you very much. Then I’m looking forward to the next release.
It also made my work easier with easy combination of ascending and descending tracts! This post Small et al. (2021) for more details.
I just tried it with the latest release S1TBX 8.0.6. The spatial reference of the generated multitemporal composite is correct now when saving it as GeoTiff (from the BEAM-DIMAP stack). Great, I’m happy!
But for completeness:
There is a surprising spatial shift of about 200 m in the IMG-Files (Stack AND also generated multitemporal composite) when saving it as BEAM-DIMAP.
1 Like
I’m confused.
then
Not sure what you mean by “it”. Have you compared the spatial reference in the geotiff
(e.g., using gdalinfo) with the BEAM-DIMAP metadata (in SNAP and the .hdr files)?
I tried it again today and the shift is not there anymore. I must have messed up something in QGIS. All good then! I’m sorry for the confusion.
The gdalinfo outputs differ slightly between the two, the GeoTiff-File one is:
Driver: GTiff/GeoTIFF
Files: C:\Temp\Interfero\stack_22_new_MCTF_4.tif
Size is 51219, 25538
Coordinate System is:
GEOGCRS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
ELLIPSOID[“WGS 84”,6378137,298.257223563,
LENGTHUNIT[“metre”,1]]],
PRIMEM[“Greenwich”,0,
ANGLEUNIT[“degree”,0.0174532925199433]],
CS[ellipsoidal,2],
AXIS[“geodetic latitude (Lat)”,north,
ORDER[1],
ANGLEUNIT[“degree”,0.0174532925199433]],
AXIS[“geodetic longitude (Lon)”,east,
ORDER[2],
ANGLEUNIT[“degree”,0.0174532925199433]],
ID[“EPSG”,4326]]
Data axis to CRS axis mapping: 2,1
Origin = (7.548599117221181,51.822928521721238)
Pixel Size = (0.000089831528412,-0.000089831528412)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 7.5485991, 51.8229285) ( 7d32’54.96"E, 51d49’22.54"N)
Lower Left ( 7.5485991, 49.5288109) ( 7d32’54.96"E, 49d31’43.72"N)
Upper Right ( 12.1496802, 51.8229285) ( 12d 8’58.85"E, 51d49’22.54"N)
Lower Right ( 12.1496802, 49.5288109) ( 12d 8’58.85"E, 49d31’43.72"N)
Center ( 9.8491396, 50.6758697) ( 9d50’56.90"E, 50d40’33.13"N)
Band 1 Block=256x416 Type=Float32, ColorInterp=Gray
Band 2 Block=256x416 Type=Float32, ColorInterp=Undefined
compared to the one of the IMG-File:
Driver: ENVI/ENVI .hdr Labelled
Files: C:\Temp\Interfero\stack_22_new_MCTF.data\Gamma0_VH.img
C:\Temp\Interfero\stack_22_new_MCTF.data\Gamma0_VH.hdr
Size is 51219, 25538
Coordinate System is:
GEOGCRS[“WGS84(DD)”,
DATUM[“WGS84”,
ELLIPSOID[“WGS84”,6378137,298.257223563,
LENGTHUNIT[“metre”,1,
ID[“EPSG”,9001]]]],
PRIMEM[“Greenwich”,0,
ANGLEUNIT[“degree”,0.0174532925199433,
ID[“EPSG”,9122]]],
CS[ellipsoidal,2],
AXIS[“longitude”,east,
ORDER[1],
ANGLEUNIT[“degree”,0.0174532925199433,
ID[“EPSG”,9122]]],
AXIS[“latitude”,north,
ORDER[2],
ANGLEUNIT[“degree”,0.0174532925199433,
ID[“EPSG”,9122]]]]
Data axis to CRS axis mapping: 1,2
Origin = (7.548599117221180,51.822928521721238)
Pixel Size = (0.000089831528412,-0.000089831528412)
Metadata:
Band_1=Gamma0_VH
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 7.5485991, 51.8229285) ( 7d32’54.96"E, 51d49’22.54"N)
Lower Left ( 7.5485991, 49.5288109) ( 7d32’54.96"E, 49d31’43.72"N)
Upper Right ( 12.1496802, 51.8229285) ( 12d 8’58.85"E, 51d49’22.54"N)
Lower Right ( 12.1496802, 49.5288109) ( 12d 8’58.85"E, 49d31’43.72"N)
Center ( 9.8491396, 50.6758697) ( 9d50’56.90"E, 50d40’33.13"N)
Band 1 Block=51219x1 Type=Float32, ColorInterp=Undefined
Description = Gamma0_VH
The GeoTIFF file uses ID[“EPSG”,4326], used for the whole world when you don’t need cm accuracy .IMG file has ID[“EPSG”,9001], for New Zealand, and ID[“EPSG”,9122]. for British Columbia.
I’m still not clear if the .IMG file is from the BEAM-DIMAP data folder.