Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map update 2023 #75

Open
chmnata opened this issue Dec 21, 2023 · 5 comments
Open

Map update 2023 #75

chmnata opened this issue Dec 21, 2023 · 5 comments
Assignees

Comments

@chmnata
Copy link
Collaborator

chmnata commented Dec 21, 2023

Documenting process and issues encountered for updating 2023 network.

@chmnata chmnata self-assigned this Dec 21, 2023
@chmnata
Copy link
Collaborator Author

chmnata commented Dec 21, 2023

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

@chmnata
Copy link
Collaborator Author

chmnata commented Dec 21, 2023

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

e.g.
image

@chmnata
Copy link
Collaborator Author

chmnata commented Dec 21, 2023

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
Copy link
Collaborator Author

chmnata commented Jan 4, 2024

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
Copy link
Collaborator Author

chmnata commented Jan 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant