Closed chmnata closed 1 year ago
I will fix the 24 segments that has error with centreline routing first.... and then work on interpolating the segment with mysterious geo_id later :meow_salute:
The incorrect matches are where here draws the bi-directional streets with 1 line (aka 1 node) when centreline draws it with 2 lines (aka 2 int_id). With X being here node and two int_id pointed out with arrows in the below image
There is also cases where -1 and 1 digitization that doesn't join well with directionality like Eastbound
, Westbound
.
Dealt with the incorrectly routed ones, turns out there are a couple (127 segments) with geo_id that has no record in aadt. Nothing of that geo_id in the tables.
The dir_bin in aadt centreline which was partially created by the oneway_dir
column is inconsistent in different centreline versions :( making the matching harder....
similar enough for now
Teps aadt on centreline
Conflated aadt on segment
Determined AADT for each segment with tep's 2018 results, using a combination of spatial joins, and manual input where there are data gaps. Those gaps were filled with adjacent street's average aadt depending on the street. All updates of aadt can be fine in the sql.
Using the table
covid.teps_aadt_2018
, but I'm not sure what version of centreline it was using as some of them does not match with our old centreline version nor the centreline_20200705....After initial conflating, 175 out of 6530 segments did not have a single geo_id match in the teps table... but some of them are actually because of some errors in centreline routing. Out of those 175, 151 are drawn by centreline with geo_id that does not exist in the teps table...... those will need to be conflated using neighbouring segments with data