-
Notifications
You must be signed in to change notification settings - Fork 133
Historical GTFS Occupancy Data Effort
Expose historical passenger loading to transit riders in lieu of real-time passenger counts with the hopes of:
- Highlighting particularly overcrowded trips
- providing insights into when successive trips have capacity
This effort is divided into 4 tasks:
- Analysis and preparation of historical data
- Mapping of historical data to existing/current GTFS Trips
- Incorporation of historical data into existing systems
- Display of historical data in mobile applications
Discussions remains around the specifics of the data integration:
- at what level will the data be aggregated two? Trip? Stop?
- Stop is preferred, agreed to start with this
- on what interval will the data be updated?
- 6 month implied, will re-visit
- How will this information be incorporated into Step 2.
- Read on
This task encompasses transformation of the data from "Analysis and Preparation" into a standard format, with GTFS-ride being proposed. In doing so, the historical trips need to be mapped to the current trips such that the historical counts can be carrier over.
Several tasks need to occur here:
- add support to onebusaway-gtfs for the proposed extensions/format above
- add support to onebusaway-transit-data-federation-builder (bundle builder) to load the above data and store as part of the bundle
- pass this new data through the onebusaway-transit-data-federation (transit data service) into the OneBusAway APIs and SIRI interfaces
The OneBusAway mobile developer leads have been engaged in this effort and are willing to take on design and development implications of this effort, but are awaiting specification of the tasks above.
- suggest a level of aggregation
- agree on csv format
- agree on update interval
- confirm owner of this task over long term
- map above CSV to GTFS-ride
- specify which GTFS-ride features will be supported
- create module that loads CSV and existing agency data and adds GTFS-ride spec
- Add GTFS-ride support to onebusaway-gtfs / onebusaway-gtfs-modules so that the data may be loaded
- Add GTFS-ride support to onebusaway-transit-data-federation-builder so that the data may be indexed
- Add GTFS-ride support to onebusaway-transit-data-federation and onebusaway-api-webapp so that the data may be accessed/exposed
- provide anticipated API (OneBusAway/SIRI) to mobile developers
- facilitate follow on design sessions
- assist with technical problems as they arise
- create test environment for development
- create a plan for release/deploy
CSV format: (tentative agreement to supply fields similar to trip_capacity.txt in combination with ridership.txt)
Summary:
- ridership.txt is closest to our intention
- if totals (not averages) are included, also need trip_capacity.txt to determine averages
Merge Algorithm
* identify service type: weekday/saturday/sunday/holiday/reduced service day
* identify which subset of these are supported
* for a given CSV trip
** match to a service type
** find route of given trip
** find closes start time to given trip
*** verify same number of stops in CSV and target route
*** verify stop lists are the same in CSV and target route
** assign CSV trip data to selected GTFS trip
** remove CSV trip from future consideration
- OBA API: provide additional parameter and response item to trips-for-route API.
Request:
/api/where/trips-for-route/1_44.xml?key=<key>&includeEstimates=true
Response:
<tripEstimate>
<occupancy>{"full" | "seatsAvailable" | "standingAvailable"}</occupancy>
</tripEstimate>
- Siri Element
EstimatedTimetableDelivery
is at the same level asVehicleMonitoringDelivery
(since 1.2):
Request:
/siri/estimated-timetable.json?key=<key>&OperatorRef=1&LineRef=4&StopRef=431
Response:
SiriServiceDeliveryGroup.EstimatedTimetableDelivery.EstimatedVersionFrameStructure.EstimatedVehicleJourney.EstimatedRealtimeInfoGroup.Monitored.Occupancy: \{"full" | "seatsAvailable" | "standingAvailable" \}
- TODO: discuss testing servers, integration needs, schedule