You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, prj_volume.uoft_centreline_volumes_output uses a grid angle system to delineate traffic direction, where +1 roughly reflects north and eastbound and -1 roughly reflects south and westbound. This is difficult to parse back into road directions eg. on the directional centreline for routing purposes. We need to replace this system with one that allows us to easily determine which direction along a road each count represents, which would let us calculate traffic upstream and downstream from a point.
One possible solution would be to associate each count with the directional centreline. It might also make sense to be able to map counts to the system we use to calculate network distances. @radumas would have a much better sense of an ideal solution.
Regardless of the solution, it could be done by modifying the arterycode mapping process developed by @aharpalaniTO et al., documented here.
The text was updated successfully, but these errors were encountered:
Currently,
prj_volume.uoft_centreline_volumes_output
uses a grid angle system to delineate traffic direction, where +1 roughly reflects north and eastbound and -1 roughly reflects south and westbound. This is difficult to parse back into road directions eg. on the directional centreline for routing purposes. We need to replace this system with one that allows us to easily determine which direction along a road each count represents, which would let us calculate traffic upstream and downstream from a point.One possible solution would be to associate each count with the directional centreline. It might also make sense to be able to map counts to the system we use to calculate network distances. @radumas would have a much better sense of an ideal solution.
Regardless of the solution, it could be done by modifying the arterycode mapping process developed by @aharpalaniTO et al., documented here.
The text was updated successfully, but these errors were encountered: