Congestion Network 2.0: Conflate routed network to the centreline

[chmnata]

• Assigned node_id used in the network to centreline's intersection or traffic signals.
• Route centreline

[chmnata]

For a total of 6507 segments, 5725 of them have both start int_id and end int_id assigned to their respective fnode and tnode. Out of those 5725 of the routable ones, 5722 got routed (3 did not).

The segments that did not have an assigned int for either start or end px seems to be all related to the fnode/tnode being midblock PXs, so there is actually no centreline intersection available at that location. For these ones, we have figure out a way to route the centreline through those nodes without int and then assign the averaged AADT of the routed centreline for those segments.

[chmnata]

The script works when there's only one node without int match, aka not two node without int match next to each other.

Interestingly, the px on steeles are actually on an intersection but the int_id does not exist in gis.centreline_intersection_20220705 but does exist as a fnode and tnode in gis.centreline_20220705 🤔

I just added them in the int_id and node_id lookup table for the time being.

[chmnata]

Gardiner and lake shore proves to be :meow_dio: once again. There is this one traffic signal 211, supposedly at Yonge and lakeshore intersection, but the intersection_id tagged is 13467631, which is on Gardiner and not Lake shore. For now I'm assuming traffic signal go tagged to the wrong int_id + has wrong geom. Should probably ask someone about this?

[chmnata]

Also traffic signals only gets tagged to one intersection, even if its 2 traffic signals irl + centreline digitalization. For example, the below px was only tagged to one (at lakeshore and LOWER SHERBOURNE ST), when its technically on both wb and eb of lakeshore.

[chmnata]

This version of centreline draws gardiner and lakeshore in a totally different way than the old old one we used. Validate the matching of centreline and segments but checking lake shore 's matching and centreline's matching separately. Occasionally changing the int_id and node_id match to the correct one (cause nearest neighbour is almost always incorrect, should include some sort of st_name match to it next time), and re-routing using only lakeshore/gardiner for respective segments. Also checked the ONE_WAY attribute in centreline to make sure where 2 bound of lakeshore became 1 line.

[chmnata]

Final conflated map looks like dis

[chmnata]

Now it looks like this, can't believe I havent done a check on this conflation but there are indeed segments not used in the lookup table

-- 30 rows in total 
with temp  as(
select unnest(segment_set) as segment_id 
from congestion.segment_centreline)
select *
from congestion.network_segments
left join temp using (segment_id)
where temp.segment_id is null

Not used segments:

Mostly some updated segments that I forgot to also update the centreline lookup when I updated the 22_2 map versions. And some cases like this: Where centreline uses A and B to represent that stretch of road, but here draws it differently and has a (1) link in between. We assigned those 2 nodes to the middle intersection, so the middle segment didn't get routed.