Identifying and verifying new congestion network segments within TTC-CafeTO study area

[ShahrzadBorjian2]

[ShahrzadBorjian2]

As we discussed, I tried to find the segment_ids of the segments within the following TTC- CafeTO study area by doing reverse look-up. I initially used in the new congestion.network_segments overlaid with gis_centerline to identify the segments within the study area. I only pulled the intersection names of the start and end points (from the gis-centreline layer) not the segment_ids (to avoid manual errors and also for network verification purposes).

Then, I used the intersection names and tried to link it to the centreline_intersection_20220705 to get int_id
and joined it with congestion.network_int_px_21_1 - which is the lookup table between here nodes and centreline intersection id to find the intersection node_id. It should be noted that some intersections have multiple node_ids. After that, I used the node_ids to find the corresponding segment_ids in congestion.network_segments . I used both sql and excel functions to create the look up queries.

Here are the summary of findings:

• I could pull the segments using the node_ids from the lookup tables. However, having multiple node_ids can make it confusing. Is there any reason for having multiple node_ids assigned to one intersection?

• I could not find node_ids for the following intersections in the lookup table:

  • Rusholme Park Cres and College

  • Dufferin and Lindsey

I think it would be useful to add direction, and segment and intersection names to congestion.network_segments .

[chmnata]

Thanks for looking into it!

1. The centreline version I used was gis.centreline_20220705, so there might be some differences comparing to gis.centreline.
2. There are different cases as to why multiple node_ids can be assigned to one int_id. The most common case is where here uses 2 bidirectional line (thus 2 sets of start and end nodes) to represent 1 street while centreline uses 1 line (1 set of start and end node) .
3. For the node_ids you mentioned:

• Rusholme Park Cres and College Since Rusholme Park Cres is not Minor Arterial and above, it's intersection was not used in creating the network. However, the traffic signal next to it has an incorrect geometry so it got matched to the neighbouring node_id :/ I will update the segments affected by this (675, 1297, 3563, 4506). They should have a node_id of 30362017, int_id of 13466357 and px of 2487

• Dufferin and Lindsey Lindsey Ave is a Local street so its also not included in creating the network. The traffic signal there (2612) is located in the middle of two streets on Dufferin, so the closes node_id matched is 30361797, there is no int_id because the px is located in the middle of 2 int_ids.

[chmnata]

@ShahrzadBorjian2 Rusholme Park Cres and College is now fixed.

[chmnata]

Currently backfilling daily and monthly data for the 4 affected segments, for more info on the steps of updating segments, see this commit. :meow_salute:

[chmnata]

Also add direction in congestion.network_segments

[ShahrzadBorjian2]

Thanks Natalie. I also used gis.centreline_20220705 . Please see the flowing snapshots. Dufferin & Lindsey and Dundas & Palmerston are in the congestion network but are not available in gis.centreline_20220705 . I even looked for the node_id and could not locate them.

[chmnata]

Thanks for pointing them, int_id and px now added.