Flat Earth Polynomials – Zero-based vs one-based indexing in SNAP

Microwave Toolbox
#1

I’ve been looking into the CreateInterferogramOp operator and I’ve found a possible issue with the computation of the Flat Earth Polynomial. In particular:

  1. I went to CreateInterferogramOp.java and found a call to the lph2xyz() method. I understand this method assumes one-based numbering of lines/pixels, and hence the + 1 correction in the respective parameters (see below).
public static DoubleMatrix estimateFlatEarthPolynomial(
           final SLCImage masterMetadata, final Orbit masterOrbit, final SLCImage slaveMetadata,
           final Orbit slaveOrbit, final int sourceImageWidth, final int sourceImageHeight,
           final int srpPolynomialDegree, final int srpNumberPoints, final double avgSceneHeight,
           final Product sourceProduct) { 
...
org.jlinda.core.Point xyzMaster = masterOrbit.lph2xyz(line + 1, pixel + 1, avgSceneHeight, masterMetadata);
...
}
  1. Next, I opened Orbit.java and went to the lph2xyz() method, which in turn calls the pix2tr() and line2ta() methods of the SLCImage class (see below).
public Point lph2xyz(final double line, final double pixel, final double height, final SLCImage slcimage) { ... }
  1. Finally, in SLCImage.java, I see the following:
public double pix2tr(double pixel) {
        return tRange1 + ((pixel - 1.0) / rsr2x);
    }
public double line2ta(double line) {
        return tAzi1 + (line * lineTimeInterval);
    }

I wonder why we don’t subtract 1 from the line argument, just as we do for the pixel.

This would also impact the SubtRefDemOp operator.

Any comments are welcome.

Regards,

Esteban
SkyGeo

1 Like
#2

Hi Esteban, thank you for pointing the bug. We have fixed it for stripmap. The problem, however, does not apply to S-1 TOPS product because separate code is used for TOPS product.

#3

Great!

I’m actually debursting and merging master and slave separately first. Only then do I create the interferogram. This is my graph:

S1-Graph.png1392×283 52.5 KB

Is it correct to assume that in this case the product will be treated as a “normal” product and this bugfix will help in that situation, too? I think the CreateInterferogramOp operator will have the isTOPSARBurstProduct flag set to false, due to the deburst/merge step.

Esteban
SkyGeo

#4

Yes Esteban, in that case it does apply.