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.

7 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. Fantastic post however I was wondering if you could
    write a litte more on this topic? I’d be very grateful if you could elaborate a little
    bit further. Cheers!

  4. Lisette says:

    I always used to study paragraph in news papers
    but now as I am a user of net therefore from now I
    am using net for posts, thanks to web.

  5. Wonderful web site. A lot of helpful information here.
    I’m sending it to some pals ans additionally sharing
    in delicious. And obviously, thanks for your effort!

  6. Hello to every single one, it’s truly a good for
    me to pay a quick visit this web page, it consists of priceless Information.

  7. With havin so much content and articles do you ever run into any problems of plagorism or copyright infringement?
    My site has a lot of unique content I’ve either
    written myself or outsourced but it looks like a lot of it is popping
    it up all over the web without my permission. Do you
    know any techniques to help protect against content from being ripped off?
    I’d genuinely appreciate it.

    my page :: Monster Legends Hack Download

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>