Sentinel-1 orbit-related questions

Hi all !

I’m currently working on fetching Sentinel-1 data from some plots in Morocco with the EO Browser API. We’re fairly new on S1 data and have a few questions to which we could not find answer in the FAQ and other online ressources.

Our main questions are about orbits and their temporality. Our ROI is in northern Morocco. According to this map, data on our ROI can have ascending and descending orbits and have a revisit period of at least 6 days (red criss-crossed pattern below).

Is there a way to know which Sentinel-1 satellite took the data? i.e. A or B? This metadata is available for Sentinel-2 but we could not find it for S1.

Our ROI is on several orbits, as we get descending and ascending data on the same days, on rare occasions. When that happens for S2 data, we would just take the mean from both observations and accept it. However, it does not seem like a good approach for backscatter data. How could we handle those situations well? Is averaging acceptable for S1 radio data, even more when it’s not from the same orbit direction?

Talking about orbit direction: we read that for non-plane ROI, the orbit direction has an impact on the data collected. Does this mean the data has to be treated separately? We want to use S1 data for timeseries and saw that, indeed, we had sometimes some severe changes between ascendant and descendant orbit, as shown below:

plotted example of our data: VV data has been averaged per date, and here are displayed only the dates for which mean dataMask = 1. No speckle correction here.

On another subject (maybe I should make another topic?):

It is recommended to use a speckle filter even with GRD data. We know some exist spatially (such as Lee filter and so on), but we were wondering if a temporal smoothing (here using Savitsky-Gollay algorithm) could also do the work?

Here is my input task:

input_task = SentinelHubInputTask(

           data_collection=DataCollection.SENTINEL1_IW,

           bands_feature=(FeatureType.DATA, 'GRD_data'),

           additional_data=_(FeatureType.MASK, 'dataMask'),(FeatureType.MASK, 'shadowMask'),

                           (FeatureType.DATA, 'localIncidenceAngle'),(FeatureType.DATA, 'scatteringArea')],

           resolution=resolution,

           maxcc=maxcc,

           config=config,

           max_threads=3,

           aux_request_args={'dataFilter': {'acquisitionMode': 'IW', 'orbitDirection': orbit_direction},

                             'processing': {'backCoeff': 'GAMMA0_TERRAIN','orthorectify': True}}

       )

Thanks for reading me !

Léa

Page 1 / 1

Hi Léa!

There is a lot to unpack in your message Thanks for sharing your thoughts though, it’s interesting.

Unfortunately, I am not a Sentinel-1 expert, so I won’t be able to answer all your points, but I’ll give you a couple of hints on some of the elements that you have touched on. I hope other forum users with more experience in radar processing can jump in!

Is there a way to know which Sentinel-1 satellite took the data? i.e. A or B? This metadata is available for Sentinel-2 but we could not find it for S1.

If you use the mosaicking option TILE, you should be able to access the original tile ID in the scenes object. This page gives more info on the mosaicking, and you can read more on scenes here. We are aware that the documentation is still not very clear and are working on it. If you struggle, don’t hesitate to post in this forum.

So you could get the satellite name (A or out of the tile ID, for example in the evaluatePixel function, by calling scenes.tiless0].tileOriginalId for the first tile in your time range for example. An example output would be: S1A_IW_GRDH_1SDV_20210201T052001_20210201T052026_036392_044574_D1FC.

Our ROI is on several orbits, as we get descending and ascending data on the same days, on rare occasions. When that happens for S2 data, we would just take the mean from both observations and accept it. However, it does not seem like a good approach for backscatter data. How could we handle those situations well? Is averaging acceptable for S1 radio data, even more when it’s not from the same orbit direction?

I cannot comment on averaging orbit directions as being good practise or not. But if you want to access a single orbit direction you could change the DataCollection (DataCollection.SENTINEL1_IW_ASC for example) or narrow the time-range for the day you are looking at.

It is recommended to use a speckle filter even with GRD data.

Currently, speckle filtering is not supported by Sentinel Hub services. We are planning to support the operation in the future however. I would suggest trying to apply some sort of speckle filter on the resulting image to see if it helps with the extreme values you are getting. Nevertheless, it should be noted that usually the speckle filtering step is applied before calibration, orthorectification and terrain correction steps. So I don’t know how valid a posteriori filtering step would be, it might be worth digging into. Our friends from the SNAP forum have some good discussions about the pre-processing of Sentinel-1 GRD data that might help.

Sorry I couldn’t answer more of your questions, but I look forward to others jumping in

Maxim

Hi Maxim @maxim.lamare,

First, thanks for your answers! Indeed, there are quite a lot of topics we’re questionning right now, and we’re really not experts either -I guess it’s showing on our part

For #1, it’s all clear, thanks! We’ll look into it.

For #2, we’ve already accessed single orbit direction (see the input_task code above, there is a ‘orbitDirection’ specification in aux_request_args, which can be descending, ascending or both (default)). This is how we collected the data for the plot I added. Thanks for letting us know about another way to get there!

For #4, about speckle correction:

I specified GRD data, since there already is a speckle-reducing process (multi-looking, as referenced here), but according to your answer it seems like it is not enough.

Thanks for raising the processing steps order question and giving us some ressources, that’s very interesting! So, as of right now, S1 data may not be valid anymore, when downloaded from sentinelhub platforms with corrections and if a speckle correction is added?

Thanks once again! You already helped quite a lot, hoping too that others can offer a different light on these topics (:

Léa

Hello ! Just bumping on point #3 (and by extension #4) raised by @leatresch as it puzzles me as well.

This depends quite a bit on what you are doing with the data. That said, based on the experience from our use-cases, we would recommend to treat descending and ascending orbits separately.