Complete QuVR MD for GTFS RT research and metric requests

cal-itp / data-infra

Cal-ITP data infrastructure

https://docs.calitp.org/data-infra

GNU Affero General Public License v3.0

48 stars 13 forks source link

Complete QuVR MD for GTFS RT research and metric requests #354

Open machow opened 3 years ago

machow commented 3 years ago

To go over with @chriscardillo next week, to sanity check the views we are creating. Below is a list of many questions which have been asked of GTFS RT data.

Depencies

These questions all depend on the availability of a built-out RT pipeline which is being tracked in:

[x] cal-itp/data-infra#221

Issues

cal-itp/data-analyses#262
cal-itp/data-analyses#261
cal-itp/data-analyses#260
cal-itp/data-infra#205 - (many questions -- I would just write out the views involved for now)

Misc

Metrics proposed from the outcomes section of this doc

Metric	Proposed Method
Valid Realtime updates available in GTFS Realtime	Number of Realtime Feeds
Alerts available in GTFS Alerts	# of agencies publishing GTFS alerts
Fares available in GTFS Schedule	# of agencies publishing Fares V2

hunterowens commented 3 years ago

add to this list (or maybe a part 2) for level of delay

lauriemerrell commented 2 years ago

cal-itp/data-infra#232 seems related to this too / seems to duplicate some of what is in cal-itp/data-infra#205

lauriemerrell commented 2 years ago

@holly-g Looking into this a bit more, wanted to note that:

The third metric proposed here is a GTFS Schedule metric, rather than GTFS RT (wonder if we need to split out / if this one should be moved or is already tracked elsewhere)
The body of cal-itp/data-analyses#260 actually seems to describe the problem in terms of analysis on GTFS Schedule data (proposes an initial analysis of GTFS Schedule data that would then support a subsequent step of looking at its relationship with RT) -- so it's related to RT analysis but a bit different

lauriemerrell commented 2 years ago

To expand on last comment, re: cal-itp/data-analyses#260 -- the "what" (goal) described relates to GTFS RT data (checking how far in advance GTFS RT predictions are useful/needed). But the proposed "how" (method) laid out in the issue body refers to actually conducting an analysis on the schedule data (what are the typical gaps between services at the same stop & what is the frequency of services) which would then be used to inform that RT analysis.

So that issue as currently written is a bit hard to categorize - perhaps should be split out into two issues, one (perhaps that existing issue) for the initial GTFS Schedule analysis and a second (perhaps new) issue for the subsequent RT work?

cc @holly-g

evansiroky commented 2 years ago

I appreciate the enthusiasm of looking into various issues like this. This particular issue is tagged as "epic" which the author of this issue liked to use to contain information about large tasks that could have numerous subcomponents to them. Also, in the greater scheme of things, this issue is rather old and not something I'd like to prioritize until the GTFS-RT pipeline is built out completely. So this is blocked by cal-itp/data-infra#221.