It shows both srgrCoefficients as well as grsrCoefficients. In the beginning I naively assumed that the srgrCoefficients are used for slant to ground conversion and grsrCoefficients for ground so slant conversion, but I now have my doubts.
(2) shows a screenshot of SNAP where the srgr_coefs are clearly the same values as the grsrCoefficients in the XML.
When analyzing the SNAP code I then found that slant range to ground range conversion uses coefficients called srgrCoeff to do a conversion by doing binary search, so effectively using these coefficients to convert ground range to slant range - only the binary search then provides the inverse functionality.
I am slightly confused by this. I hoped an analytic conversion would be possible to convert from slant to ground range. If this is not the case, what meaning do the srgrCoefficients in the product XML have?
The analytical conversion from SR to GR is detailed in the doc Sentinel-1 Product Specification, and it indeed uses the srgrCoefficients.
As for why SNAP does not use the srgrCoeffs in the SR to GR conversion, maybe it is due to one of the following reasons:
some SAR sensors don’t provide srgrCoeffs. For instance Radarsat-2 doesn’t, and only the grsrCoeffs are available in the metadata. Maybe the SNAP team wanted a function that generalised to other sensors, not just S1
when I looked at the S1 polynomials some time ago, I was not getting accurate geolocations using the srgrCoeffs. Maybe I was not interpreting them correctly, maybe they were not sufficiently accurate. The roundtrip conversion sr->gr->sr was giving fairly different input and output values when using the srgrCoeffs and grsrCoeffs in each one of the steps, but equal input and output when using grsrCoeffs in both steps. I have checked a recent S1 product and the rountrip conversion is accurate using srgrCoeffs and grsrCoeffs. I see the products now have polynomials with 9 coefficients, as opposed to only 5 in early S1 products. Maybe that explains the increased accuracy.
