Maybe the question is dumb but I found no similar information in the forum yet.
In order to increase the geometric accuracy of SAR data (especially when no orbit files are provided, such as ALOS for example) I did the following:
- Opening the GCP manager
4a. Placing a few points with known coordinates (well distributed over the image)
4b. Inserting the actual coordinates in the Lat and Lon colums
4c. Select a Method and click ‘Attach’
4d. Save the Product
- Terrain Flattening
- Range Doppler Terrain Correction
However, it seems that the result won’t actually use my manually inserted points at all. Are they really intergrated in the TC process when they appear under Vector Data > ground_control_points?
I think I am using them wrong because nothing changes with/withoud GCPs.
Try using SAR-Simulation Terrain Correction, it should work better when orbit quality is not very good.
Thanks for the suggestion. This was my hope, too.
Unfortunately, there is almost no difference, even though the topography has enough characteristics. The irregular inaccuracies remain in two ALOS images. I also tried different DEMs.
If I process them with ASF MapReady the shift is gone, even without GCPs. So there must be something which is handled better there. Due to consistency reasons in my work flow I would like to stick to SNAP as well.
I would have thought that orbit state vectors are a required input to the Range Doppler TC (and also SAR-Sim) step.
Also, I don’t see an easy way for Range Doppler TC to make use of GCPs.
Maybe ASF MapReady uses gridpoint-based geocoding?
I tried a bit more and found that, in the case of ALOS PALSAR, the Terrain Flattening causes distortions in the geometry which persist in the Terrain Correction. However, it turned out fine for ALOS-2.
This doesn’t solve the thing with the GCPs but maybe is a solution for the shift.
The original question remains: How are GCPs used in SNAP at all?
Deskew before multilook. The TC doesn’t use the GCP points.
this caused the shift, thank you Luis!
For those who want to apply Terrain Flattening on ALOS-1 data - this order worked for me:
- Multi Looking
- Calibration to B0
- Terrain Flattening
- Terrain Correction
In this case GCPs won’t help at all, but were not required neither.
can I use them for the coregistration?
Edit: Apparently not. If I store GCPs in a product I get a Graph exception when coregistering.
So can I increase the geometric accuracy of ALOS data at all?
@lveci: Can manually placed GCPs be used to improve coregistration results?
any suggestions on this? Does it matter if products have GCPs for the coregistration?
I collected GCPs for three SAR datasets (already terrain corrected) and wanted to perform co-registration assisted by these points but I get “Error: org.esa.snap.core.gpf.GraphException”.
For the offset method I used ‘Product Geolocation’ but none of the options make a change. I also tried differen polynoms but this doesn’t affect the Coregistration error as well. Same happens when I place the GPCs in the SLC image.
How can I effectively use GCPs for the improvement of geolocation of a product?
Currently, this is not possible. In the normal coregistration, the cross correlation uses GCP to determine where a pixel in the slave image is found in the master image. The Warp operator will then use these GCPs to warp the slave into the master space.
You could try create stack and cross correlation and then possibly mess with the GCP before applying the warp. I don’t think it can be done without coding an new operator to do it.
alright thanks you for the clarification.
Is it possible to improve corregistration results using manually placed GCP with known coordinates? I’m using Sentinel 1A SLC images.
For InSAR S-1 SLCs need to be co-registered to 1/1000th of a pixel in azimuth - obviously impossible by hand.
How can Know the orbit quality is not very good, If it there level for its value.?