And which would be the expression for S1A?

Thanks

S1-A: Relative Orbit Number = mod (Absolute Orbit Number orbit - 73, 175) + 1

S1-B: Relative Orbit Number = mod (Absolute Orbit Number orbit - 27, 175) + 1

Thank you very much for your answer. In the meantime I have found out juggling around with the numbers of the example.

@spatialtrail and @peter.meadows the tiles of Sentinel-1 having different extents are resulting in the same relative orbit of **92**.

S1A_IW_GRDH_1SDV_20191103T003105_20191103T003130_029739_03639C_FB5C.wkt and its Extent is

78.80412 14.89078 81.42895 16.83671

S1A_IW_GRDH_1SDV_20200805T002754_20200805T002819_033764_03E9E5_716C.wkt and its Extent is

81.08151 26.63921 83.886 28.56222

Am I doing something wrong here?

Thanks in advance

Sentinel-1 A & B are in a repeat period of 12 days and 175 orbits. The relative orbit is the orbit number within each repeat period with values from 1 to 175. So each relative orbit covers a whole orbit and thus covers (almost) all latitude ranges.

Your two images are indeed from the same relative orbit since the difference in absolute orbit number is a multiple of 175, i.e. (33764-29739)/175 = 23 exactly.

To ensure two images with the same relative orbit cover the same region of the ground, the two acquisition times should be very similar (within a few seconds). In your case there is just over 3 minutes between the two images (15s corresponds to approx. 100km along track). You will need to pick a pair of products with much closer acquisition times for them to cover the same region on the ground.

Thanks for the detailed explanation @peter.meadows. The problem I am facing is I want to identify the start and end dates of data already available for a farm in my computer (downloaded).

In Sentinel#2 the search is based on the tile ID. In case of Sentinel#1 how do I find the data available (already available) based on the relative path for a tile.

Thanks

I suggest you use the Copernicus Open Access Hub at https://scihub.copernicus.eu/dhus/#/home. You will be able to find your location and which products have been acquired over that location.

Hi, I have searched a lot the forum and not found an answer to my question, I think you could probably solve my problem.

In the kmz files from SAR-MPC Test Datasets (sar-mpc.eu/test-data-sets) all S-1 bursts are identified thorugh an “absolute burst ID”, a number from 1 to 375887. The shapefile also reports the “relative orbit” number, however I cannot find a way to identify the corresponding “slice” number in the orbit, which is fundamental to be able to select, starting from an absolute burst ID, several S-1 products over the same location! Also, it would be amazing to be able to recover, the local burst ID (number from 1 to 9) starting from the same absolute burst ID, which I think is a mod9 operation, with some offset that is unknown to me.

If youlike please contact me at: mazanetti@fbk.eu

Can you help me?

Massimo

See section 9.25 about burst ID calculation:

Thank you, this is interesting. I tried with one image but the formula seems to not work. To make sure I am using the correct values of the parameters:

**t_b** mid-burst sensing time: I got this information from swath file **./annotation/s1…xml**, in the `azimuthAnxTime`

field (it is the only temporal parameter in the burst data) is it correct?

**t_ANX** anx time of current orbit: I got this information from **./manifest.safe** file, here I have two fields: `s1:startTimeANX`

and `s1:stopTimeANX`

, both do not work correctly…

Can you suggest where I am wrong?

I can only read the document where they refer to the L0 manifest file, perhaps @ghajduch could advise how to do the calculation from L1 metadata?

If you are only looking for relative orbit number from the filename, you can just figure out any ascending node for track 1 starts for each of the satellites with a few searches - you know that this needs to be around 18:00 UTC. After that, its just the time step between orbit numbers is just 12 days / 175 orbits. You can just use filenames and these reference times to figure this out.