Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow filtering of feed versions by calendar dates #851

Closed
3 tasks done
drewda opened this issue Nov 3, 2016 · 1 comment
Closed
3 tasks done

allow filtering of feed versions by calendar dates #851

drewda opened this issue Nov 3, 2016 · 1 comment

Comments

@drewda
Copy link
Member

drewda commented Nov 3, 2016

FeedVersion models include information about the dates that they cover: earliest_calendar_date and latest_calendar_date. These properties are included in the public API responses: http://transit.land/api/v1/feed_versions Let's also allow users of this API endpoint to filter by date--this will make it possible to search through historic feed versions.

The following model scopes and API controller query parameters should provide enough flexibility:

  • calendar_coverage_begins_at_or_before
  • calendar_coverage_begins_at_or_after
  • calendar_coverage_includes

TODO:

  • model scopes
  • query parameters in API controller
  • add indices to those columns in database?
@barbeau
Copy link

barbeau commented Nov 3, 2016

Filtering by date would be great!

We’ve been archiving GTFS-rt data, and now are trying to go back and piece together schedule data over that same time period as the timestamps in the real-time data. So our typical use case for a request would be supplying a timestamp for the first GPS point in the dataset and a timestamp for the last GPS point in the dataset, and we would want to get back a list of GTFS datasets that cover that time period. In other words, any trip_id in our GTFS-rt dataset would be guaranteed to exist in at least one of the returned GTFS datasets (assuming no error in the feeds). We would expect the parameters to be treated as inclusive (i.e., include the date specified in the parameter), which sounds like it matches with the proposed field names above.

@irees irees self-assigned this Nov 4, 2016
@irees irees added the ready label Nov 16, 2016
@irees irees closed this as completed in #867 Dec 5, 2016
@irees irees removed the ready label Dec 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants