-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SAR swath information #18
Conversation
@emmanuelmathot Is any of this something users would search on? |
@m-mohr yes, user searchs for S1 Stripmap with beam S6 to create an interferometric pair |
@emmanuelmathot I suggest adding an example of a Stripmap product in the README and stripmap-item.json. It eases the adoption |
Okay. For search the current structure of an array of objects is not ideal. If we want to enable easy searching we should probably make the structure simpler or so. |
Yes, I agree with going for a simpler structure and keep the focus on discovery rather than extensive metadata in the STAC Item. |
Maybe just |
Is this useful for satellites other than sentinel-1? |
seems like this is maybe more appropriate for the sentinel-1 extension. unless there are other data providers where this is useful? |
The idea is to have a scalable description of the swath with an object describing the beams. Each beam is a specific steering of the instrument and thus has it's own parameters (i.e. view).
Shall work like
no?
Most SAR mission uses different instrument modes with swath composed of many beams. For instance, ScanSAR technique is a quite used mode in many missions. |
@davidraleigh It's relevant for all SAR missions. See pages 14-15 of https://www.asi.it/wp-content/uploads/2019/08/COSMO-SkyMed-Mission-and-Products-Description_rev3-2.pdf for CSK and this is just an example. |
beams and swath ids cannot be seen as synonyms |
@emmanuelmathot I'm not so sure. In theory yes, but in practice I still see implementations struggle to search bands or assets, so I don't think in practice you can currently easily search for the swath IDs in STAC API Filter implementations. Do you have different information? :-)
@fabricebrito Okay, I tried to understand this through some googling but can't find a good resource that explains the differences. I The other question is: If this is rather specific to one/some(?) SAR modes, should this go into a separate extension (e.g. ScanSAR)? |
beam ids are relevant for StripMap acquisitions so it comes down to how the satellite is programmed to acquire data over the areas. Sentinel-1 Stripmap for instance is typically (not exclusively) used over small islands. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a Stripmap example as this is the original request
.vscode/settings.json
Outdated
@@ -0,0 +1,3 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@emmanuelmathot I hadn't seen the S1-S4-GRD example, it contains the wrong beam id (s6 instead of s4), so just a minor fix and we're good to go
I want to check whether this could be re-used for the CEOS ARD work, but this could take a bit longer... just fyi |
will this create a delay in the approval? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good! Thanks @emmanuelmathot
@m-mohr any updates on your check with CEOS ARD work? |
This PR adds the field
sar:swath
composed of beam objects to describe precisely subswaths.It fixes #17