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
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.
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?
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.
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.