This is possible.
You can download it manually then and use it as “External DEM”
1 Like
OK, thanks.
Some more points to add:
- SAR processing is complex and it is almost impossible that two different systems would result in exactly the same values. Resampling is probably the main “culprit”, which depends on output resolution, subppixel alignment, DEM/EGM resampling/alignment then reprojections, etc.
- There was a paper published recently comparing Sentinel Hub S1 CARD4L product and Google Earth Engine one. There were as well differences found (obviously), but within the limits of what was expected. And Sentinel Hub’s process seemed to produce more accurate values:
Dyke G., Rosenqvist A., Killough B., and Yuan F., 2021. Intercomparison of Sentinel-1 Datasets from Google Earth Engine and the Copernicus Sinergise Hub CARD4L Tool. International Geoscience and Remote Sensing Symp. (IGARSS’21). FR3.O-10.6.
I would have assumed that both SNAP and Sentinel Hub process produce correct results, you just need to take care that you use them consistently, e.g. either one or another, across your experiment.
2 Likes
Hi
Have you take a look to this post Sentinel 1 GRD sigma0 calibration wrong output values. For me a part of the problem comes from the calibration step in SNAP.
GEE processing workflow (which produces sigma_0 btw) is fully reproducable in SNAP (kind of logical, as it uses a known recipe). It does not do alignment. Alignment is indeed another sampling artefact that may cause differences in the output. Subsetting may have a similar effect, if the pixel spacing is not exactly aligned.
Using a standard processing recipe with an open source toolkit is not really complex at all.
I wonder how these IGARSS folks determine what is “more accurate” (but IGARSS stuff is usually not open).
Google Mercator is 3857, btw, not 3785.
you are right, thank you for clarification.