i.eodag: add query, print, and footprints options

[HamedElgizery]

• Add query option, from which one can set extra querayables for searching.

• Add print option to allow printing of the following in JSON format:

  • Current EODAG configuration.
  • Available products.
  • Available products for a given provider.
  • Available providers.
  • Available providers offering a specific product.
  • Queryables for a given provider and/or product.

Note: Queryables from the above list can then be used in the query option.

• Add foorprints option to allow saving the scenes in a single combined footprint vector map.

[veroandreo]

I left some comments and questions regarding flags and footprint option. Also, several docstrings have the "EO products to be sorted" as parameter description, it doesn't seem right in all cases, it is maybe a left over of copy-pasting, please have a look.

Also some more use cases and examples would be desirable in the html

[veroandreo]

What is the message here? I do not understand

[HamedElgizery]

What I am trying to convey is that if you are able to use one of the provided i.eodag options e.g. start, end, producttype, provider, etc... Then you should use them instead of passing them through the query option, because they might cause unexpected problems.

Shall I just type this, if it is more clear? or is it too wordy?

[ecodiv]

If I understand right, this option is to use searching parameters not provided for by the other filter parameters? Perhaps turning it around:

"Query using extra searching (filter?) parameters not provided for by the provided filter options"

Would it be possible to check if the user uses query parameters that are already available as parameter option, and issue a warning if the user uses these parameters?

[ninsbl]

This dhould be made clear in the manual...

[ninsbl]

Currently, I have to review on a mobile phone, which is somewhat limiting. So, i may have overlooked something. Anyway, please see my comments in the code...

[veroandreo]

I've just tested different use cases. In generally, it works as expected, except for the query option. I tried with OrbitDirection and start, but nothing gets filtered really with those... so, I'm not sure it actually works or how it is supposed to work (the queryables for S2 will return mostly the same values, because they are like organization, instrument and so on...). Perhaps if multiple products are passed to producttype, it makes more sense??

This is what I tried with queryables:

i.eodag -l start=2022-05-01 end=2022-06-01 clouds=50 producttype=S2_MSI_L2A provider=cop_dataspace query="start=2022-05-20"

i.eodag.py -l start=2022-05-01 end=2022-06-01 clouds=50 producttype=S2_MSI_L2A provider=cop_dataspace query="orbitDirection=DESCENDING"

Try with and without the query option in NC project with this region setting:

n=228510
s=214980
w=630000
e=645000

In general, I'm in to merge this one as it got too long already (maybe smaller PRs are easier to review and test), and if there's something else to fix, create a new PR.

[ninsbl]

I think the additional queryables need to be used in the crunch function on the returned initial surchresults, not during initial surch.

As for implementing the queriables, please consider the different operators and possible use of multiple values. Please double check also my earlier suggestions.

[ninsbl]

I agree with @veroandreo that we should merge and then improve from the current state.

I still think that however, that extraction and deletion of archives is more appropriately implemented with flags. In any case, if a settings file gets priority over options/flags should be made clear in the manual...

A next step should be to add test cases that do not require login credentials, like for printing, filtering and so on..

[HamedElgizery]

I've just tested different use cases. In generally, it works as expected, except for the query option. I tried with OrbitDirection and start, but nothing gets filtered really with those... so, I'm not sure it actually works or how it is supposed to work (the queryables for S2 will return mostly the same values, because they are like organization, instrument and so on...).

Thanks for the testing! I am currently working on fixing the issue.

In general, I'm in to merge this one as it got too long already (maybe smaller PRs are easier to review and test), and if there's something else to fix, create a new PR.

Makes sense, I will be pushing the fix on the next PR if we agree on that, which will also extend on the current query functionality.