Timestamps with multiple satdatasets in the same patch about eo-learn HOT 2 CLOSED

Hi Christoph,

You are correct. The eopatch allows to store one single timestamp list which is used by the input tasks to request data to SentinelHub. If the acquisition dates are different (e.g. in your input_task_2), no data will be retrieved nor added. We would recommend that the number of temporal frames of time dependent features matches the number of timestamps, so that filtering and manipulation tasks would work correctly.

If you wanted to combine datasource (like S2 with S1), what you could do is download the different data sources in different eopatches (using the graph dependencies, not the linear_workflow), perform separate processing pipelines like temporal resampling to same dates and spatial resampling to same ground resolution, and then merge the eopatches into a single one. The resulting arrays could be directly compared/concatenated and filtering tasks would work on all attributes.

Another use case would be to combine corresponding bands (or indices like NDVI) of temporal acquisitions from S2 and L8 into a single eopatch. You could download the NDVI of S2 and L8 separately into different eopatches, and concatenate the eopatches over time (eop1+eop2 or concatenate_data). You'd have to create a task to sort timestamps and corresponding temporal dimension of arrays if you wanted sequential acquisition dates.

If you really wanted to have arrays with different temporal frames in the same eopatch, you could have a task to assign one feature (e.g. 'TRUE-COLOR-L8') to the other eopatch (i.e. storing 'TRUE-COLOR-S2-L1C'), for instance by creating a MoveFeature task. You would have then to handle the difference in acquisition dates and many functionalities of the framework would break. (not recommended option)

Hope this is clear. If you had a use case or workflow in mind we are happy to help you set it up or point you in the right direction.

from eo-learn.

Thanks for the detailed clarification! One initial patch per sensor is the way to go then. I think it would be a good idea to put the essence of this into the documentation, e.g. by providing a minimal "How to use data of two sensors S1 + S2" example.

from eo-learn.