Relative Orbit Number = mod (Absolute Orbit Number orbit - 27, 175) + 1
and so for orbit 7231 the relative orbit is mod(7231-27,175) + 1 = mod(7204/175)+1. Now 7204/175 is 41.165714 and 41*175 = 7175. So the remainder is 7204-7175 = 29 and so the rel orbit = 29 + 1 = 30.
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
@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
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.
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.
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…
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.
The kmz we provide are representative of any cycle.
As such the kmz does not refer to an “absolute burst ID”, but to a burst ID, which is actually a relative one within a cycle. Their purpose is exactly to provide a bijection between beam (for instance IW1) + burst id and a geographic location.
We provide a well two sqlite databases (one for IW and one for EW) providing the same type of information.
In both case, the relative orbit number is only provided for convenience, for instance to filter the huge list of burst id, or from a given burst ID, to filter a list of products by the corresponding relative orbit number. The burst id values are consecutive from one relative orbit to another (for the same sub swath).
In the S1 products, we provide both the burst id (the one comparable to the burst id map), and the absolute burst id, which is a unique identifier of a burst. One cannot directly compute the burst id from the absolute burst id as a cycle is not an exact multiple of burst duration (neither for IW, nor for EW)
In S1 terminology, a “slice” is a part of a data take. A data take is a continuous acquisition of data in the same acquisition mode (EW or IW or …) and the same polarisation configuration. For a same relative orbit, the location of start or stop of the data take may change from one cycle to another depending on the mission planning (even if not changing completely). Thus there is no way to perform absolute prediction of slice number from burst id, acquisition time or something else.
A slice of (EW or IW) is composed of multiple bursts acquired from multiple subswath. As the start of a datatake may be changing from one cycle to another, a given burst can be part of slices with different coverages. That’s the reason why we do not provide “slice” id, but burst id.
I don’t understand your point about “local burst ID”.
The burst data in the ./annotation/s1…xml does not contain one, but at least three temporal parameters:
azimuthTime as an date in UTC
azimuthAnxTime as a time since last ANX
sensingTime as a date in UTC
The azimuthAnxTime shall correspond to tb - tAnx in the formula (that is time since last ANX). However I am not sure if the azimuthAnxTime refer to the start, center, end of the burst.
The relative orbit number is provided in the manifest, both for the start, and stop of the slice (may not be the same for products acquired over ascending node crossing the equator).
The computation of burst ID may be affected as well by inaccuracy of annotation of ANX time for some L0 products. We are identifying them… but this is a very long process.
Hi @ghajduch , thank you for your information. By “local burst ID” I mean the number between 1 and 9 that is required in input to the TOPS Split function in SNAP… To me is very important to understand if there is a deterministic way to relate burst ID with this number (this is to programmatically trigger the TOPS Split function). I fear it is not…
Then this is more a question about SNAP usage than on the content of the data.
Are you referring to Python S1-TOPS-SPLIT Analyzer
If so, this may be “just” about adding the relative burst ID to the list of information extracted by the tool, and/or placing an entry value to filter by relative burst id.
I am not referring to any Python script, just the SNAP function available in the SNAP software:
Radar >> Sentinel-1 TOPS >> S-1 TOPS Split
It is a bit crazy that there is no way to trigger this function without opening the image and check MANUALLY which is the number of the burst (counting them from 1 to 9), instead of just reading some info in the metadata beforehand.
For the data after IPF 3.5.x it is possible, tricky but possible. This the scanario I have in mind:
I find a place on Earth
I check with the MPC burst Map the corresponding burst ID that covers the area
Reading the annotations file I find the burst ID, which is in a given “burst list” with items numbered from 1 to 9, and then I know the local number (1-9).
For data previous to IPF 3.5.x this is just impossible.
Could you please confirm the formula for calculating the relative orbit number of Sentinel-1B? I came across a different formula in this source 2021-1_TR_S1_burst_number.pdf (140.2 KB).