Thanks for making the GRD dataset available in EE and also openly sharing information about the creation process @simonf
I am trying to recreate your pre-processing steps to process some data locally and develop an algorithm that I then port over to EE. From the documentation I am not 100% clear which pre-processing steps are in which order (especially with noise removal).
Are you able to share the graph you are using/used for pre-processing the EE data?
@Fernerkundung: Can you point out where our docs are unclear about the preprocessing steps? I’d like to fix that. Currently they say:
Each scene was pre-processed with Sentinel-1 Toolbox using the following steps:
- Thermal noise removal
- Radiometric calibration
- Terrain correction using SRTM 30 or ASTER DEM for areas greater than ±60° latitude, where SRTM is not available.
The final terrain corrected values are converted to decibels via log scaling (10*log10(x)) and quantized to 16-bits.
Thermal noise has not been removed from S-1 GRD products.
I’m mostly referring to the Sentinel-1 Preprocessing article.
Points 1 and 2 are straightforward (thermal noise removal and sigma0 calibration with the internal look-up tables). I am lost however at the Terrain correction description:
Orthorectification converts data from ground range geometry, which does not take terrain into account, to σ°
Does that mean you used Apply radiometric normalization and Save sigma0 band with the projected local incidence angle? Or just Range Doppler Terrain correction with sigma0 as input band?
All my GRD products state in the annotation xml files
<thermalNoiseCorrectionPerformed>false</thermalNoiseCorrectionPerformed. This should mean that thermal noise has not been removed, shouldn’t it? Can you point to a documentation that states that noise is removed by the PDGS?
This point on yes/no applying thermal noise removal is a major sore. One of the main effects of this operation on GRD data is to set the noisy boundaries to 1000 (from values that are typically < 10), which is not particularly useful. See this thread.
It would be nice if
<thermalNoiseCorrectionPerformed>false</thermalNoiseCorrectionPerformed> would be consistent with the actual state of the processing (true?).
On March 16 at 21:00 UTC, the last available image in the dataset
COPERNICUS/SI_GRD_INT in my region of interest was
S1A_S5_GRDH_1SSV_20160314T063630_*. From the name of the image, we see that the
production of the image is March 14 at 06:36 UTC.
On March 17 at 15:00 UTC, the last available image in the dataset
was the same.
On March 18 at 19:28 UTC, the last available image was
S1A_IW_GRDH_1SSV_20160315T032230_*. From the name of the image, we see that the
date and time of the production of the image was March 15 at 03:22 UTC.
From the answer of simonf, we know that the transfer of the images
from the ESA to the Google Earth Engine dataset COPERNICUS/S1_GRD_INT is done
Is it possible to know at which time UTC? Can I conclude from my
observations that it is between 15:00 UTC and 19:28 UTC?
Let t be the time of the transfer UTC. Is it possible to know what
are the relative dates and times of the production of the images in the
transfer? Can I conclude from my observations that it is an interval near
[t-3.5d, t-2.5d]? It would mean that the images would be available between two
and a half day and three and a half day later than their production.
@maximebenoit_gagne: yes, currently the daily pipeline finishes ingestion around 19:00 UTC. I should be able to shave off a few hours off its total duration, actually - let me fiddle with the schedules a bit.
In general, though, we don’t want to make strong commitments regarding timing - as you probably have noticed, occasionally scihub goes through periods of high download error rates, in which case we don’t get all the new images immediately.
Incidentally, does someone know if there is a particular time of day when a lot of new assets are added on scihub? I can tune the pipeline so that it starts soon after that time.
It would be nice if false would be consistent with the actual state of the processing (true?).
It is consistent, thermal noise has not been removed from GRD-products, sorry for previous misinformation.
Could you please explain how the incidence angle band is obtained?
Is it equivalent to the band you can save during RD-terrain correction in SNAP?
And if so, is the local incidence angle from DEM, the projected local incidence angle from DEM or the incidence angle from ellipsoid used?
Thanks in advance!
The incidence angle from the tie point grid comes from a grid in the
product metadata and is interpolated on the fly. It’s represents the
incidence angle from ellipsoid.
Dear Sentinel 1 users,
Several people from the Earth Engine team, including me, will be attending the Living Planet Symposium in Prague next week. You are welcome to stop by the Google booth if you are interested.
In addition, we will be offering two free hands-on workshops at the Google Prague office:
Introduction to Earth Engine, Wednesday, May 11, 2016, 18:00 - 20:30
This workshop is intended for new Google Earth Engine users interested in doing large-scale remote sensing analysis. Participants will be guided through the basics of getting up and running with Earth Engine and work through examples of how to easily perform complex, large-scale tasks such as multi-sensor time-series compositing and supervised classification using the Earth Engine API and interactive development environment.
Intermediate Earth Engine Topics, Thursday, May 12, 2016, 18:00 - 20:30
This workshop is intended for users that have already some experience using Earth Engine, and would like to learn more about the Earth Engine internals and advanced processing techniques.
Check out the workshop website for more information and a link to the registration form.
Hope to meet some of you in person!
Based on ESA document (https://earth.esa.int/web/sentinel/technical-guides/sentinel-1-sar/products-algorithms/level-1-algorithms/ground-range-detected), it looks like thermal noise has yet been removed from Level-1 GRD products. Am I wrong? GEE applied this operator again? Please clarify it, since it matters.
According to @mengdahl’s post above, it was not removed. Would be nice to reflect that on the docs.
The documentation is incorrect, thank you for spotting the mistake. This correction is not on by default and you can trust the corresponding flag in product metadata.
so let’s sum up:
The GRD images aren’t thermal noise removed. So GEE is right to correct it and the official documentation is incorrect.
In the Level1 GRD data description it’s written, that ground range coordinates are the slant range coordinates projected onto the ellipsoid of the Earth (likely WGS84). So is there a orthorectification, when I am over ocean still needed? If not, how can I reproject the image wtihout the use of the SAR Geometry functions.
In the documentation of GEE is explained, that every image is terrain or ellipsoid corrected. Is this correct?
Many thanks for your help!
All images in EE are terrain-corrected. In this thread @css says that in S1 toolbox TC is expected to be more accurate than EC over the ocean.
Oh yeah. Very nice. Thank you.
Dear @simonf, are there the presentations/documentation of the workshops available somewhere?
Carlos - it’s not from the Prague workshop, but you might find this useful.
In particular, check out the slide decks EE 101A, EE 201 and Arrays and Matrices.