Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

QST: How to use sarsen functions on other SAR constellations than S1 #41

Open
remi-braun opened this issue Aug 29, 2022 · 4 comments
Open

Comments

@remi-braun
Copy link

Hello,

I would like to use sarsen to avoid using ESA SNAP in eoreader, but since this library lacks an API documentation, I have some questions 馃槃

I already have my own way to load agnostically these SAR constellations:

Constellations
COSMO-SkyMed 1st Generation
COSMO-SkyMed 2nd Generation
ICEYE
RADARSAT Constellation Mission
RADARSAT-2
Sentinel-1
SAOCOM-1
TerraSAR-X, TanDEM-X, PAZ SAR

I would like to use your calibration, terrain correction (and so on) methods in order to avoid calling GPT.
Is this already possible? (are they fundamentally sensor agnostic ?)
Is this a good way to use of your library ?
It seems your algorithms are based on xarray-sentinel, but is there a workaround to your functions that would allow anyone to give bands and metadata, allowing the user to easily use your library with other constellations ?

@alexamici
Copy link
Member

@remi-braun the algorithms are designed to work on top of the xarray-sentinel data structures, that are themselves quite generic, and they are not intrinsically tied to Sentinel-1. What was tied to xarray-sentinel and Sentinel-1 are a few details of the implementation and I'm now building a SarProduct abstract class that defines all the interfaces to the data.

The next release should have all the infrastructure to use the algorithms with other products.

Note that this development is self-funded during a very busy time so no ETA.

@remi-braun
Copy link
Author

Thanks for the heads up 馃槃

I wish you to succeed in this immense task 馃檹

Do you plan tu support other satellite constellations in the future ?
I ask this because maybe some of the work is already done in EOReader (agnostic identification of constellation, metadata handling...) for all the constellations mentionned here before. A synergy could maybe be found if needed.

My roadmap is trivial:

  • support all SAR data we might face during Copernicus Emergency Management Service activations (that means a lot of them)
  • in the future and if possible, let go of SNAP. For that, I need to find a good replacement in Python.
    I hoped maybe I could use sarsen, but if I'm right you are implementing it backwards, as this library is based on xarray-sentinel and not the other way around (I need generic functions for calibration, despeckling, etc. (orthorectification should be easily implemented))

@alexamici
Copy link
Member

alexamici commented Nov 16, 2022

@remi-braun I abstracted the current data interface here:

https://github.com/bopen/sarsen/blob/abstract-product-computations/sarsen/datamodel.py

and moved all Sentinel-1 specific code that implement the generic interface here:

https://github.com/bopen/sarsen/blob/abstract-product-computations/sarsen/sentinel1.py

Admittedly the data interface is not yet completely specified, and I may have bits of the data access that are still Sentinel-1 specific, but adapting from the EOReader product to the sarsen should be already quite simple.

I'll ask a co-worker with more time in hand than me to look into EOReader that looks very interesting!

@remi-braun
Copy link
Author

Nicely done!

I will look into that when a will have more time, but if we can find some synergy this could get exciting 馃槃
Feel free to ask what comes in mind about EOReader (i.e. in the discussion field)

Maybe one day sarsen could become the generic sar processor everybody dreams of 馃檹

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants