Is it possible to run using command line only?

[coreyryanhanson]

If we wanted to integrate AccessMod into an automated pipeline is there way to run it without dependence on the GUI? I haven't seen anything in the documentation, but thought maybe it would exist undocumented to facilitate debugging.

[nicolasray]

Hello, we are working on a command-line version of AccessMod, but it is not ready yet, and I'm not able at the moment to give you a landing date.

[fxi]

That's the replay mode, and it will be available from an interactive session within a docker process, or a detached session. We can imagine a set of CLI wrappers for python, node, or R, but currently not planned.

I use that to relaunch analysis during development, but I have to improve the experience for end users.

Here are the main steps of the current workflow in version > 5.7.20-beta :

1. Configure and launch an analysis using the GUI, e.g. with a subset of facilities. A configuration file will be written in JSON format.
2. Export the file
3. Modify the file using a text editor or a data oriented language, e.g. R/python. Possible operations:
   • Select different set of facilities
   • Update the travel scenario
   • Update scaling up tables
   • Change travel time
   • Enable/Disable options
4. Launch a replay script, like the one below, with binding to an AccessMod database, probably the same volume as the one used during the configuration creation.
5. All output are automatically saved in the DB and optionally exported in a local ./out folder as shapefiles, excel files, gpkg, csv, etc..

#!/bin/bash 
AM_VERSION=5.7.20-beta-1.0

docker run --rm -ti \
  -v $(pwd)/out:/replay/out \
  -v $(pwd)/config.json:/replay/config.json \
  fredmoser/accessmod:$AM_VERSION Rscript -e replay.R

Other examples with config files :

https://github.com/fxi/AccessMod_shiny/tree/feature/config_save_restore/replay/example

Caveats :

• Missing documentation and changing API should be expected until we reach a public release.
• Validation : config files will be hard to validate against a schema. Not sure if this will ever happen.
• Not all options are currently available, as some output layer/files names are not properly generated (yet).
• No DEM/LDC check will be applied to selected facilities in replay mode : AccessMod will produce unexpected results if some facilites are selected over cells without LDC or DEM values. This indication could be exported during config file creation – as it's computed in the GUI session – but the config file is already quite bloated.
• Probably a lot of other edge cases.

[coreyryanhanson]

This is really cool! I was exploring it a bit and had one more question. I know it's not supported, but would there be a straightforward way of me calling the R functions directly on the backend for project creation, imports, and toolbox functions (excluding the manual facility adjustment) and having the server work as intended or would the refactoring to do so be especially difficult and cumbersome?

(The reason I ask is my particular use case is a pipeline for many regions of interest and the ability to run cloudbased servers that can preprocess all of the data and run the tests simultaneously across multiple nodes.)

[fxi]

Unfortunately, calling directly R functions will not be possible with this version: there is a lot going on the reactive side of the app to handle the naming convention, spatial validation, warnings, error handling, etc..

The current process to open some parts of the tool to a docker process will most likely be the only way. Open everything will be hard. Probably better starting from scratch and migrating piece by piece.

My plan back in 2014 was to first develop a series of GRASS modules, then an API for R, then a job scheduler, then the reactive UI. This was not fully accepted and decisions were made to cut corners and produce the final app as quickly as possible and bundle it inside a VM to be able to run it on any platform, without installing anything, not even a GIS software. However, I had 6 months to produce the first beta release with 6 working modules: my initial plan was unrealistic in that time frame. But it would have been a precious investment in the long run.

[coreyryanhanson]

That makes sense. Thank you!