Network Checking

Network Checking#

The network checking module is meant to be run before every Polaris model run if the network has been edited in any way since its last successful run.

Got a problem that the checker didn’t catch? Report it!!

This module includes many types of network checks, which are best grouped in three different sets, classified by the type of analysis and its implication for model running, as some of these will result in model crashes while others might have only a slight (and not necessarily known) effect on model results.

Doing a full model check can be done with just a couple lines of code, as shown below.

# We open the network
from polaris.network.network import Network
n = Network()
n.open(source)

# We get the checker for this network
checker = n.checker

# Run all checks
checker.complete_analysis()

Or you can run one by one.

checker.structure_check()
checker.critical()
checker.connections_table()
checker.consistency_tests()
checker.connectivity_walk()
checker.connectivity_auto()
checker.connectivity_transit()
checker.deep_analysis()

Regardless of how one choose to run the tests, one can retrieve the results of issues found for each existing issue in two different ways. In aggregate:

analysis_result = checker.errors # type: dict

If one ones to perform only a partial network check, the different types are described below.

Check types#

Database structure#

The first type of network check is the analysis of the database structure, where we detect any tables or table fields missing in our database, and that is done without relying on flags or other shortcuts.

Critical checks#

The second type of verification is consistency checks, where we run a series of checks on the supply model data itself in search of inconsistencies such as:

Missing data (NULLs/EMPTY)
Discrepancies in data from different tables
Data values known to cause issues during model runs

It should be noted that most of these checks have been identified as causes for model failure, so it is crucial that any new cause for model crash identified is reported for inclusion in this check suite.

There is a large number of conditions that, when exist, cause Polaris to crash. Many of these conditions can be formulated as simple queries for which a non-empty result would mean an error, so it was natural to structure such checks as a series of queries, which are listed below.

We check for the existence of:

Links with positive lanes_ab and zero fspd_ab (same for ba)
Links with positive cap_ab and zero lanes_ab (same for ba)
Links with positive fspd_ab and zero lanes_ab (same for ba)
Links with zero lanes for both directions
Transit_Pattern_Mappings referencing links that do not exist int the network
Zones with no locations associated to it
Locations with NULL for zone
Locations with NULL for link
Locations with NULL for walk_link
Locations with non-existing walk_link
Parkings with NULL for zone
Parkings with NULL for link
Parkings with NULL for walk_link
Parkings with non-existing walk_link
Transit_Stops with NULL for zone
ev_charging_stations with NULL for zone
Node with NULL for zone
Zones with zero locations
Locations with no corresponding records on Location_Links
Signal phase with zero movements
Signal with no nested records associated to them
Signals timings with cycle equal zero
Nodes in the road network that have zero lanes arriving on it
Nodes in the road network that have zero lanes departing from it

Consistency tests#

Links with speed higher than 120kph (in either direction)

Connections Table#

The checker module also has a suite of procedures to check the connections table, which searches for inaccuracies such too many links connected to a single node pockets not used int the connections table or lanes not connected to any other link at an intersection.

checker.connections_table()

Its results are attached to the full report mentioned above.

Network connectivity#

The third type of test consists of a a series of connectivity done at different levels of precision in order to determine whether the network is fully connected.

Due to the specific (and complex) nature of the path finding algorithms used in Polaris, this connectivity analysis is done in a simplified manner for the transit and roadway networks and in a rather precise way for the walk network.

As tests are run, error messages will be shown will be logged, and therefore printed to terminal and saved to to the logfile saved in the user’s temp folder.

For specific analysis results on network connectivity (more complex results):

#To get the results of the connectivity tests it is possible to do the following
checker.get_disconnected_transit_nodes()
print(checker.errors)

checker.get_disconnected_walk_nodes()
print(checker.errors)

Deep analysis#

Finally, the checker module also has a suite of procedures for detailed network analysis that is targeted at refining the network in search for inaccuracies, such as intersections with too many approximations

checker.deep_analysis()