Coordinates problem with gpt and Sentinel-3 data

malvina · September 5, 2016, 10:00am

Hi
I’m using SNAP and the gpt command line of snap-3.0 on Sentinel 3 data.
I’ll try to explain my problem:

opening the SLSTR L1 dataset (S3A_SL_1_RBT) with SNAP the data contain correct geographical coordinates.
Saving the output with the Export/GeoTiFF command and visualizing it in ENVI (and QGIS) the coordinates are wrong.
In the attached file you can see the error

.
The same error occurs when I use the gpt command.

If in SNAP I reproject the SLSTR L1 and save it in GeoTIFF, the coordinates are correct.
In the attached file the second visualization with correct geographical information.

Could you suggest me the correct steps to follow in order to obtain a GeoTIFF SLSTR in UTM - WGS84 starting from the xfdumanifest.xml contained in the S3A_SL_1_RBT data?

Thanks and regards
Malvina

mengdahl · September 5, 2016, 10:03am

Please use fully updated SNAP4.0 and see whether the same issue persists. We do not issue bugfixes to old versions of SNAP, which is why all bug-reports should be done on the latest version with the latest updates.

malvina · September 5, 2016, 10:15am

Hi Mengdahl

Thanks for the quick reply.
I’ve now installed SNAP4.0, and repeated the same steps but I’ve the same problem!

marpet · September 5, 2016, 3:15pm

I just tried it. To open the exported GeoTIFF I have used QGIS and not ENVI, because I don’t have ENVI at hand. The coordinates were shown correctly in QGIS. Is it possible that ENVI has a problem with the GeoTIFF file? Can you tell me which product you have used?

malvina · September 6, 2016, 11:06am

Hi Marper
I’ve downloaded the S3A_SL_1_RBT____20160829T201756_20160829T202056_20160829T210706_0179_008_114_0540_SVL_O_NR_002.SEN3 where the Sicily area is well detected.
I’ve followed these steps:

Open SNAP 4
open the S3A xfdumanifest.xml file in SNAP
Selected in the Multiple readers combo request the “Sentinel-3 SLSTR L1B products in 1km resolution”
Export product in GeoTIFF
Visualized the new GeoTIFF file in ENVI and for Mt. Etna the coordinates that are about 37° 42’ N, 15° 00’ E in SNAP while in ENVI are 28° 12’’ N, 46°7’ E.
in my QGIS the data are open in Middle East area.

My question is : why if I reproject from lat/lon in UTM WGS84 using SNAP the GeoTIFF is correctly read by ENVI.
Unfortunately I have to use ENVI/IDL to process S3 data and I would use command line (gpt or gdal) to convert S3 in GeoTIFF.
Can you suggest me another way?
Thanks

marpet · September 7, 2016, 8:03am

Hi Malvina,

I can confirm your observing.
It is better to reproject the data before exporting it to GeoTIff. In former versions we showed a warning when someone tried to export not map projected data to GeoTiff.
Some time ago this message got lost somehow, unfortunately. I filed a bug for this.
So in general it is better to reproject the data. Specifically for SLSTR the result is not very accurate if not done.

malvina · September 7, 2016, 8:47am

Thanks Marpet
please can you tell me the complete gpt Reproject command I’ve to execute in order to reproject the data in UTM WGS-84?

Do I have to resample the data?

gpt Resample -SsourceProduct=S3A_SL_1_RBT___20160829T20175620160829T202056_20160829T210706_0179_008_114_0540_SVL_O_NR_002.SEN3 /xfdumanifest.xml -Pdownsampling=First -PflagDownsampling=First -PreferenceBand=S9_BT_in -Pupsampling=Nearest -PresampleOnPyramidLevels=true -t etna.dim

Thanks a lot

marpet · September 7, 2016, 9:42am

Attached is a graph file. It reads the SLSTR file in 1km resolution and reprojects the product to the suited UTM zone.

You can call it like:

gpt "G:\Processor Requests\read_SLSTR_reproj_to_UTM.xml" -PslstrFile="G:\EOData\SENTINEL3\S3A_SL_1_RBT____20160829T201756_20160829T202056_20160831T041035_0179_008_114_6599_LN2_O_NT_002.SEN3\xfdumanifest.xml" -f GeoTIFF -t "G:\EODATA\temp\S3A_SL_1_RBT____20160829T201756.tif

read_SLSTR_reproj_to_UTM.xml (432 Bytes)

malvina · September 13, 2016, 9:33am

Thanks a lot for your feedback. I’ve tested your script but it didn’t work. Anyway I’ve solved doing the following steps:

gpt Resample -SsourceProduct=S3A_SL_1_RBT____20160909T091559_20160909T091859_20160909T113759_0179_008_264_2340_SVL_O_NR_002.SEN3/xfdumanifest.xml -Pdownsampling=First -PflagDownsampling=First -PreferenceBand=S9_BT_in -Pupsampling=Nearest -PresampleOnPyramidLevels=true -t etna.dim

# select only the S8_BT_in and S9_BT_in bands and attributes

gpt Subset -Ssource=etna.dim -PcopyMetadata=true -PsourceBands=S8_BT_in,S9_BT_in -t etna_res.dim

# Reproject the data

gpt Reproject -Ssource=etna_res.dim -Pcrs=AUTO:42001 -Presampling=Nearest -t etna_rip.dim

# Subset only the S8_BT_in and S9_BT_in

gpt Subset -Ssource=etna_rip.dim -PcopyMetadata=true -PsourceBands=S8_BT_in,S9_BT_in -t etna -f GeoTiff

Thanks again for your help.

jasonbox · July 10, 2017, 9:11am

Hi Marco,

I’ve found the same issue as user malvina… I find that coordinates are correct on mouse-over in SNAP (5.0)…However, after exporting Geo-tiff, opening in QGIS 2.18, I get ~100 km offsets between different Sentinel-3 images… I am using ‘On the fly’ Coordinate Reference System (CRS) transformation and selecting some familiar CRS like WGS84 / NSIDC EASE-Grid North

I confirmed the offsets also appear when loading the GeoTiffs in ENVI. So, I think the issue comes on export between SNAP and read-in to QGIS or ENVI

(ps. still not gotten snappy configured) but the above I can work with through GUIs.

best,

Jason

marpet · July 10, 2017, 3:19pm

Probably the shift occurs because the EASE grid is currently not (well) supported.
How have you done the reprojection.
If I select EPSG:3973 - WGS 84 / NSIDC EASE-Grid North I get
‘This “AxisDirectcion” object is too complex for WKT syntax’

I haven’t seen it before and I don’t understand it, because I can see the WKT.