3. Parameter File

The parameter file has 4 distinct sections, each of which hold parameters for a certain portion of the software.

Basic use of the parameters module is exemplified through the AequilibraE API as detailed in the Parameters module section of the use cases.

3.1. System

The system section of the parameters file holds information on things like the number of threads used in multi-threaded processes, logging and temp folders and whether we should be saving information to a log file at all, as exemplified below.

Link examples

The number of CPUs have a special behaviour defined, as follows:

  • cpus<0 : The system will use the total number logical processors MINUS the absolute value of cpus

  • cpus=0 : The system will use the total number logical processors available

  • cpus>0The system will use exactly cpus for computation, limited to

    the total number logical processors available

A few of these parameters, however, are targeted at its QGIS plugin, which is the case of the driving side and default_directory parameters.

spatialite_path is a parameter needed only by Windows users. Please refer to the instructions on how to set Spatialite on Windows.

3.2. Assignment

The assignment section of the parameter file is the smallest one, and it contains only the convergence criteria for assignment in terms of maximum number of iterations and target Relative Gap.

Link examples

Although these parameters are required to exist in the parameters file, one can override them during assignment, as detailed in Convergence criteria.

3.3. Distribution

The distribution section of the parameter file is also fairly short, as it contains only the parameters for number of maximum iterations, convergence level and maximum trip length to be applied in Iterative Proportional Fitting and synthetic gravity models, as shown below.

Link examples

3.4. Network

There are three groups of parameters under the network section: links, nodes & OSM. The first are basically responsible for the design of the network to be created in case a new project/network is to bre created from scratch, and for now each one of these groups contains only a single group of parameters called fields.

3.4.2. Node fields

The specification for node fields is similar to the one for link fields, with the key difference that it does not make sense to have fields for one or two directions and that it is not possible yet to import any tagged values from OSM at the moment, and therefore the parameter osm_source would have no effect here.

3.5. Open Street Maps

The OSM group of parameters has as its only there are further groups: modes and all_link_types.

List of key tags we will import for each mode. Description of tags can be found on Open-Street Maps, and we recommend not changing the standard parameters unless you are exactly sure of what you are doing.

For each mode to be imported there is also a mode filter to control for non-default behaviour. For example, in some cities pedestrians a generally allowed on cycleways, but they might be forbidden in specific links, which would be tagged as pedestrian:no. This feature is stored under the key mode_filter under each mode to be imported.

There is also the possibility that not all keywords for link types for the region being imported, and therefore unknown link type tags are treated as a special case for each mode, and that is controlled by the key unknown_tags in the parameters file.