Extract SAFE products without intermediate directory

Describe the bug Extraction is adding a useless subdirectory, example: extracting my_data/S2A_MSIL1C_20180619T132231_N0206_R038_T22KGV_20180619T150922.zip leads to my_data/S2A_MSIL1C_20180619T132231_N0206_R038_T22KGV_20180619T150922/S2A_MSIL1C_20180619T132231_N0206_R038_T22KGV_20180619T150922.SAFE

In order to be coherent with unzipping outside eodag, e.g. unzip S2A_MSIL1C_20180619T132231_N0206_R038_T22KGV_20180619T150922.zip, in my opinion it would be preferable to lead to my_data/S2A_MSIL1C_20180619T132231_N0206_R038_T22KGV_20180619T150922.SAFE.

[sbrunato]

@sbrunato , is there any particular reason why an intermediate directory (product.properties[title]) has to be created?

For homogeneity purpose

@sbrunato what you are saying is that it is not possible to get/build the root directory of the zip file from the search result properties?

It is possible, but for now we use f"{outputs_prefix}/{product.properties[title]}" as destination by default for all providers / product types.

This can be updated, but before we’ll have to check how it may impact other users and projects using eodag.

@floriandeboissieu we’ll keep you informed in this issue if we update this sub-directories behavior

[LucHermitte]

This can be updated, but before we’ll have to check how it may impact other users and projects using eodag.

This would definitively simplify things for S1Tiling.

We just had another request for a direct support of external products downloaded by end-users without the redundant directory. Supporting it would definitively convolute our code base to do eodag job of not downloading what is already there.