Editing and consistency

Editing and consistency#

Differently from the previous Polaris network editor, this new version separates the several needed editing features in three different groups based on their implementation.

  1. Trigger-based, always-on, editing features

  2. Manually-trigger editing

  3. Available only in the QGIS interface

Hands-on in a nutshell#

There are three possible scenarios for network editing:

  1. Editing the network after opening it with the QGIS plugin (with gracious shutdown)

  2. Editing the network using the Python library (with gracious shutdown)

  3. All other cases

Cases 1 and 2 result in continuous internal consistency for the network, and if your editing networks falls within the 3rd case, just open the network with the Python plugin or with the QGIS plugin and things will be taken care for you.

Editing tools#

The main idea of this new network editing framework is to leverage the GIS editing and visualization capabilities of specialized soft5ware (i.e. QGIS), instead of re-implementing them for the sole purpose of editing Polaris Networks.

In that sense, the design goal for this tool is to allow the user to use the GIS or database manipulation tool of their choice for their regular network editing tasks and to ensure internal network consistency. Ideally, enforcing internal consistency would be done entirely through the use of database triggers, which would result in a “virtually incorruptible” network.

The challenge of creating a network editing piece of software based solely on database tools is not trivial, but it mostly possible. However, SQLite does not have the necessary trigger capabilities of full-blown databases required for a sensible implementation. As a consequence, operations like updating the walk_link for locations and parkings in the event of a deletion in the Transit_Walk table results can take up to a whole second per update, making it inadequate for implementation as a trigger.

For this reason, internal network consistency is ensured through a mix of database triggers and Python code. On that note, there are two types of database triggers. The first type is the one that executes required changes to the database at the time an edit occurs (e.g. adds new nodes to the network when a new link is added to the network when required), and the second type of trigger records the changes executed to a backlog so an external tool (this Python package) can identify such changes and execute the required changes to the network.

This backlog is implemented as a table called editing_table in the standard model database.

Executing changes in the backlog#

Following the principle of enforcing internal network consistency without the need for user intervention, processing the backlog is done with by simply opening that network with this package.

from polaris.network.network import Network

net = Network()
net.open('path/to/file')
net.close()

It is also possible not to process the list of edits in the queue when opening a database (below), but that is strongly advised against.

from polaris.network.network import Network

net = Network()
net.open('path/to/file', process_backlog=False)
net.close()

Internal network consistency#

Here we list all behaviors covered by the junction grouped by the table where consequential changes happen, the type of change and by the type of consistency mechanism (instant change or creation of a backlog).

EV_Charging_Stations#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter Latitude

Enforces Y from geo

.

Latitude

Alter Longitude

Enforces X from geo

.

Longitude

Deletes a charging station

Deletes corresponding records from EV_Charging_Station_Plugs and EV_Charging_Station_Plugs

.

Location#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter X/geo

Enforces X from geo

.

x

Alter Y/geo

Enforces Y from geo

.

y

Alter setback/geo

Enforces setback from geo/link

.

setback

Alter Zone/geo

Recomputes from geo

.

zone

Alter area_type

Recomputes/enforces from zone

.

area_type

Alter link/geo

Recomputes from geo/link

.

link setback

Alter walk_link/

geo

Recomputes from geo

.

walk_link, walk_offset

Alter walk_offset

Enforces from walk_link

walk_offset

Change in set

Update Location_Links table

.

Change in set

Update Location_Parking table

.

Change in set

Update EV_Charging_Stations table

.

Alter zone

Update area_type field

.

area_type

Parking#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter setback/geo

Enforces setback from geo/link

.

setback

Alter Zone/geo

Recomputes from geo

.

zone

Alter area_type

Recomputes/enforces from zone

.

area_type

Alter link/geo

Recomputes from geo

.

link setback

Alter walk_link/

geo

Recomputes from geo/link

.

walk_link, walk_offset

Alter walk_offset

Enforces from walk_link

walk_offset

Change in set

Update Location_Parking table

.

Alter zone

Update area_type field

.

area_type

Node#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter geo

Moves links’s ends to new position

.

x, y

Delete node

Controlled by link deletion

Add node

Controlled by link creation/edit

: x, y

Change to X field

Enforce from Geometry

x

Change to Y field

Enforce from Geometry

y

Traffic Signals and signs#

The traffic signal information necessary for Polaris to work is stored in six different table: Signal, Signal_Nested_Records, Phasing, Phasing_Nested_Records, Timing and Timing_Nested_Records. As very little manual editing is expected to be done to all of these tables, the number of automatic consistency mechanisms involving these tables is very small, and involve mostly propagation on data deletion and summary of table data on their parents.

Sign#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Deletes a sign

Sets control_type to ‘’ on table nodes

.

control_type

2

Adds a sign

Sets control_type to ‘all_stop’ or stop_sign on table nodes. Removes corresponding record from table Signal

.

control_type signal
Signal#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Deletes a signal

Clears related tables: Phasing Timing and Signal_Nested_Records Sets control_type to ‘’ on table nodes

.

control_type

2

Adds a signal

Sets control_type to ‘signal’ on table nodes. Removes corresponding record from table Sign
. |

control_type sign

3

Changes data

Enforces data on “times” field

times
Signal_Nested_Records#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Changes number of records

Updates the field ‘times’ in the table Signal

.
Phasing#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Deletes a Phasing record

Clear related table: Phasing_Nested_Records

.

2

Changes data

Enforces data on “movements” field

movements
Phasing_Nested_Records#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Changes number of records

Updates the field ‘movements’ in the table Phasing

.
Timing#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Deletes a Timing record

Clear related table: Timing_Nested_Records

.

2

Changes data

Atempts to change data in the table

cycle, phases
Timing_Nested_Records#

Index

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

1

Change times for any phase

Updates the field ‘cycle’ in the table Timing

.

value_maximum, value_red, value_yellow

2

Change number of records

Updates the field ‘times’ in the the table Timing

.

Transit_Bike#

To some extent, the Transit_Bike network could be managed like the roadway network. However, this network is an abstraction built on top of the roadway network AND transit layer, so it is not reasonable to have this network manually edited.

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter bearing_a

Enforces bearing_a from geo

.

bearing_a

Alter bearing_b

Enforces bearing_b from geo

.

bearing_b

Change in set

Re-evaluates need for bike stop

.

Change in set/data

walk_link on Location & Parking

.

bike_link

Transit_Stops#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter X

Enforces X from geo

.

x

Alter Y

Enforces Y from geo

.

y

Alter Zone

Recomputes from geo

.

zone

Change in set

Update Transit_Links geometry

.

Change in set

Update Transit_Walk geometry

.

Besides the above operations, there are also restrictions on addition and deletion that are in place. These constraints are:

  • A stop cannot be deleted if a route is using it (i.e. it is referred to on transit_pattern_stops or Transit_Pattern_Mapping)

  • A stop can only be added to the database if a route already refers to this stop (i.e. it is referred to on transit_pattern_stops or Transit_Pattern_Mapping)

Transit_Walk#

To some extent, the Transit_Walk network could be managed like the roadway network. However, this network is an abstraction built on top of the roadway network AND transit layer, so it is not reasonable to have this network manually edited.

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter bearing_a

Enforces bearing_a from geo

.

bearing_a

Alter bearing_b

Enforces bearing_b from geo

.

bearing_b

Change in set

Re-evaluates need for walk stop

.

Change in set/data

walk_link on Location & Parking

.

walk_link

Zone#

What happens

Expected change

When it happens

Delete

Add

Edit geo

Edit data

Alter X

Enforces X from geo

.

x

Alter Y

Enforces Y from geo

.

y

Update table ev_charging_stations

Updating zone on relevant records

.

zone

Update Location table

Updating zone on relevant records

.

zone

Update Node table

Updating zone on relevant records

.

zone

Update Parking table

Updating zone on relevant records

.

zone

Update Transit_Stops

Updating zone on relevant records

.

zone
Contents