Table of Contents |
---|
For experts: straight to the point
Code Block | ||||
---|---|---|---|---|
| ||||
# Clone the repo: git clone git@gitlab.unige.ch:geohealth/accessmod_replay_demo.git cd accessmod_replay_demo # Launch the script: ./script.sh # Check the result: gdalinfo -stats out/1_120/raster_travel_time_original/raster_travel_time_original.img |
Step-by-step procedure
Requirements
The replay function requires a bash command to run. A language that can be used in Linux-based and Mac OS only. To use it in Windows, the easiest approach is to install a Linux-based distro from the Microsoft Store, e.g. Ubuntu 20.04 LTS, or the Windows Subsystem Linux (WSL), which is anyway required to run Docker desktop. Then, you can use the command line in this distro to run the Replay bash commands.
After installing any of the distros, there will be a short installation and activation process that will ask you to set a user name and an administrator password.
It is necessary to have Docker desktop and AccessMod installed. For instructions in how to install Docker desktop, look here, and for AccessMod, here or here.
Preparation of the files
To use the Replay function, it is necessary first to prepare the baseline data and the general analysis configuration in AccessMod.
- Start Docker desktop
- Start AccessMod
- In the left panel, go to Settings and select ‘Enable advanced options in modules’
- To prepare your configuration file, load the required layers and prepare the analysis as usual, in the selected tool. To avoid double computations, select the advanced option ‘Save analysis parameters without computing’. This will save your file names and analysis parameters in a
.JSON
configuration file. - Finally, export your individual configuration file and the whole project from AccessMod.
The Replay: files
The Replay function uses at least two files as input: the AccessMod project (.am5p
) as input data, and the configuration file (config.json
) as analysis parameters. However, its real value comes from using additional files (.json
, .
rds
, .txt
, etc.) to automatically modify the analysis parameters.
Files description
The bash file (script.sh
) acts as a coordinator of the whole process. It starts by identifying the AccessMod image, the output folder, and the files involved (.am5p
, .R
, .json
). It then checks if those files are really present, to finally proceed to run Docker with those files as input and run the R script.
Specifically the bash script calls Docker and runs commands inside a Docker container created from a specific image of AccessMod. It mounts into the container the previous input files (project.am5p
, config.json
, etc.), as well as the R script (script.R
) that includes all the instructions for the analysis. The bash script eventually calls an R session to run the R script, which uses the AccessMod project as a local database, the config.json
as information source to create a list of default parameters, as well as any additional input files as R objects that provide new parameters for the analysis. The R script also exports the results into the outputs folder (/out
), and write down a summary file (summary.json
).
Finally, the output folder (/out
) is originally an empty folder where all output results will be stored in individual folders for each sequential run according to the parameters described by theconfig.json
file in R.
Currently, all files and folders need to be in the same directory, but future modifications should allow to work on multi-project runs, keeping only the required inputs in a dedicated directory and later storing there the specific outputs.
Single use: manual update of parameters
If you are not interested in running a sequential analysis that changes parameters automatically, but instead run one or a few models, it is possible to manually modify the parameters in the config.json
file (example below), which appear as arguments ("args"
). Make any changes from a text editor such as Notepad++. In such case, it will not be necessary to include an additional input file. If the type of analysis (accessibility, geographic coverage, referral, etc.) changes, it is highly recommended to generate a new config.json
file in AccessMod.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
"args": { "inputMerged": "rLandCoverMerged__demo", "inputPop": "rPopulation__demo_patients", "inputHf": "vFacility__demo", "inputZoneAdmin": null, "outputPopResidual": "rPopulationResidual__batch", "outputHfCatchment": "vCatchment__batch", "outputPopBarrier": "rPopulationOnBarrier__batch", "outputTableCapacity": "tCapacityStat__batch", "outputTableZonal": "tZonalStat__batch", "outputSpeed": "rSpeed__batch", "outputFriction": "rFriction__batch", "typeAnalysis": "anisotropic", "knightMove": false, "removeCapted": true, "vectCatch": true, "popOnBarrier": false, "towardsFacilities": true, "radius": 5000, "maxTravelTime": 120, "maxTravelTimeOrder": 120, "useMaxSpeedMask": false, "hfIdx": "cat", "nameField": "name", "capField": "capacity", "orderField": "capacity", "ignoreCapacity": false, "addColumnPopOrigTravelTime": false, "addColumnsPopCoverageExtended": false, "zonalCoverage": false, "zoneFieldId": null, "zoneFieldLabel": null, "hfOrder": "tableOrder", "hfOrderSorting": "hfOrderDesc", "tableScenario": [ { "class": 1, "label": "Built_area", "speed": 6, "mode": "BICYCLING" }, { "class": 2, "label": "Low_dense_vegetation", "speed": 4, "mode": "WALKING" }, { "class": 3, "label": "Dense_vegetation", "speed": 2, "mode": "WALKING" }, { "class": 1001, "label": "Main road", "speed": 100, "mode": "MOTORIZED" }, { "class": 1002, "label": "Secondary", "speed": 80, "mode": "MOTORIZED" }, { "class": 1003, "label": "Tertiary", "speed": 50, "mode": "MOTORIZED" } |