Laurie

@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 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...

@evansiroky wondering if this is the same intention as https://github.com/cal-itp/data-infra/issues/2463? Perhaps we can keep just one.

In the v2 pipeline, to download future data we could either: * Create separate datasets for future service and check them as yes for data pipeline * Rework the downloader...

> Number of distinct timestamps per trip per day in both the trip updates and vehicle positions This is available in `fct_observed_trips`, we have a variety of different timestamp counts...

I believe that this need will ultimately be met by the current MD efforts to add best practices to the spec: https://github.com/google/transit/issues/396, recommend closing this ticket.

It is my understanding that questions remain about how these fields will relate to the automatically calculated ones

@evansiroky I believe you have indicated that you don't intend to maintain the route/agency/network selector fields in GTFS service data which I believe means we would not be able to...

This is a valid bug, leaving open.

If any reviewer looks at this -- setting a past cutover date for testing purposes, will bump