Currently, Stride either reads a population (without location data) from a .csv file, or generates a population (with location data) from an .xml model without saving it anywhere.
I’m planning to polish this a bit more before the beta:
Our evaluators seemed interested in saving generated populations to a file. Conceptually, they’d consist of such a .csv file together with a serialization of the generated Atlas. Similarly, by specifying a .csv input and an .atlas input to go with it, we should be able to run a pre-generated population with geo data attached to it for the visualizer to render.
Maybe the selection based on file format is a bit of a hack — I did it that way because it was easiest back when I wasn’t familiar with much of the Stride code and everything was ugly. Populations and their models shouldn’t be stored under the same XML path. Users should specify one of the following sets of keys in a run config:
population_model, geodistribution_profile, and reference_households, to generate a population and use it without saving it to disk.
The above, plus population_output and atlas_output, to save the generated population before running. (Maybe skip generation and read from these files if they exist? Is that useful or obtrusive?)
population_file, to run from an old-style .csv population file.
population_file and atlas_file, to run from a population file whose clusters have visualizable geographic data.
I think this should help make the user interface to the generator feel polished enough for release! :)
Currently, Stride either reads a population (without location data) from a
.csvfile, or generates a population (with location data) from an.xmlmodel without saving it anywhere.I’m planning to polish this a bit more before the beta:
Our evaluators seemed interested in saving generated populations to a file. Conceptually, they’d consist of such a
.csvfile together with a serialization of the generatedAtlas. Similarly, by specifying a.csvinput and an.atlasinput to go with it, we should be able to run a pre-generated population with geo data attached to it for the visualizer to render.Maybe the selection based on file format is a bit of a hack — I did it that way because it was easiest back when I wasn’t familiar with much of the Stride code and everything was ugly. Populations and their models shouldn’t be stored under the same XML path. Users should specify one of the following sets of keys in a run config:
population_model,geodistribution_profile, andreference_households, to generate a population and use it without saving it to disk.population_outputandatlas_output, to save the generated population before running. (Maybe skip generation and read from these files if they exist? Is that useful or obtrusive?)population_file, to run from an old-style.csvpopulation file.population_fileandatlas_file, to run from a population file whose clusters have visualizable geographic data.I think this should help make the user interface to the generator feel polished enough for release! :)