I’m going to describe these from the center outward. The core data element would be a queue of arrivals, represented in an agency-independent way. Here are some of the data elements I would suggest should make up a common representation of an arrival:
- Number of seconds until the arrival
- Clock time of the arrival
- Is the arrival time an estimate based on AVL or a scheduled time?
- Route id of arrival (preferably a GTFS route_id)
- Location id of arrival (preferably a GTFS stop_id)
- Trip id of arrival (e.g., GTFS trip_id)
- Direction of arrival (e.g., GTFS direction_id)
- Textual information (headsign, e.g., GTFS trip_headsign or trip_short_name) describing routing or destinations
- Service alerts associated with this arrival (detours, delays, etc.)
The overlap with GTFS is not accidental – there is obviously a big overlap with the data elements used for scheduling, and I hope that overlap extends into an AVL standard protocol.
This arrivals queue would be populated by one or more agency adapters (consumers of REST services for example). In Portland, to get a complete set of arrivals for some stops, it would be necessary to query the REST services for both TriMet and Nextbus (for Portland Streetcar arrivals). If at some point we have a standardized AVL REST API (the AVL equivalent of GTFS) we could just code one adapter (passing agency endpoints as a parameter), but until then we’ll need agency adapter modules for each unique REST format.
OK, now working in the other direction from the arrivals queue, we could simply have UI developers directly read the arrivals queue (and we should provide this option). But I also think we could make life easier for UI developers (our mission!) by providing some standard services they are likely to want to make use of. Examples I can think of off the top of my head include:
- Access arrivals sorted by time of arrival
- Access arrivals grouped by stop_id
- Paging services (e.g., split arrivals display into multiple pages of ‘n’ arrivals each)
- Refresh interval management
I’m sure there are more. Better if we can code these once with good APIs than to make UI developers re-invent the wheel over and over again.
So what do you think? Is this a reasonable stack? Are there components I’m missing? Can something be simplified? Other services that should be included in the API?Let me know how you think this can be improved!