Drop-down selection for some parameters

[jsbrittain]

Is your feature request related to a problem? Please describe. I would like to be able to define parameters that only accept certain inputs; this can include validation, but a prefered option would be restricting values to a list of predetermined options.

Describe the solution you'd like Drop-down option for some parameters;

Describe alternatives you've considered N/A

Additional context

[jsbrittain]

Any implementation would need to load the available options as part of the configuration, or as a link to another source (such as a file stored as part of the module payload). Incoporating the full parameter list as part of the 'params' substructure keeps meta-data with value data, but complicates config readouts in the Snakefile's, introduces backwards compatibility issues, and/or would require additional logic at run-time. An alternative implementation would be to add meta-data separate to the 'params' sub-structure in the config file. A viable parameters structure (placed at the same level as the intended structure uses a ':'-prepend, such as ':params'. This has been trialled as follows:

input_namespace: in
output_namespace: out
params:
  "Dataset": "APHRODITE Daily mean temperature product (V1808)"
  "Admin Level": "1"
  "Year": ""
  "Resolution Type": "ppp"
  "Country (ISO3)": "VNM"
  "Options": ""
:params:
  "Dataset":
    type: select
    options:
      - "APHRODITE Daily mean temperature product (V1808)"
      - "APHRODITE Daily accumulated precipitation (V1901)"
      - "CHIRPS: Rainfall Estimates from Rain Gauge and Satellite Observations"
      - "TerraClimate gridded temperature, precipitation, and other"
      - "ERA5 atmospheric reanalysis"
      - "WorldPop population density"
      - "WorldPop population count"
      - "GADM administrative map"
    required: true
  "Resolution Type":
    type: select
    options:
      - ppp
      - pph
    required: true

Although this separates meta-data from values, the paired 'params'-':params' structure allows meta-data to be associated with any named structure, allows ':'-tagged meta-data to be rescinded from the user interface, and should be extendable to hierarchical modules. Furthermore, the 'options' sub-label could be replaced with a 'file location' if reading is to be performed from file.

[jsbrittain]

A subtle modification of the above extends the colon-notation to any field, instead of requiring a parent structure:

input_namespace: in
output_namespace: out
params:
  "Dataset": "APHRODITE Daily mean temperature product (V1808)"
  ":Dataset":
    type: select
    options:
      - "APHRODITE Daily mean temperature product (V1808)"
      - "APHRODITE Daily accumulated precipitation (V1901)"
      - "CHIRPS: Rainfall Estimates from Rain Gauge and Satellite Observations"
    required: true
  "Resolution Type": "ppp"
  :"Resolution Type":
    type: select
    options:
      - ppp
      - pph
    required: true

Note the use of two different syntax examples which are not equivalent. The first, ":Dataset", can be accessed in the snakefile as config['params'][':Dataset'], while :"Resolution Type" wraps an additional string and can be accessed as config['params'][':"Resolution Type"]. Of course, the intent is that these are not directly referenced in the Snakefile, and instead managed by grapevne. Without quotes these two forms are equivalent (e.g. :params). With quotes there is a dependency on which quotes are used, since :"Resolution Type" is not equivalent to :'Resolution Type'. For this reason my preference is for the former.

The disadvantage of this approach is that data and metadata are still not retained in the same structure (can potentially diverge), and the config file becomes less clean to read outside of grapevne.

Some potential metadata markers are:

• Single symbol delineator, e.g. ":Dataset", "_Dataset", etc.
• Wrapped symbol delineator, e.g. ":Dataset:", "_Dataset_", etc.
• Implicit structure, e.g. "Dataset [options]", although these are more likely to clash with user specifications

[jsbrittain]

Dropdown list support could also help resolve software version selection, as mentioned here: https://github.com/kraemer-lab/vneyard/pull/9