Copernicus Auto Download DEMs introduce 1/2 pixel and line shift

S1TBX 8.0.6: I observed that Terrain-Flattening and Terrain-Correction of Sentinel-1 using auto downloaded Copernicus 30m DEMs was not the same as using a Copernicus 30m DEM as an external DEM. Auto download is introducing a 1/2 pixel and 1/2 line shift to the DEM. I verified this by manually shifting the external DEM by that amount. I obtain the exact result as auto download with the external DEM after shifting the georeferencing by the 1/2 pixel and 1/2 line: (0.000208333333333,0.00013888888888).

My test data is north where x and y pixel size is different: N51E095.
Pixel Size = (0.000416666666667,-0.000277777777778)
The georeferencing adjustment that produced the same result as autodownload is coincidentally on the even lat/long:
gdal_edit.py -a_srs EPSG:4326 -a_ullr 95 52 96 51 Copernicus_DSM_COG_10_N51_00_E095_00_DEM.tif
The original DEM corner point is: 94.999791666666667,52.000138888888891

Additional testing needs to be performed in more equatorial areas to verify this holds true.

Looks a lot like this:

@johntruckenbrodt You are correct that the second shift that @maawoo reported: “This shift gets even worse when using the auto-downloaded SRTM tiles.” appears to be the same 1/2 pixel/line shift I have reported when using Copernicus 30m Auto Download. I have never selected to output the DEM from the TC process, so I cannot confirm the initial shift @maawoo reported in that post. Today @jun_lu notes: A JIRA ticket ([SITBX-898] - JIRA) has been created for (both?) issue(s).

I have repeated the same experiment with data over the N01W074 geocell. The shifts were also 1/2 pixel and 1/2 line, but these pixels are square: Pixel Size = (0.000277777777778,-0.000277777777778)
So the shift to the auto downloaded DEM prior to TF and TC is (0.00013888888888,0.00013888888888). That same shift is applied in reverse to the saveDEM from TC. @jun_lu