An Architecture Stack for Javascript Transit Appliances

Currently I’m aware of two “browser-based” transit display applications: Transit Boardâ„¢ which is a hybrid of server-based and Javascript technology produced by yours truly for Portland Transport, and an as-yet-unreleased pure Javascript application that TriMet is working on. There may well be others that I’m not aware of.

My belief is that the potential for HTML/CSS/Javascript apps in this space with a variety of use-case-specific interfaces is very large, and part of the brief for this site is to make it easier for developers to crank out different UIs. To that end I want to propose an architecture stack that would support easy UI development:

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.

I’ll take a moment here to put in a plug for JSONP REST services. The Javascript “same origin” security policy is a tricky obstacle that generally means that a web interface has to be sourced from the same domain as the REST API is served from. That’s pretty restrictive! There are two ways around this: proxy servers that route the data through the same domain as the application is served from (but these consume resources that don’t add any other value) and the use of the JSONP format, which is an exception to the same origin restriction. I’m very pleased that as a result of a request coming out of the CivicWebs Hackathon event, TriMet added JSONP as a supported format (if you’re already supporting JSON, JSONP is a pretty easy addition, just a little bit of extra wrapper syntax).

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!

This entry was posted in Architecture. Bookmark the permalink.

2 Responses to An Architecture Stack for Javascript Transit Appliances

Leave a Reply

Your email address will not be published. Required fields are marked *