My team and I set up functions in order to automatically fetch and process satellite data using sentinelhub and eopatch libraries.
For S1 data, we are using a linear workflow. The main piece is a SentinelHubInputTask. It asks for
bands_feature VH, VV from
DataCollection.SENTINEL1_IW (we look for data in Northern Africa), and
additional_data localIncidenceAngle, scatteringArea, shadowMask data. Orthorectification is used, thus this data is available.
Until the recent update, all was fine -we could request S1 data and get what we wanted, i.e. the outputs was as follow in the patch:
patch.data['GRD_data'] was made of
['VV', 'VH', 'localIncidenceAngle', 'scatteringData'] (in the workflow we move
shadowMask to the mask feature, hence why it’s not here).
However, now in the 0.10.1 version, our function outputs data in a different way:
- localIncidenceAngle and scatteringArea went from being in
patch.data['GRD_data']to having their own sub-features in
patch.data, cf image,
patch.data['GRD_data']only has one band, when we request both VH and VV. We have no idea what is in there. We tried comparing it to solo request (only VV or only VH), but there seems to be no ressemblance.
Here is a screen of the outputs we currently have:
I could not recreate the previous state of our S1 eopatches since going back to eolearn 0.10.0 triggers the new unit errors (for instance, the code asks for
VV data in reflectance, which obviously do not work and results in a 400 error). Here is an old screen of the outputs, which shows that only
GRD_data was a subfeature of the
data feature and that it had a shape of 4 (for
(Sorry for the shapely warning )
We looked up the changelog in both eo-learn and sentinelhub but could not link any of the changes to S1 data. We did not edit our functions, only updated the libraries versions. We really have no idea why this change happened and could not see similar experiences on the forum or on the internet at large.
Did anyone noticed that change too? Is there any explanation on the library part?
While we could easily change our post-request code to fit the new sub-features
GRD_data issue cannot be solved so easily as we have no idea what data is in there. We really are blind here.
Thank you for taking the time to read all that!