3. The AequilibraE project¶
Similarly to commercial packages, AequilibraE is moving towards having the majority of a model’s components residing inside a single file. This change is motivated by the fact that it is easier to develop and maintain documentation for models if they are kept in a format that favors data integrity and that supports a variety of data types and uses.
Note
As of now, only projection WGS84, 4326 is supported in AequilibraE. Generalization is not guaranteed, but should come with time.
The chosen format for AequilibraE is SQLite, with all the GIS capability supported by SpatiaLite. The impressive performance, portability, self containment and open-source character of these two pieces of software, along with their large user base and wide industry support make them solid options to be AequilibraE’s data backend. Since working with Spatialite is not just a matter of pip installing a package, please refer to Dependencies.
Note
This portion of AequilibraE is under intense development, and important changes to the project structure and the API should be expected until at least version 0.7.X. Versions 0.8 and beyond should see a much more stable API, with new capabilities being incorporated in each release.
3.1. Project structure¶
Since version 0.7, the AequilibraE project consists of a main folder, where a series of files and sub folders exist. The files are the following:
project_database.sqlite - Main project file, containing network and data tables for the project
results_database.sqlite - Database containing outputs for all algorithms such as those resulting from traffic assignment
parameters.yml - Contains parameters for all parameterized AequilibraE procedures
matrices (folder) - Contains all matrices to be used within a project
scenarios (folder) - Contains copies of each project_database.sqlite at the time a certain scenario was saved (upcoming in version 0.8)
3.2. Data consistency¶
One of the key characteristics of any modelling platform is the ability of the supporting software to maintain internal data consistency. Network data consistency is surely the most critical and complex aspect of overall data consistency, which has been introduced in the AequilibraE framework with TranspoNET, where Andrew O’Brien implemented link-node consistency infrastructure in the form of spatialite triggers.
Further data consistency, especially for tabular data, is also necessary. This need has been largely addressed in version 0.7, but more triggers will most likely be added in upcoming versions.
All consistency triggers/procedures are discussed in parallel with the features they implement.
3.3. Dealing with Geometries¶
Geometry is a key feature when dealing with transportation infrastructure and actual travel. For this reason, all datasets in AequilibraE that correspond to elements with physical GIS representation are geo-enabled.
This also means that the AequilibraE API needs to provide an interface to manipulate each element’s geometry in a convenient way. This is done using the wonderful Shapely, and we urge you to study its comprehensive API before attempting to edit a feature’s geometry in memory.
As AequilibraE is based on Spatialite, the user is also welcome to use its powerful tools to manipulate your model’s geometries, although that is not recommended, as the “training wheels are off”.
3.4. Project database¶
3.5. Parameters file¶
3.5.2. Extra user data fields¶
The AequilibraE standard configuration is not particularly minimalist, but it is reasonable to expect that users would require further data fields in one or more of the data tables that are part of the AequilibraE project. For this reason, and to incentivate the creation of a consistent culture around the handling of model data in aequilibrae, we have added 10 additional data fields to each table which are not used by AequilibraE’s standard configuration, all of which are named as Greek letters. They are the following:
‘alpha’
‘beta’
‘gamma’
‘delta’
‘epsilon’
‘zeta’
‘iota’
‘sigma’
‘phi’
‘tau’