Terrain corrected S1 data crossing the antimeridian are shifted into the Western Hemisphere

[s0sh0rt]

Terrain corrected results for S1 images crossing the antimeridian (E/W 180) are shifted into the Western Hemisphere. The first image below, of the Northern Division of Fiji, shows the displaced terrain corrected result compared to Google Earth. The coordinate of the left side of the terrain corrected file is W180.00, and should have been approximately E178.66. Addition of terrain-flattening creates a no data zone near the actual location of the antimeridian, second image below (note this is not alligned or scaled to the first image). These defects are present in Siberian images that cross the antimeridian also. Two images for testing are:
Fiji: S1A_IW_GRDH_1SDV_20170719T173155_20170719T173224_017543_01D56F_DCD0
Siberia: S1B_IW_GRDH_1SDV_20170715T183018_20170715T183043_006502_00B6EE_7E37

[s0sh0rt]

Subset to an AOI entirely in the Eastern Hemisphere appears to be a workaround for the issue of terrain correction shifting the output into the Western Hemisphere, as long as the subset does not cross 180. I have also found that external DEMs may not cross or touch the antimeridian, or the result will also end up shifted into the Western Hemisphere with the left edge at W180. However the terrain-flattening artifact remains.

Western Hemisphere AOIs along the antimeridian have similar difficulties. However, subset does not work as a solution for these AOIs: Graphs with subset terminate immediately with no output.

The graph is Read-Cal-TF-TC-Subset-Write using ACE30 auto download DEMs for the N65W180 one degree AOI, and image: S1B_IW_GRDH_1SDV_20161105T183040_20161105T183105_002827_004C93_61DA.
I am unsure why Subset adds a 6 point by replicating the 5th. All Western Hemisphere subsets I have tested immediately terminate without error:
POLYGON ((-179.99 66, -179 66, -179 65, -179.99 65, -179.99 66, -179.99 66))
POLYGON ((-180 66, -179 66, -179 65, -180 65, -180 66, -180 66))
Tested AOI 1 degree east with same result: no output
POLYGON ((-179 66, -178 66, -178 65, -179 65, -179 66, -179 66))
The image without subset is shown below highlighting the flattening issue near the actual location of the antimeridian (center of image). This image is shifted east with the left side at 180. Right of center is the Kresta Bay in Siberia.

External DEMs that slightly cross the antimeridian (DEM x1,x2 longitude -180.004 to -178.996) can be interpreted in Eastern hemisphere coordinates: 179.996 to -181.004. In some cases terrain flattening and/or correction exits with image does not intersect the DEM or subset. Subsetting the external DEM prior to SNAP processing so the left edge is >-180 (not =-180) has not worked as a workaround.

These tests were performed with SNAP 5.0.7, S1TBX 5.0.5. There is no change using SNAP v6.0P5.

[speed_of_light]

Hi,

I’m wondering if you have solved the problem of shifting.
I’m having the same problem with S1 EW GRDM files that are crossing the anti-meridian.

It seems like the geometric corrected ‘.dim’ is correctly visualized in ‘World View’ tab of SNAP. However, when ‘.img’ files are opened, the origin is still shifted.

[s0sh0rt]

Using SNAP 7.0 my standard processing graph (top leg of graph only) takes 10s of hours to run geocells touching the antimeridian, and a HUGE ~500 GB of memory. Other geocells complete in a few minutes, using <50 GB. This is likely because processing of an image crossing the antimeridian is wrapping the globe. I used a DEM trimmed 0.1 degree back from the antimeridian, and specified the Subset the same, in an attempt to avoid antimeridian issues, with out much success.

My most recent test resulted in correct geometry, but for the top part of the image it only processed the subswath entirely in the hemisphere. I believe that the black wedges are probably related to Terrain Flattening Black Areas and may be fixed by increasing Terrain-Flattening additionalOverlap. I will be running more areas and tests as time permits, and will process each step instead of running the graph.

Source image (horizontally flipped):

[s0sh0rt]

I have tested various subsets of my processing graph using SNAP 7.0, on one degree geocell s17e179 with S1A_IW_GRDH_1SDV_20170719T173155_20170719T173224_017543_01D56F_DCD0.

Terrain-Flattening alone is ~15% complete after a day on our 72 core, 768 GB server. Process has used 25K minutes CPU and sits at +550 GB of memory usage. As mentioned previously, TF may be processing the entire circumference of the globe.

Terrain-Correction alone completes in an acceptable 10-30 minutes depending on parameters. Results are correctly orthocorrected for topography, but the files do not have correct georeferencing. Processing time without subset to the geocell: 28 minutes with a 20m DEM covering just s17e179, or 19 minutes using SRTM download:

Processing time with the subset to POLYGON(( 178.9955983 -15.9955983, 179.8998424 -15.9955983, 179.8998424 -17.0038673, 178.9955983 -17.0038673, 178.9955983 -15.9955983)),
is 10 minutes using a 20m DEM covering the same polygon. The polygon and DEM are slightly larger than the s17e179 geocell, but are purposely clipped back from the antimeridian, to avoid any crossing issues:

The failure in the georeferencing is that both the full image and subset have Western hemisphere coordinates with the left edge of the images, incorrectly, on the antimeridian. The full image appears to have the correct northing, but the subset coincidentally(?) has same upper corner as the full image: (-180.0000000, -15.6857078). Both are shown here in the Western hemisphere, overlaid in a viewer, with the antimeridian annotated:

Measuring a single tie point identified a 1.355559 degrees west (no shift in Latitude) for the full image. Shifting the georeferencing results in the image registering with a global border polygon. Use of file georeference coordinates in either hemisphere (left = 178.6444083 or -181.355559) appears to work for most image processing or GIS packages. Eastern hemisphere image shown:

Setting the subset file georeferencing to the subset polygon that was used, results in ~close alignment with a global border polygon:

Similar issues affect Eastern hemisphere geocells in eastern Russia (ie. Northern hemisphere also). This issue possibly affects any image touching/crossing the antimeridian. Additional testing will need to be conducted for Western hemisphere processing.

This has been an issue for a while. Can someone please take a look? I will run some additional tests. @jun_lu

[jun_lu]

The problem has been tracked in https://senbox.atlassian.net/browse/SITBX-647

[s0sh0rt]

Thank you. I suggest opening another problem relative to Terrain-Flattening crossing the antimeridian since they are somewhat different.

[jun_lu]

The issue with terrain-flattening is tracked in https://senbox.atlassian.net/browse/SITBX-649

[jun_lu]

The problem has been fixed. The fix should be in the next release. Please give it a try and let us know if the issue still persists.

[s0sh0rt]

@jun_lu I finally had a chance to start testing a sampling of areas around the Antimeridian. Running SNAP V8.0.3 S1TBX x8.0.2 and the full processing string below with External DEMs corresponding to the 1 degree geocells (lower left corner) results in “No intersection with source product…” for the western hemisphere geocells. Eastern geocells produced the correct product for n62e179 20190419, but 20190430 was shifted into the western hemisphere (-180 to -179 instead of 179 to 180). Both s19e179 were also shifted into the western hemisphere. I believe the difference here is that the slice for 20190419 does not cross the antimeridian.

n62e179 S1A_IW_GRDH_1SDV_20190419T054829_20190419T054858_026855_0304E0_B48D.zip
n62e179 S1A_IW_GRDH_1SDV_20190430T183234_20190430T183259_027023_030B01_D593.zip
s19e179 S1A_IW_GRDH_1SDV_20190428T173233_20190428T173250_026993_0309EF_6CF9.zip
s19e179 S1A_IW_GRDH_1SDV_20190505T063208_20190505T063243_027088_030D6B_386C.zip
s19w180 S1A_IW_GRDH_1SDV_20190428T173233_20190428T173250_026993_0309EF_6CF9.zip
n67w180 S1B_IW_GRDH_1SDV_20190424T182957_20190424T183026_015952_01DF9F_53E1.zip
n67w179 S1B_IW_GRDH_1SDV_20190424T182957_20190424T183026_015952_01DF9F_53E1.zip

I also have tested gpt Terrain-Flattening with my 1 degree DEMs for these images. Only n62e179 20190419 was correctly produced. All the other died with “java.lang.OutOfMemoryError: Java heap space”. I increased gpt.options Xmx to 720GB, yes a lot of memory on our server, and after consuming 720 GB they again died.

I also tested using default SRTM DEMs, which obviously would not download for the northern geocells. The southern geocells died with “java.lang.OutOfMemoryError: Java heap space”, after downloading quite a bit more DEMs than required (pretty much the entire circumference of the globe).

[s0sh0rt]

For >4 years we have wanted to create Sentinel-1 products for areas around the antimeridian. Specifically Fiji and areas of Chukotka Russia. @jun_lu reported the issue fixed in releases after Oct '20. @marpet suggests subsetting to only one hemisphere. This has not worked for our Sentinel-1 processing.

Using SNAP 8.0.8/S1TBX 8.0.5 results in ~600 GB memory used, >10 hours to produce, and >400 hours of CPU, as the process circumnavigates the globe. gpt.vmoptions Xmx was set to most of our large server’s available memory for these tests. The subset is defined entirely in one hemisphere, 0.1 degrees away from the antimeridian. Processing and results are the ~same for both an External DEM just covering the subset, and Auto-Download DEMs. When using Auto-Download the process reports SRTM downloads of the ~entire circumference of the globe.

The results are in the wrong hemisphere. This image shows a ~geometrically correct, ~correctly terrain flattened, ~correctly subset product, but shifted ~1.2 degrees into the western hemisphere. The antimeridian is the left side of the screenshot below from the western hemisphere, with land polygons superimposed. The subset defined in the processing graph is the eastern hemisphere geocell S17E179 (S16-17, E179-179.9), but the product is located from W179.66 to W178.66 in the screenshot.

I recall implementing other processing across the antimeridian by changing all references to radians. I had also created DEM files at E180 and W181 which are duplicates of W180 and E179 respectively, but with coordinates in the opposite hemisphere. This approach solved some of these issues in other software we developed.

Antimeridian is an odd case, and we maybe one of a very few attempting to use Sentinel-1 to map antimeridian areas. This is definitely not something we want placed at the top of the development/fix list, but should be kept on developer radar.

This graph using 3arcsec SRTM Auto Download uses less memory ~300GB.
1slice_e180.xml (6.6 KB)

S1A_IW_GRDH_1SDV_20170719T173155_20170719T173224_017543_01D56F_DCD0.zip
“POLYGON(( 178.9729607 -15.9729607, 179.90 -15.9729607, 179.90 -17.0272235, 178.9729607 -17.0272235, 178.9729607 -15.9729607))”

[jun_lu]

We will look into it, thanks

[aleksandra.efimova]

I also have an issue:

while doing terreain correction(gamma) using COP DEM90 for the Sentinel 1 Path 1, which is crossing the antimeridian, I get a gap in the output. Does anyone know how to fix the issue?