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.
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.
The GRD images aren’t thermal noise removed. So GEE is right to correct it and the official documentation is incorrect.
Another question:
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?
So you’re saying there will be a seamless integration, and now that I think about it I see no reason why there shouldn’t be … any chance you know the S1 ingestion interval by heart?
Yes, I understand S1B will be ingested into the same catalogue (COPERNICS/S1_GRD). You should only notice that it is S1B from the metadata. S1A is 12 day repeat, and S1B as well, but interleaved, so overall 6 day repeat (though the boxes are not always on everywhere).
I am not sure about ingestion intervals, but I believe they push out catalogue updates every week (Thursdays?).
We try to download all new assets every day, and ingest all those we download. S1B is picked up automatically. However, in the last few days the scihub site has been slow, so we have not been able to get all available assets yet.
Check the COPERNICUS/S1_GRD_INT catalogue instead. COPERNICUS/S1_GRD is a so-called “calculated” catalogue, which is exposed at specific push events. Looks like they skipped a few of the latter.
S1_GRD_INT is integer scaled output of s1tbx. You can create logscaled S1_GRD with this function (JavaScript interface):
function db(image) {
var bands = image.select("…").bandNames();
var bias = ee.Image.constant(bands.map(function(pol) {
return image.get(ee.String(pol).cat(’_log_bias’))
}))
var gains = ee.Image.constant(bands.map(function(pol) {
return image.get(ee.String(pol).cat(’_log_gain’))
}))
var toDecibels = image.addBands(image.select(bands).subtract(bias).divide(gains).float(), null, true);
return toDecibels.addBands(image.select(‘angle’).resample(‘bicubic’), null, true);
}
We indeed update the S1_GRD collection only once per week, and we had to skip last week. Sorry about that - it happens quite rarely. This week’s update has just happened, and S1B is now available. The workaround Guido provided does help if you want to see the most recent assets immediately.
Can you please provide a bit of detail on the quantizing procedure? Specifically, do you make use of the ConvertDataType and/or BandMath operators in SNAP/GPT or is there an external process at work?
Also, I am interested to hear if you folks use the “Radiometric Normalization” checkbox within the Terrain-Correction operator (asked previously by Kersten). There are sometopics on the forum here that discuss the differences between using Calibration->Terrain-Correction vs Terrain-Correction(radio-normalize), but as far as I know the suggested procedure is to not use the normalization checkboxes as they are carryovers from NEST.