search

CityofToronto / bdit_congestion

Determining most congested streets and days in Toronto
https://github.com/orgs/CityofToronto/teams/bigdatainnovationteam
GNU General Public License v3.0
0 stars 0 forks source link

Map update 2023 #75

Open chmnata opened 11 months ago

chmnata commented 11 months ago

Documenting process and issues encountered for updating 2023 network.

chmnata commented 11 months ago

After updating the routing code to use only network links, the routed results are much cleaner. image

chmnata commented 11 months ago

However, it has created short segments as new traffic signals were introduced.

e.g. image

chmnata commented 11 months ago

About 53 segments are effected, the 20ish new traffic signals are gonna retired those 53 segments and create 102 new ones. Most of them looks legit, creating segments with decent distance, leaving 12 new segments with length less than 100m. For example: image image image image Most problematic ones... because the segments should not originally cut at queensway / parkside as they do not physically intersect.

image

chmnata commented 10 months ago

While validating, found out that there are a couple of duplicated use of link_dir and realized HERE could change the geometry of a link and node, but keep the link_dir and node_id as constant. e.g. green = 23_4, pink = 22_2, the two link_dir's geometries are clearly different, starting from a different node_id in space but both the link_dir and node_id remained the same even if the geometry is different. image

This becomes an issue when re-routing for segments that contains outdated links, because the change in geometry doesn't necessarily come up as "changed" as link_dir and node_id stayed the same, which could result in some weird routing when some node doesnt intersect a street anymore. I only realized this during validation because one segment_id had both change in geometry and a change in link_dir text. The segment 3415 that have this issue: blue - original, red 23_4 version. 1 node has moved so that is been updated and 3415 has been retired and replaced with 7222. image

However, this new segment does not align with other previous segments that "didn't change" (in terms of link_dir and node_id) image

The other segments that had a change in spatially should be updated as well.......

Other example of local streets drawn slightly different image

chmnata commented 10 months ago

The changing geometry does not post an issue other than the one segment noted above :meow_dio: Checked the validity of the "new" segments (created by updating link_dir's geom) by routing the changed segment + its adjacent segments and see if ST_isvalid(geom) is true. They were all true. See more in ../../notebook/map_geometry_changes.ipynb

Will rerun/continue validation tests in notebooks/network_update_2023.ipynb with the new geometries.

chmnata commented 3 months ago

Noting here some convo about the change of maps and the fact that some segments now have different length because of how roads are drawn slightly differently. The difference in length will result in different travel time when comparing results derived from different maps. For example, the length of a segment is 100m in 22_2, and it is now 110m in 23_4. The travel time calculated by the length and speed will make the results incomparable, as the base length is different. (around 200 segments has a change in length)

image We can eliminate this issue if we were to store average speed instead of average travel time.