Geographic coordinate sampling

Dear SNAP-Team,

I recently compared exported latitude and longitudes from the Terrain-Correction operation to a self-made latitude and longitude raster grid for a region of interest in Africa (just an example). Please find the GPT graph I have used and the generated coordinate images under the following link: I used the Copernicus DEM with added EGM2008 heights as an external DEM with a sampling of 0.0001 degrees. Unfortunately I cannot provide the DEM here.

I have observed a rather weird sampling behaviour of the coordinates which do not seem to be equidistant, i.e. an alternating, hidden sampling pattern affects the actual sampling. For the sake of illustration, I only use latitudes now to explain the problem, because longitudes behave the same. In the below image you can see an outcut from the whole scene from SNAP’s latitudes output (“SNAP_latitudes_africa_roi.tif”)

and the self-made latitudes (continuous sampling increase from the upper-left corner) (“latitudes_africa_roi.tif”).

If one subtracts both layers the following pattern becomes obvious (“latitudes_diff_africa_roi.tif”)

with a zoom-in view:

The difference between SNAP’s latitudes and the other continuous latitudes always increases up to 7 sampling steps and then becomes approximately equal again. The maximum order of the difference is about 1e-6 degree, which translates to around 0.2-0.3m at the equator. My questions are:

  1. Why does this pattern occur, i.o.w. why is the longitude and latitude sampling in SNAP not equidistant? I debugged through the source code and found the responsible function to be the MathTransform interface of the opengis package.
  2. Isn’t the order of this pattern still critical when geo-referencing Sentinel products? Or did I misinterpret something?

Thank you very much in advance for your advice.

Differences of the magnitude you are seeing often occur with calculations using 32-bit (single precision) floating point. Historically, remote sensing has used singe precision more most data to keep memory requirements within the capacity of high end 1990’s vintage UNIX workstations. Many remote sensing use cases don’t need sub-meter accuracy.

The GIS community, however, does need sub-meter accuracy, so the best place to discuss your findings (especially if you include a patch) is the GeoTools developer list (found here). OpenGIS FAQ gives useful historical background for opengis and GeoTools.

Dear @gnwiii ,

thank you for this interesting, historic insight :slight_smile:
From the order of the pattern your explanation sounds meaningful - I will try if I get more information from the respective GeoTools code repo.