eodag icon indicating copy to clipboard operation
eodag copied to clipboard

Make the product's catalog more visible

Open maximlt opened this issue 5 years ago • 6 comments

I've just had the case of a user who didn't know a product type was made available by eodag. The new website (#233) will display the content of product_types.yml in one of the sections of the Getting Started. However, this still won't be so easy to find or to browse. eodag list or dag.list_product_types() return the content of the YAML file, but this is also not so easy to explore.

I was thinking that we could have a script to generate a nicely formatted HTML page of this catalog. We could generate it during the docs build and link it or embed it in the documentation. We could also generate this HTML the first time EODataAccessGateway is instantiated (like the whoosh index or the default configuration file) and have a method to open that page in a browser (e.g. dag.open_product_catalog()).

This would allow users to:

  • Easily see the products that are made available directly by eodag
  • Find the product's identifier eodag uses (e.g. S2_MSI_L1C)

For each product, we could add the list of providers that make it available.

maximlt avatar Apr 20 '21 09:04 maximlt

It would also be nice in this catalog to display somewhere which extra kwargs (coined as queryable internally) can be passed to a provider for a given product (e.g. cloudCover).

maximlt avatar Apr 21 '21 06:04 maximlt

we could have a script to generate a nicely formatted HTML page of this catalog. We could generate it during the docs build and link it or embed it in the documentation

Yes, this would would be a useful information to put in the documentation

have a method to open that page in a browser

I am not sure if this would be a good idea to make a method open the documentation using the browser. We can discuss about it later. Do you know other python libraries having this kind of method ?

It would also be nice in this catalog to display somewhere which extra kwargs (coined as queryable internally) can be passed to a provider for a given product (e.g. cloudCover).

This information can be found in https://eodag.readthedocs.io/en/latest/_static/params_mapping_opensearch.csv. We can summarize it and also build a table to display in the doc using the CI like for product types

sbrunato avatar Apr 21 '21 09:04 sbrunato

This information can be found in https://eodag.readthedocs.io/en/latest/_static/params_mapping_opensearch.csv. We can summarize it and also build a table to display in the doc using the CI like for product types

Oh thanks now I understand why this file is generated ! :D It's super useful information :+1:

I am not sure if this would be a good idea to make a method open the documentation using the browser. We can discuss about it later. Do you know other python libraries having this kind of method ?

Hmm no I don't know any package that does that. I've used tools however that automatically open their results after a process in the browser. And to be clear, I was not thinking about opening the documentation website, but rather directly the HTML page (product's catalog) that would be shipped with eodag. I'm thinking about that because I find that I open quite often the product_types.yml file to look for a product (e.g. find the ID used by eodag).

maximlt avatar Apr 21 '21 09:04 maximlt

Hello. It's been a while :). When I was working on the project, I was always kind of annoyed by the product type id knowledge overhead needed to get started with eodag. I always tought it would be great if eodag can be smart enough to allow the users (at least in the CLI) to input whatever keyword they think could direct them to the right EO product (e.g: satellite name, mission name, instrument name, tags like infrared, visible, etc.) instead of something like say, S2_MSI_L1C. Maybe a poll on how users (experts and novices alike) like to search for EO products could help with this?

aoyono avatar Jul 09 '21 09:07 aoyono

Hi @aoyono , glad to see your message! And also, thanks for the suggestion.

That is true that the product type may be something not so easy to handle : it can be named differently between eodag, one provider, or another one.

There already exist the "guess product type" functionality. Is is documented here https://eodag.readthedocs.io/en/latest/notebooks/api_user_guide/4_search.html#Guess-a-product-type (It might need an example to be more clear).

We may also add some more examples in the documentation to show how to use it, like:

eodag search --platform SENTINEL2 --processingLevel L1 --box 1 43 2 44 --start 2021-03-01 --end 2021-03-31

It is also related to #165 to have some keywords to describe product types, and query them

sbrunato avatar Jul 09 '21 10:07 sbrunato

Yes, the guess_product_type was an attempt to achieve that. It would definitely help to gather the EO community thoughts somewhere to enhance it.

aoyono avatar Jul 09 '21 10:07 aoyono

  • [x] Make a new script like utils/params_mapping_to_csv.py that will generate a csv file with:

    • available product types as rows,
    • product types metadata (abstract, platform, etc.) and providers as columns (fill the table and mark available when a product type is configured for a provider, nothing if it is not)
  • [x] run the script through tox, like it is done for params_mapping_to_csv.py

  • [x] display the table like parameters supported by providers in the page EO product types

  • [x] check https://sphinxcontrib-needs.readthedocs.io/en/latest/directives/needtable.html to display an advanced table using datatables style for filtering and columns show/hide

sbrunato avatar Nov 08 '22 12:11 sbrunato