i.eodag: remove pandas dependency and save results in json/geojson files

[HamedElgizery]

This PR will:

• Remove Pandas dependency
• Add filtering with eodag crunch [1]
• Add sorting
• Add DOCSTRINGS
• Add JSON support
• Save search results as a geojson file, which can later be read by i.eodag.

Note: Reading geojson containing search results is not yet supported, and it will be addressed in a future PR.

Added filtering options:

• area_relation
• minimum_overlap
• filtering by dates (useful when reading products from a file)

Sorting parameters:

• cloudcover
• ingestiondate

Both can be set to ascending or descending.

[1] https://eodag.readthedocs.io/en/stable/api_reference/searchresult.html#crunch

[ninsbl]

Nice! Lots of useful improvements!
I added a couple of suggestions for your consideration. Feel free to reject or incorporate as you feel for it. I leave an approving review anyways...

[veroandreo]

This example or functionality does not make sense to me. If users provides a file with IDs is because they already did the search and filtering and they want to download the scenes found (i.e. IDs in the file). I cannot imagine to provide a text file with IDs and eodag doing a reverse search and filter... Is that what it does?

[HamedElgizery]

Yes, it takes the text file with a list of IDs, search for the scenes that is associated with each ID, and then it filters these founded scenes to make sure all of them satisfies the rest of the parameters.

I think a use case would be, if for example, a user did a general search (i.e. without setting the cloud coverage percentage), and then they want to pick scenes from this list of products with a certain cloud coverage percentage...

[HamedElgizery]

Anyways IMO, I can imagine that in most use cases products found by searching can be saved as a geojson file, and that geojson file can later be parsed by the module again. What is good about these geojson files, is that you don't need to do the searching again, as you already have the products ready to be downloaded after parsing the geojson file.
For reference: https://eodag.readthedocs.io/en/stable/notebooks/api_user_guide/5_serialize_deserialize.html?highlight=serialize

And for the text files it would just be a collection of IDs that is collected apart of the i.eodag module, and instead of typing them manually by hand in the shell they are just written in a text file... That is how I think it could be optimally used.

[lucadelu]

@HamedElgizery ok your explanation could make sense for me, Your idea it is not a common behaviour, people usually look for the data and later they download them. @veroandreo what do you think?

This seems the last open point before accept the pull request

[veroandreo]

I'm at a eodag workshop in FOSS4G, and now I see the potential utility of this. @HamedElgizery is this similar to what they do with the crunch functionality, that it filters a search object?

In any case, I think this can be merged.

[HamedElgizery]

Thanks for the feedback! @ninsbl @veroandreo @lucadelu

I will be adding footprint option in the next PR, because I think this one already contains off-topic additions, right?
Also I will probably be adding more qureyables for searching in the next PR, or the one after.