jrawbits
commented
2 years ago This implicates a larger issue with input files: we're very much attached to .csv files as the input medium, and it will be very difficult to change that flexibly (e.g. all the module specifications for input files would need to be "genericized").
A better solution (implied in at least one other issue current as of 1/2022) might be to create some input setup and validation tools that can extract geographic data or other sources into the required .csv inputs (and let people flexibly map their locally maintained data in their database of choice across to the .csv inputs with a certain amount of completeness and consistency checking). The idea would be to set up table/field correspondences between the user's database and the .csv files, use that to read the database, perform consistency checks, and then write the .csv input files. We would need to make the target model (VERSPM) a parameter as well (because that sets Units and Geography, as well as the list of modules that require inputs).
That further suggests making the input processor a VEModel function. So we can open a model, give it the database correspondence table, and have it pump out the .csv input files for the model from the database, with consistency/error checking based on each module's Initialize module function (as in #20 or #106). In the same way that opening a model with VEModel currently (3.0) runs the framework's "parse module" functionality without running the model, we could have this input preparation function work with the model's run scripts and the individual module's initialize functions to head off problems as the user is preparing data, without running the model (and also have it skip loading from another data source and just look at what is currently in the user's input folder).
Various inputs require estimates of acres in Bzones (and consistent zone structures). Change how that data is supplied (optionally) so users can directly supply data in spatial formats as model inputs.