Mohan Branched#326
Conversation
websigeeek branched it for review and update
|
@radumas Please check the excel sheet. I will finalize it after your reveiw. |
One detector at Bloor and Runnymede added in the 'Locations' sheet. In segments table, analysis ID 1413812 refers to Dovercourt Rd from College to Dundas. The analysis id refers to detector names AC1 and AD3. both of which are inactive since 2018 August. Detector AD2 also is inactive since Aug 2018. Located at Sterling and Dundas. Not included for route in the sheet. If that route is needed, I will add. CO_DF to AD2 (EB and WB)
About College Street detectors: 'CO_BA' and CO_PA last data reported on 2018-10-10, 'CO_UN' last data reported on 2018-10-12, 'CO_YO' and 'CO_SP', 'CO_DF' ,'CO_OS', 'WS_QP', 'HB_QP' no data pulled therefore, no routes through these detectors.
Green ones are high priority. Green DU_UN and BD_AV is along the Active TO bike lane. May be of interest. Dufferin (both direction) is a low priority. Routes along Roncesvalles is red as BD_DU is not working. But might be a route of interest in future. Highpark-Runnymede both directions and Highpark-Dufferin both directions are the four added routes of immediate interest.
Bathurst and Avenue Rd added
Pls check the half baked query for the lookup table for detector status (active Vs inactive). As list derived from "from_detector" and "to_detector is different and overlapping, I am working on to find the best way to bring them all together in one table..
Updated V 2. Contains the list of all detectors that are inactive.
in the previous query some active detectors were wrongly classified as inactive. That is fixed in this one.
Updated detector table with the route_point IDs as we talked this morning. Just need to check for review.
comparing the output with Jovan's routes not working yesterday the following four analysis IDs are also included in the output. 166985, 1422136, 1427976, 1427980. These four routes are there in observations but not in aggr_5min table. Pull data is true. May be there is something I did not understand.
Functions for identifying the routes and detectors according to the status as either active or inactive on any particular day. The readme file is also updated with the details of how the function works.
This is a route point status function. Takes a single input date in YYYY-MM-DD and returns the list of route points that are active or inactive. Readme is also updated.
Updated readme file with new detector table schemas.
radumas
left a comment
There was a problem hiding this comment.
Bit hard to review the dags in one branch that depend on the sql in the other...
Haven't finished reviewing the sql but have some initial comments for you to work on.
| substring(cod::bit(24) from 12 for 5) as major_device_class | ||
| ``` | ||
|
|
||
| #### Bluetooth_New-Table-Schemas |
There was a problem hiding this comment.
Not sure if this heading is necessary
| * `reader_locations` | ||
| * `routes` | ||
|
|
||
| **reader_history:** |
There was a problem hiding this comment.
These should be 4th level headings so they appear in the Table of Contents ####
|
|
||
| **routes:** | ||
|
|
||
| Routes contain all the routes that pass through the locations (which are either intersections or pseudo intersections) where readers are installed. It corresponds to a unique segments on which data is collected from the network of readers. For a two way street, routes are created for both directions such as Eastbound (EB) - Westbound (WB) or Northbound (NB) - Southbound (SB). In the City of Toronto, bluetooth readers are installed at various locations at different times by different projects. Thus, routes were created accordingly as detectors were added into different tables. Easy way to create and update routes is [described here](https://github.com/CityofToronto/bdit_data-sources/issues/234). The routes that were created earlier were in `bluetooth.segments` table and new routes were created in `natalie.bluetooth_routed` table. After more readers were added, new routes were also created in table named `mohan.bt_segments_new`. This table consolidated all three routes into a single table `routes`. |
There was a problem hiding this comment.
Link should be to the route creation documentation, not the issue.
I also don't think this history is useful to include
he routes that were created earlier were in
bluetooth.segmentstable and new routes were created innatalie.bluetooth_routedtable. After more readers were added, new routes were also created in table namedmohan.bt_segments_new.
|
Closing, outdated and superseded by #381 |
Mohan branched it for review and update
What this pull request accomplishes:
Issue(s) this solves:
What, in particular, needs to reviewed: