3.4.2. Network

Note

This documentation, as well as the SQL code it referred to, comes from the seminal work done in TranspoNet by Pedro and Andrew.

The objectives of developing a network format for AequilibraE are to provide the users a seamless integration between network data and transportation modeling algorithms and to allow users to easily edit such networks in any GIS platform they’d like, while ensuring consistency between network components, namely links and nodes.

As mentioned in other sections of this documentation, the AequilibraE network file is composed by a links and a nodes layer that are kept consistent with each other through the use of database triggers, and the network can therefore be edited in any GIS platform or programatically in any fashion, as these triggers will ensure that the two layers are kept compatible with each other by either making other changes to the layers or preventing the changes.

Although the behaviour of these trigger is expected to be mostly intuitive to anybody used to editing transportation networks within commercial modeling platforms, we have detailed the behaviour for all different network changes in Change behavior .

This implementation choice is not, however, free of caveats. Due to technological limitations of SQLite, some of the desired behaviors identified in Change behavior cannot be implemented, but such caveats do not impact the usefulness of this implementation or its robustness in face of minimally careful use of the tool.

Note

AequilibraE does not currently support turn penalties and/or bans. Their implementation requires a complete overahaul of the path-building code, so that is still a long-term goal, barred specific developed efforts.

3.4.2.1. Network Fields

As described in the The AequilibraE project the AequilibraE network is composed of two layers (links and nodes), detailed below.

3.4.2.1.2. Nodes

The nodes table only has four mandatory fields as of now: node_id, which are directly linked to a_node and b_node in the links table through a series of database triggers, is_centroid, which is a binary 1/0 value identifying nodes as centroids (1) or not (0).

The fields for modes and link_types are linked to the modes and link_type fields from the links layer through a series of triggers, and cannot be safely edited by the user (nor there is reason for such).

Field name

Field Description

Data Type

node_id

Unique identifier. Tied to the link table’s a_node & b_node

Integer (32/64 bits)

is_centroid

node_id of the first (topologically) node of the link

Integer (32/64 bits)

modes

Concatenation of all mode_ids of all links connected to the node

String

link_types

Concatenation of all link_type_ids of all links connected to the node

String

As it is the case for the lin k layer, the user is welcome to add new fields directly to the database, but we recommend using the API.

Note

It is good practice when working with the sqlite to keep all field names without spaces and all lowercase. SPACES AND NUMBERS IN THE FIELD NAMES ARE NOT SUPPORTED

3.4.2.1.3. Future components

  1. Turn penalties/restrictions

  2. Transit routes

  3. Transit stops

3.4.2.2. Importing from Open Street Maps

Please review the information Open Streeet Maps

Note

ALL links that cannot be imported due to errors in the SQL insert statements are written to the log file with error message AND the SQL statement itself, and therefore errors in import can be analyzed for re-downloading or fixed by re-running the failed SQL statements after manual fixing

3.4.2.2.1. Python limitations

As it happens in other cases, Python’s usual implementation of SQLite is incomplete, and does not include R-Tree, a key extension used by Spatialite for GIS operations.

For this reason, AequilibraE’s default option when importing a network from OSM is to NOT create spatial indices, which renders the network consistency triggers useless.

If you are using a vanilla Python installation (your case if you are not sure), you can import the network without creating indices, as shown below.

from aequilibrae.project import Project

p = Project()
p.new('path/to/project/new/folder')
p.network.create_from_osm(place_name='my favorite place')
p.conn.close()

And then manually add the spatial index on QGIS by adding both links and nodes layers to the canvas, and selecting properties and clicking on create spatial index for each layer at a time. This action automatically saves the spatial indices to the sqlite database.

Adding Spatial indices with QGIS

If you are an expert user and made sure your Python installation was compiled against a complete SQLite set of extensions, then go ahead an import the network with the option for creating such indices.

from aequilibrae.project import Project

p = Project()
p.new('path/to/project/new/folder/')
p.network.create_from_osm(place_name='my favorite place', spatial_index=True)
p.conn.close()

If you want to learn a little more about this topic, you can access this blog post or the SQLite page on R-Tree.

If you want to take a stab at solving your SQLite/SpatiaLite problem permanently, take a look at this OTHER BLOG POST.

Please also note that the network consistency triggers will NOT work before spatial indices have been created and/or if the editing is being done on a platform that does not support both RTree and Spatialite.

3.4.2.3. Network consistency behaviour

In order for the implementation of this standard to be successful, it is necessary to map all the possible user-driven changes to the underlying data and the behavior the SQLite database needs to demonstrate in order to maintain consistency of the data. The detailed expected behavior is detailed below. As each item in the network is edited, a series of checks and changes to other components are necessary in order to keep the network as a whole consistent. In this section we list all the possible physical (geometrical) changes to each element of the network and what behavior (consequences) we expect from each one of these changes. Our implementation, in the form of a SQLite database, will be referred to as network from this point on.

Ensuring data consistency as each portion of the data is edited is a two part problem:

  1. Knowing what to do when a certain edit is attempted by the user

  2. Automatically applying the tests and consistency checks (and changes) required on one

3.4.2.3.1. Change behavior

In this section we present the mapping of all meaningful changes that a user can do to each part of the transportation network, doing so for each element of the transportation network.

3.4.2.3.1.1. Node layer changes and expected behavior

There are 6 possible changes envisioned for the network nodes layer, being 3 of geographic nature and 3 of data-only nature. The possible variations for each change are also discussed, and all the points where alternative behavior is conceivable are also explored.

3.4.2.3.1.1.1. Creating a node

There are only three situations when a node is to be created: - Placement of a link extremity (new or moved) at a position where no node already exists - Spliting a link in the middle - Creation of a centroid for later connection to the network

In both cases a unique node ID needs to be generated for the new node, and all other node fields should be empty An alternative behavior would be to allow the user to create nodes with no attached links. Although this would not result in inconsistent networks for traffic and transit assignments, this behavior would not be considered valid. All other edits that result in the creation of un-connected nodes or that result in such case should result in an error that prevents such operation

Behavior regarding the fields regarding modes and link types is discussed in their respective table descriptions

3.4.2.3.1.1.2. Deleting a node

Deleting a node is only allowed in two situations: - No link is connected to such node (in this case, the deletion of the node should be handled automatically when no link is left connected to such node) - When only two links are connected to such node. In this case, those two links will be merged, and a standard operation for computing the value of each field will be applied.

For simplicity, the operations are: Weighted average for all numeric fields, copying the fields from the longest link for all non-numeric fields. Length is to be recomputed in the native distance measure of distance for the projection being used.

A node can only be eliminated as a consequence of all links that terminated/ originated at it being eliminated. If the user tries to delete a node, the network should return an error and not perform such operation.

Behavior regarding the fields regarding modes and link types is discussed in their respective table descriptions

3.4.2.3.1.1.3. Moving a node

There are two possibilities for moving a node: Moving to an empty space, and moving on top of another node.

  • If a node is moved to an empty space

All links originated/ending at that node will have its shape altered to conform to that new node position and keep the network connected. The alteration of the link happens only by changing the Latitude and Longitude of the link extremity associated with that node.

  • If a node is moved on top of another node

All the links that connected to the node on the bottom have their extremities switched to the node on top The node on the bottom gets eliminated as a consequence of the behavior listed on Deleting a node

Behavior regarding the fields regarding modes and link types is discussed in their respective table descriptions

3.4.2.3.1.1.4. Adding a data field

No consistency check is needed other than ensuring that no repeated data field names exist

3.4.2.3.1.1.5. Deleting a data field

If the data field whose attempted deletion is mandatory, the network should return an error and not perform such operation. Otherwise the operation can be performed.

3.4.2.3.1.1.6. Modifying a data entry

If the field being edited is the node_id field, then all the related tables need to be edited as well (e.g. a_b and b_node in the link layer, the node_id tagged to turn restrictions and to transit stops)

3.4.2.3.1.3. Field-specific data consistency

Some data fields are specially

3.4.2.3.1.3.5. a_node and b_node

The user should not change the a_node and b_node fields, as they are controlled by the triggers that govern the consistency between links and nodes. It is not possible to enforce that users do not change these two fields, as it is not possible to choose the trigger application sequence in SQLite

3.4.2.4. Projection

Although GIS technology allows for a number of different projections to be used in pretty much any platform, we have decided to have all AequilibraE’s project using a single projection, WGS84 - CRS 4326.

This should not affect users too much, as GIS platforms allow for on-the-fly reprojection for mapping purposes.

# 4 References http://tfresource.org/Category:Transportation_networks

# 5 Authors

## Pedro Camargo - www.xl-optim.com -