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.

3 Responses to An Architecture Stack for Javascript Transit Appliances

  1. flo says:

    this sounds like a reasonable stack. I hope we’ll soon see transit appliances everywhere :)
    one thing regarding the data representation: the waiting time (number of seconds) seems like the most important information in the UI but changes all the ‘time’. I guess you propose to have a convenience function that computes that value from the arrival clock time rather than have it directly represented in the model.

  2. mattwigway says:

    I think this can be simplified by removing both the arrivals queue and the common services and replacing them with a ‘data controller.’ This would be an object that is configured with its location. It calls the agency adapters to update the queue, manages the queue, and provides access to both the raw queue data and the queue data sorted as you say above. This would simplify usage for programmers on both ends, and reduce the amount of code needed, I think. As always, comments please!

    I also agree with Flo about the need to provide not only seconds until arrival, but absolute times of arrival. Also, the object should have a flag that indicates if there is new data, so the programmer only has to redraw the page if something has changed (e.g. one minute ago the next bus was scheduled to arrive at 5:28, and it’s stillscheduled to arrive at 5:28. Then the application developer could decide whether or not to create a new page. This would be especially valuable for any appliances that aren’t near WiFi/Ethernet and must be connected using a slow/expensive connection such as 3/4G, dial-up, satellite, HAM radio or passenger pigeon.

  3. Eventually came around the racks! PwnCheats is actually happy
    to relieve really the only Internet Jello Splash Secrets.
    It will be possible to get and still have a greater
    rating after that anybody using this type
    of Jello Dash Tips. Would people previously obtain jammed on the stage that needed your complete lives
    aside? This particular will not come about nowadays because you can easily rejuvenate ones existence without
    notice. Despite the fact that have got 1 life left, allow this phenomenal Jelly Dash Tricks turbine produce a person extra.
    Obtain the highest score amongst your pals and also make it possible for
    them ask yourself along with try defeat your current large
    credit score. You may need far more expertise to end
    a straight? Not an issue inside two mouse clicks it will be easy to
    build much more exp. The definition of a person awaiting, Your Jello
    Splash over Defraud can be holding out that you create.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>