transitmatters / t-performance-dash Goto Github PK

With the new aggregation views, we should find a way to speed up the s3-lambda requests on the back-end.

Pressing the "X" to leave aggregation mode on Android Chromium causes some wwwwweird behavior.

the hover-over black info box points to the midpoint between a data point and its corresponding benchmark value, and the benchmark is highlighted with a grey dot while the data point is not highlighted at all.

We should consider adjusting how this is displayed: perhaps pointing straight at the data point instead of the midpoint?

Even if the time scale of data available from the MBTA performance API is not a full day, would be helpful for that to be clear in the chart by having the X range always be 6am-1am.

Because the route id is ridiculous, alerts won't be found. This should be addressed.

"About | Source code | Open source attributions" aren't hooked up at the moment

Would be nice if we had a way for folks to reach the team with feedback, e.g. colorblindness accessibility complaints.

a) so we don't lose them after 90 days, and
b) to improve query time

e.g. https://dashboard.transitmatters.org/rapidtransit?config=Orange,70034,70030,2020-11-22
Also true for a few other stop pairs. The issue is all trips are sharing the same 2 trip ids- they should probably be blank instead.

Should we
a) turn all the trip ids blank so that at least we won't pair them with arrivals to invent dubious travel times
b) check the T's published data source to see if we messed up the storage somehow
c) just erase this day from s3

While requests are being made, would be nice if you could tell!

Email sent to massdotdev on 29 Nov. Will see what they suggest.

We also claim >100% for all historical data points because the ratio is Infinity.

Would be great if you could link directly to a certain configuration

Options are:

1. Just hack it together in the URL manually
2. React Router??

We should consider having a way to annotate dashboard data with major events- e.g. when someone is staring at data from March 2020, there's some very useful context there that it would be nice to display somehow.

Pull alerts from performance API and overlay alert icons on graphs.

We should confirm the logic on dwell calculation in s3_historical.py.
It is possible that the same trip can arr/dep a stop multiple times in quick succession, and we should handle any irregularities accordingly. (aka, also worry about park street?)

Existing headways logic should handle this scenario, though we can't rule out very same-train headways when the trip id's are empty.

Travel-times logic is close to correct, though the same trip departing twice might give rise to 2 very-similar travel-times.

I believe there are only a small handful of stops that exhibit this behavior with any regularity. (e.g. Tufts)

Any update to these functions should consider run-time performance, since they run on very long lists and slow down long aggregate requests.
In addition, when we start fixing issues about the green-line, this may be important to revisit as well.

Last thought- right now, my approach has been 'do what makes most sense', though we might want to consider changing this approach to 'do exactly what the T does' iffen we figure out how they calculate these things.

https://github.com/mbta/transit-performance/ and the google doc linked here might give some clues.

If you request several months worth of data, and then quickly switch to single day mode, the single day info will get erased when the aggregate requests finally return.

We're manually setting the API key environment variable on lambdas right now. This should be handled through deploy.sh.

We need to be smarter about when the left-side dropdowns refresh. Currently it's only downward, so stations only refresh when a new direction is selected. In reality, everything below a selection should probably update/deselect when something new is selected.

https://dashboard.transitmatters.org/rapidtransit?config=Orange,70022,70020,2020-10-27,

It would be nice to show the route somewhere on the chart so screenshots are very clear about the data.
In the title maybe? hmm...

Right now it feels like these happen serially. They should happen at the same time, or be coalesced into a single http request.

Right now, make_parallel wraps only the s3 calls, but it could wrap each data_func so that it only has to calculate for a single day.
We might lose out from threading CPU bound code (or we might win by interleaving I/O and CPU bound tasks)
We might win on processing smaller batches of data at a time (or lose out due to more overhead)

Food for thought: jit with numba or cython? Probably not the right tool for the job.

We might want to cap the y-axis so that huge outliers don't disrupt the ability to view trends in data.
[ I'll look into OL heavily this week to see what is still falling through the filters ]

According to Chris, the T says dwell data at terminal stations is gibberish. I think instead of hiding this from the user (in case they are working on improving it), we put a disclaimer on/near that graph saying it might be bonkers when the station is a terminus.

When switching from agg mode to single day mode, the array functions won't work on this.props.traveltimes since it's still an object.
Clicking on the (X) should clear the data in updateConfiguration.

The am-peak/pm-peak/off-peak options should be expanded to headways and dwells (server side), and incorporated into AggregateByDateSelectable charts (client side)
Also, the current suggestion is that these options are hidden unless you're in "advanced mode".
I'm thinking a normal-looking checkbox in the configuration for "advanced options"?

In which Nathan takes a crack at TypeScript for the first time in several years

• Add park street
• jaggedy benchmarks
• are we calculating metrics accurately?

The aggregation mode progress bar loading may not be consistent, and is also causing tooltip flicker.

(Requires #96)

Once we've decided what bus routes and stations to support, we need to actually upload events for those. You'll want to use the bus generator tool in combination with the bus data from the MassDOT portal to do this.

By default bus2train will generate for all routes, but there's a debug override that can be used to restrict to certain routes. And sorry, that should really be a command-line argument!

https://files.slack.com/files-pri/T0A32SRJ8-F01FR6WLF98/timetravelingblueline.jpg

Bus integration is going to need a new "route", similar to how "rapidtransit" is set up now:
https://dashboard.transitmatters.org/rapidtransit?config=Blue,70057,70041,2021-04-02,

The new page should display a similar set of charts as the rapid transit mode, but probably only travel times and headways.

This is closely related to #95 in that the React hierarchy is going to need some refactoring, mainly the network and configuration stuff. That may honestly be able to just get stuffed into a different class and reused on the bus side.

Per @friendchris there's some "Invalid Date" showing up on iOS on the multi day charts.

Graph point tooltips should just have the time. No date needed.

This didn't used to happen

going from multi-day mode to single-day mode and then pressing browser's 'back' button leaves teh configuration confused about where it is.

Adding bus support to the dashboard needs a mechanism to switch between bus and subway. Here's a possible option for that:

I'm imagining the "Select a line..." selector moved over, with a switch immediately to the left. Not 100% sold on this, and maybe @idreyn has some thoughts?

The StationConfiguration component should probably also sit above App in the hierarchy. Perhaps App should be renamed to RapidTransit, and there should be a "Root" or something to encapsulate the mode and StationConfiguration?

• When data is done loading, complete the progress bar (or amp up the rate so it finishes quickly)
• Also do the reverse... if the progress bar is nearly done and the data is not done; hold

a) so we can show off our benchmarks
b) bc covid has reset all the brains

I think orange line derailment, and maybe the power issue at charles today?

Here's a good example day. the corresponding dashboard alerts shows lots of stuff.
https://dashboard-beta.transitmatters.org/rapidtransit?config=Orange,70036,70032,2021-03-15,

Currently the green and yellow points are not sufficiently distinguishable for colorblind users.

As I noticed in #93 — we don't have data for all routes.

Whoever picks this up needs to determine, of the routes we have available, which to support, and then update src/constants.js with stop data for those.

Note: This is a manual process because the data is so sparse. i.e. for the 57 we only have the following directions and stops available—therefore needs to be human curated.

{
    "57": {
        "979": [
            0
        ],
        "899": [
            1,
            0
        ],
        "987": [
            0
        ],
        "1807": [
            0
        ],
        "931": [
            1
        ],
        "912": [
            1
        ],
        "918": [
            1
        ],
        "959": [
            0
        ],
        "966": [
            0
        ],
        "900": [
            1,
            0
        ],
        "903": [
            1
        ],
        "937": [
            1
        ],
        "954": [
            0
        ],
        "9780": [
            0
        ],
        "926": [
            1
        ],
        "913": [
            1
        ],
        "973": [
            0
        ],
        "11780": [
            0
        ]
    }
}

Right now the titles aren't useful—for example headways is just "Headways". Would be useful if it said "Headways (Central to Park Street)" etc.