I have 4 Cosmo-SkyMed HIMAGE (HH) datasets that I have processed (Cal/TC/Spk) in SNAP. I would now like to be able to visually compare them visually as a first step but notice they are all slightly offset from each other.
I would like to check if a coregistration routine between such images is possible in SNAP? I have run the coregistration routine but consistently ended up with 3 blank “slv” images. Would such a coregistration step perhaps be done earlier on in the processing, or am I missing something here? I don’t have very much experience in VHR SAR processing so any help would be very much appreciated.
if all images are of the same track (relative orbit), you can coregister them after the calibration step. However, if they are acquired within different passes, it is better to terrain correct them first and then use coregistration. If you have empty slaves, you can either increase the number of GCPs or try the DEM assisted coregistration instead.
Thank you for the recommendations above.
After calibrating (Sigma0) and Terrain Correcting (using external ALOS30 DEM) the 4 datasets, I loaded them into the “DEM Assisted Coregistration” routine. I note that their “Orbit” numbers are different (screenshot below) and hence, according to your suggestion, this would be the right sequence of steps to take.
Would this be an appropriate routine to use seeing as some form of DEm correction was already done in the TC step prior? Please correct me if I am wrong but would I be right also to say that their orbits are not of the same track/relative orbit if their Orbit numbers are different? What do the “Track” numbers refer to?
With regards to coregistration routines, under Radar > Coregistration, would you recommend the standalone “Coregistration” routine, or the “DEM-Assisted Coregistration”, with or without XCORR? Just to note that these are L1A datasets.
Orbit number is simply the number of times the satellite has circled the Earth since launch. Track number should indicate which ground-track the satellite followed at the time of acquisition…it looks that the track number is not displayed correctly with these products, perhaps there’s a small issue with the reader @lveci
@mengdahl, thanks for the clarification. I’m not sure if this helps but I looked into “Abstracted Metadata” and spotted the following. Would such incorrect information affect the coregistration routine?
Hope this helps with the diagnosis as well, @lveci
My SNAP is updated, yet I see a misregistration when using ascending COSMO-SkyMed StripMap HImage SBS-B products from the Third Party Mission database over Myanmar and I have overlaid the Open Street Map dataset. The dataset is https://tpm-ds.eo.esa.int/oads/data/CosmoSkyMed/CS__OPER_SAR_HIM_AB_20141127T232701_N21-217_E099-571_0000.SIP.ZIP. and the Open Street Map data (in shapefile format) are from: https://download.geofabrik.de/asia/myanmar-latest.osm.bz2. Is this likely due to a mismatch in the quality of the DEM and the high resolution of the COSMO-SkyMed? or something else? I don’t think it is related to the mismatch in acquisition date. The COSMO-SkyMed seems to line up very well with Sentinel 1 data (I compared it with S1A_IW_GRDH_1SDV_20181231T113040_20181231T113105_025269_02CB62_5469.zip using that date because the Google Earth Pro image was only a week away from that date).
Hello, I would like to download a Cosmo-Skymed stack or a couple of images to test in SNAP and StaMPS but I don’t know how to download the samples. When I click your link, the web page don´t be able for me to download it and it show me a message “your account is bloked”.
you have to create an account first and then register for the TPM products before you can access them:
The link posted by pschles cannot be accessed publicly .
Thank you. I have intended but data acces is for EU, Canadá and Africa only, I’m from México, It’s sad.
yes, the ESA archives do not contain the entire image archives of the third-party missions.
More information here: https://earth.esa.int/pi/esa?type=file&table=aotarget&cmd=image&alias=TPMterms
Hi, where can I find more detailed information about the first steps to do with the CSK data in SNAP before using the StaMPS process? i read that all you need to do with stripmap data is coregistration and interferogram formation. I am using 28 images to make 1 stack, and they are from the same stripmap, so i don’t think i will need calibration, right? and after that i can process to do StaMPs exactly as one will do for Sentinel products. Please, correct me if I am wrong. But i don’t understand if I have to terrain correct them, and i don’t also understand what empty slaves mean…
no calibration needed for InSAR techniques, because you are working with the phase information and not with intensities.
Actually, all you need for the StaMPS export is
- the coregistered stack of intensities
- the stack of interferograms (include lat/lon and DEM information during the interferogram formation)
perfect, in the first line of productset-reader , i should put my master slave and all the other files, but i dont know what parameters to choose in the other ones, ( create stack, cross correlation and wrap)
Basically, you can leave all parameters as predefined. Only if the coregistration fails or the quality is bad you need to refine them.
By the way, have you seen this tutorial? InSAR Displacement mapping with ERS data
thank you very much for the tutorial, maybe it will help me understand more
oh, i see that apply-orbit is something you have to do anyway, with any kind of data
no, CSK data has very good orbits, it is not necessary.
I did the coregistration, but i have an empty RGB window, and when I check in the InSAR stack (coregistration Residuals) there is nothing written.
hmm, are all products acquired from the same track?
You can check in the coregistration list, by selecting the refresh button (circular blue arrows).
I took them from the same stripmap.