search

sertit / eoreader

Remote-sensing opensource python library reading optical and SAR sensors, loading and stacking bands, clouds, DEM and spectral indices in a sensor-agnostic way.
https://eoreader.readthedocs.io/en/latest/
Apache License 2.0
271 stars 22 forks source link

Add support for time series product #130

Closed BastienKovac closed 4 months ago

BastienKovac commented 4 months ago

Is your feature request related to a problem? Please describe.

I often work with Time series of satellite data (mainly using either Sentinel or Landsat), it would be useful to have a dedicated product for the creation of stacks.

Conceptually, this TimeSeriesProduct would simply be a dict of [datetime, Product] with the capability to properly stack the requested data with an added time dimension, as well as exposing Product information (footprint, available bands etc.)

Describe the solution you'd like

I've started to look into it, and I think the following approach could work :

  1. Slightly rework the Product class so that it inherits from a "ProductAPI" class (exact name TBD) that would only expose what a Product is supposed to do as abstract methods (reading etc.), as opposed to how it's constructed
  2. Identify which methods from the current Product class must be moved to the new API class, and move them
  3. Implement the TimeSeriesProduct, inheriting from the Product API

This plan should avoid any backward compatibility issue.

As a first proof of concept, I think it would be easier to limit the time series to compatible products : Same constellation, same CRS and same available bands

remi-braun commented 4 months ago

Hi Bastien,

I have a POC to handle objects with multi EOReader products here: https://github.com/sertit/eosets

I am currently very busy with other matters so the updates are not that recent, but this POC will arrive to maturity as soon as possible as I need those things also in my work.

I am not sure, but does the Series object aligns with what you want? (see this notebook)

BastienKovac commented 4 months ago

This does seem really close with what I had in mind, may I ask the reasoning to make it a separate library though ? I feel like it would be interesting to have a common API/interface between all those different types of product

remi-braun commented 4 months ago

I really wanted to focus EOReader of the management of single products. This makes the testing way easier and the documentation lighter.

I don't really like the libraries that do everyting all in one, even the coffee ;)

BastienKovac commented 4 months ago

This makes a lot of sense, even though I'd wouldn't turn down a coffee !

Thanks for the quick response

remi-braun commented 4 months ago

Don't hesitate to add issues to EOSets for missing features :)