optional configuration input file

[johanvdw]

Rather than using set_input it should also be possible to create a niche model based on a configuration input file.

Both options are useful.

[stijnvanhoey]

I would combine this with a very tiny cli that provides the option to run niche from command line, using this config file, something like

niche.py config_file.txt -o outputfoldername

and a small help when no command line options.

[johanvdw]

I'm planning to implement this like this:

msw: "input/msw.asc" 
mhw: input/mhw.asc
# anything starting with # is considered a comment. Lines starting with # are ignored
soil_code:input/bodem.tif
# optional values can be left empty
inundation_vegetation:
#or can have a fixed value
rainwater: 0
# it is also possible to overwrite codetables used
ct_vegetation: new_vegetation.csv

# any other options can be specified as well
deviation: 1 # generate deviation maps
simple_model: 1 # use only mhw, mlw and soil_code
output: "c:/nicheoutput"

Which basically means I can use pandas to open the file like I do for the code tables (with comment and seperator set)

[stijnvanhoey]

Why not use a YAML document for the configuration file?

• is a more general existing 'syntax' for configuration files
• already includes the # as comments options
• provides more structure options to provides sections in the config
• you're example already seems to represent YAML anyway

name : my_model_name

input layers:
    - soil_code : ./input/bodem.tif
    - msw : ./input/msw.asc          #no quotes should be required
    - mhw : ./input/mhw.asc
    - inundation_vegetation :        # optional values can be left empty
    - rainwater: 0                       #or can have a fixed value
    - ...

code tables:
    - ct_vegetation :  new_vegetation.csv      # it is also possible to overwrite codetables used

model options:
    - deviation maps: True  # generate deviation maps
    - output maps folder:  c:/nicheoutput

@peterdesmet comments?

Some questions:

• I do not really understand the usage of your type: value? This means to use a continuous value for the layer?
• simple_model: should this not be retrieved from the way input layers are provided? Or is this an additional check?

We should proper explain the format in the documentation, see #36

P.S. if you want to store the config in a df, something like this should work (maybe looks a bit odd to use the json_normalize ;-)

import pandas as pd
import yaml

with open('nich_config.yaml', 'r') as f:
    df = pd.io.json.json_normalize(yaml.load(f))

print(df.head())

[johanvdw]

Note that for previous versions of niche these values are stored (manually I think -should check) in an excel file "parameters.xlsx"

[cecileherr]

Yes, in the previous version the user manually added the names of the input layers in the excel file.

[stijnvanhoey]

@cecileherr would you be fine to use the text format proposed here instead of the xls-file?

[johanvdw]

@stijnvanhoey - regarding your questions:

• type: value -> i have removed this
• simple_model: Just an example, but I think it makes sense to force people to specify it if they want to use it. You can copy the configuration of a full model and make it a simple model. Anyway - let's see what the users think it is easy to change.

[cecileherr]

It would be OK (or even easier) for us to use a text file, but I think we should still have some kind of GUI / front end for (some) users. An unexperienced user must also be able to see what the possible options to run NICHE Vlaanderen are and ideally find some information for each possible choice.

[peterdesmet]

Can't say much about the content of the settings file, but agree that a YAML file would be great.

[johanvdw]

@cecileherr : I created a seperate issue for the GUI.

[johanvdw]

@stijnvanhoey Disadvantage of yaml (with categories) vs simple key-value pairs is that it may be slightly harder to use for the user. Eg

input_layers:
   mhw: data/mhw_small.asc
   mlw: ../testcase/grobbendonk/mlw.asc
   soil_code: ../testcase/grobbendonk/soil_code.asc

May be valid while

input_layers:
   mhw: data/mhw_small.asc
   mlw: ../testcase/grobbendonk/mlw.asc
  soil_code: ../testcase/grobbendonk/soil_code.asc

would not be and

input_layers:
   - mhw: data/mhw_small.asc
   - mlw: ../testcase/grobbendonk/mlw.asc
   - soil_code: ../testcase/grobbendonk/soil_code.asc

Would not be either (if we decide to use dict rather than lists).

[johanvdw]

I will implement it like this anyway:

input_layers:
   mhw: data/mhw_small.asc
   mlw: ../testcase/grobbendonk/mlw.asc
   soil_code: ../testcase/grobbendonk/soil_code.asc

If it turns out to be an issue during user testing - we can still adopt with small changes. Not being sloppy on configuration file formatting can also be considered a plus.

[stijnvanhoey]

Rather hard on the file formatting with sufficient feedback to user on why things fail (+ proper examples of configuration files) than trying to capture all possibilities user potentially could define ;-)

[johanvdw]

Closed as of 3e55dc83a6bdc1e41af3bbde739bd2204e4ba9ec and previous commits.

Note that support for codetables is not yet included (#32 )