Implement algorithms tab of the plugin dock

[ricardogsilva]

The plugin dock has an Algorithms tab. This is meant to be the primary place where users can discover and run Trends.Earth algorithms.

As seen on the mockup above, the algorithms section shows a list of available algorithms which can be used for generating multiple SDG-related indicators. The list is organized with a three-level hierarchical structure:

• The first level is the group of each algorithm
• The second level has the name of the algorithm and a button to execute it. Depending on the algorithm, the Run button may be compound, with a main action that allows running with custom data. The secondary action shall allow running with the default UNCCD datasets. Algorithms that can only run using remote data shall show a normal button. This shall serve as a hint to the user that using own data is now the preferred execution method
• The third level has a brief description about the algorithm and a link to more information

Algorithms shall primarily be grouped in accordance with their respective SDG.

There may also be other groups, to show beta algorithms or some other related categories. These shall be shown last on the list, in order to indicate to the user that their relevance is lower

Clicking on one of the Run buttons shall open an additional dialogue that allows parametrizing and running the relevant algorithm (which will be the subject of additional issues)

Notes

• Some algorithms may execute only locally (with the user's own datasets), some may execute only remotely (using Trends.Earth default datasets), some may be able to execute either locally or remotely, depending on the user's choice. This information shall be conveyed in the GUI by doing the following:

  • If the algorithm only runs locally or only runs remotely, the algorithm list shall show a normal Run button that will cause its algorithm execution dialogue to open
  • If the algorithm may run either locally or remotely, the algorithm list shall show a compound button, with the primary action being Run to run the algorithm locally. The secondary action shall be Run with default data and it will allow running the algorithm remotely

• Lets introduce a class to model algorithms groups. This shall have at least the following properties:

  • name: str - Human friendly name of the group, to be shown on the GUI. Example: Proportion of land that is degraded over total land area
  • name_detail: typing.Optional[str] - An optional further detail about the group, to be shown on the GUI after the name, enclosed in brackets. Example: SDG 15.3.1

• Lets also introduce (or improve upon, if it is there already) a class to model algorithms. This shall have at least the following properties:

  • group: AlgorithmGroup - group that the algorithm belongs to. Shall be an instance of the class described in the previous point
  • runs_locally: bool - boolean that specifies that the algorithm can be run locally, with user supplied datasets. This shall be used by the GUI in order to build the algorithm's run action
  • runs_remotely: bool - boolean that specifies that the algorithm can be run remotely, with Trends.Earth default datasets. This shall be used by the GUI in order to build the algorithm's run action
  • name: str - Human friendly name of the algorithm, to be shown on the GUI. Example: Land Productivity
  • name_detail: typing.Optional[str] - An optional further detail about the name of the algorithm that will be shown on the GUI after the name, enclosed in brackets. Example: sub-indicator 1
  • brief_description: str - Brief description of the algorithm. One or two paragraphs of text max. This shall be shown as the third level of the algorithms list on the GUI.
  • description: str - Longer description about the algorithm, with enough text to help the user configure the algorithm parameters in order to produce suitable results. This shall be shown on the algorithm execution dialogue.

[luipir]

FYI @ricardogsilva No algorithm class seems available in the plugin code. all algorithm presence in tight with he GUI or linked to a specific calculate_\<alg short name>.py code => proceed to create Algorithm class.

[azvoleff]

@luipir - correct, there isn't currently an algorithm class, though agree with this proposed improvement - sorely needed!

And apologies if I missed this elsewhere, but assume a dataset class will be added as well? This will be needed for #371, as well as for this class - I'd add a dependencies or similar property to the algorithm class that would allow specifying a list of dataset dependencies for a particular algorithm. Some of the current algorithms need to be run in sequence as they depend on outputs of prior algorithms