ERS-2 Coregistration Errors (java.lang.NullPointerException) and (java.lang.ArrayIndexOutOfBoundsException: -1)

[SimoneA]

Thanks, @ABraun. I tried this previously:

@ABraun

What happens when you apply a spatial subset on all images based on geographic coordinates?
You can define the WKT here and use it in the subset tool as described here . Afterwards, all products should have the same extent.

And even after subsetting before the coregistration, didn’t solve the problem.
These are the subsetted (orbit applied) Intensities (before coregistration):

7, 13 and 18 remain offset even after subsetting defining WKT.

@ABraun

This can lead to several outcomes

• all products now have the same extent and the three faulty ones cover the correct area
• the subset of the three faulty ones is shifted as well - then the geolocation information is incorrect in general

So should I assume they are badly georeferenced?

Out of curiosity, how is it possible that the footprint is displayed correctly? Does it use a different set of coordinates?

Also, are there any other approaches that might solve the issue, or there is nothing to do at all?

Thanks a lot!

[ABraun]

@SimoneA

So should I assume they are badly georeferenced?

I’m afraid so, yes. If the same coordinates are located at different parts of the images, the images’ geocoding is not correct. You might contact the EO Help to ask if they can re-process the images. https://esatellus.service-now.com/csp/
List them the image IDs and a screenshot of the footprints along with screenshot of both correct and shifted images, so they understand that the three you mention do not cover the area which is given in the metadata.

The footprints are probably just computed based on coordinate information within the metadata, but the coordinates of the image have an offset. Apparently, these coordinates are not correct.

[SimoneA]

@ABraun Thanks a lot for your help throughout the entire process, I really appreciate that. I just got one question left. As the coregistration performed before has been successful for the other scenes, how can I remove only the faulty ones and proceed with the interferograms formation? Is there any specific way to do that to avoid future errors in the coming steps?

Thanks a lot once again.

Simone

[mengdahl]

Hmm, isn’t there an “initial offset” - setting that would tell the co-registration module from where to start the seach, in case of huge displacements? (I remember having requested for that years ago)

[ABraun]

@SimoneA

As the coregistration performed before has been successful for the other scenes, how can I remove only the faulty ones and proceed with the interferograms formation? Is there any specific way to do that to avoid future errors in the coming steps?

you can create a band subset based on the entire stack and un-check all faulty dates. This will ensure correct handling of metadata.

@mengdahl

Hmm, isn’t there an “initial offset” - setting that would tell the co-registration module from where to start the seach, in case of huge displacements? (I remember having requested for that years ago)

I am not aware of such an option which allows to define an initial shift for individual images.

@SimoneA How large (in pixels) is the offset? The automated estimation of initial offsets offers windows of up to 2048 pixels width.

One last thing to try: Apply the orbit file and then range-doppler terrain correction using “complex output” and “nearest neighbor” resampling of the data. If the data is projected correctly, you can use the terrain corrected products as input for the coregistration and select “Product Geolocation” instead of “Orbit” as Initial Offset Method. Maybe this tricks SNAP into correctly overlaying the input data, although there might be new issues because the data are no longer in slant geometry. But worth a try.

[mengdahl]

I think we should add initial offset setting into the co-reigistration as simply widening the search window is tremendously wasteful especially on images with normal locational accuracy.

[SimoneA]

Dear @ABraun and @mengdahl, thank you both for your advice.

I will try them both and post the outcome soon (hopefully it won’t take 13 hours).

@ABraun Could you kindly tell me where to find this information, please?

@ABraun

@SimoneA How large (in pixels) is the offset?

@mengdahl regarding the initial offset, all I can see is either Orbit or Geolocation, is it this supposed to be somewhere else?

I wondered how I could do this:

@mengdahl

I think we should add initial offset setting into the co-reigistration

I could try change the settings in the cross-correlation tab > Estimate Initial Coarse Offset, if that can be the one, but which are the settings to adjust?

[mengdahl]

If you only take the images that can be used for PS-InSAR (compatible Doppler, baseline clearly under critical baseline length), you are left with a much reduced stack that is faster to co-register.

[SimoneA]

The problem is that already some scenes are missing for that period and ROI, therefore, I really need to maximise the available scenes.

[mengdahl]

Unfortunately it is impossible to do InSAR with images that are not InSAR-compatible, even if co-registration works. With respect to your chosen master-scene the following images are fully or almost fully incompatible:

• Due to Doppler-centroid difference: 1,3,4,5,10,11,15,18,23
• Due to too large perpendicular baseline: 13,17
• Image 19 is a borderline case for both.

ERS-2 suffered from loss of gyroscopes which worsened both orbit (baseline) and pointing (Doppler-centroid) control since 2000, see: Review of the Impact of ERS-2 Piloting Modes on the SAR Doppler Stability

If that is the timeframe and area you are interested in I would recommend you to download Envisat ASAR data that does not suffer from those same issues.

See this reference for more info: InSAR Principles: Guidelines for SAR Interferometry Processing and Interpretation (ESA TM-19)

[SimoneA]

Thanks a lot @mengdahl I really appreciate your help. I will very much consider Envisat instead, and see if my life will get easier. Will keep you posted, thank you so much!

[ABraun]

we discussed this again and wanted to suggest the following things to try (maybe for a test only with one correct and one faulty product):

• apply the “Update Georeference” operator (Radar > Geometric) to one of the faulty products and see if the result is more suitable for coregistration
• increase the coarse registration window size as large as possible
• compare DELFT and PRARE orbits to check if one of them produces better coregistration results

Please test only one of these options at a time to see if the change has an impact. We are interested in your experience, once you can share something (both good or bad)

[SimoneA]

Dear @ABraun thank you to further investigate my issue. I currently changed to Envisat, and I completed the whole STaMPS process without significant issues. However, as soon as I’ll get a minute, I will try these steps and I will post the results, hopefully within the next week!