Transit Surfer(tm) Updates


We’ve just finished updating the Transit Surfer™ to use TriMet’s new REST interface – it certainly makes things simpler under the hood. There are some further performance optimizations we can get out of the new interface – but one thing at a time.

Users should not notice any difference, but they will notice another change that is being rolled out simultaneously. Previously we didn’t distinguish between split routes. So a #15 for example could be bound for either Thurman St. or Montgomery Park, and we would not identify which arrival went where. We had an interim change that made the distinction, but put the data on multiple lines, which was too verbose. The latest change makes the point, but keeps the data on one line, like so:

15 Montgomery Pk: 8 min; To Thurman: 19 min

This also affects the SMS (text message) interface in a similar way.

As always let us know what you think, or if you see any issues!


3 responses to “Transit Surfer(tm) Updates”

  1. some thought after using it for a few weeks…

    here’s an example of two messages that i got recently to a transit stop inquiry, 1st message:

    “More Info at http://tunyurl.com/1a2fg5 15 Parkrose TC: 2m,32m; 14 To 94-Foster: 17m, 37m-Reply back ?? ”

    2nd message:

    “to get alerts”

    please do whatever you can to not send that 2nd message. my suggestion would be to get rid of that url, but i imagine it’s there for a reason, so, maybe put it at the end of the message, without the “More Info at” part, in parenthesis like this: (http://tunyurl.com/1a2fg5). it can be confusing at the top, and it pushes the relevant information down.

    also, is the “Reply back ?? to get alerts” really even necessary? it’s such a waste of space to include in every message.

  2. The string “15 Parkrose TC: 2m,32m; 14 To 94-Foster: 17m, 37m” comes from us. Everything else is part of the 411sync service and outside our control.

    Someone just let me know about a similar service, so I may check that out as an alternative.

  3. How about the ability to pass multiple stops in. That way you wouldn’t need to create special sets, or have an engine to allow users to create special sets.

    Just simply allow multiple comma delimited stop IDs in the parameter list, and pass that through to the web service – or something like that.

    I have a few areas where I can take multiple busses for my trip but from different stops – and it would be helpful to have one URL I could bookmark on my phone with all of the stops together so I could compare before I set out walking.

    But there would really be not much use for you to build a special set just for me – although I wouldn’t mind. :)

    But from home I have three possible bus stops that are almost equidistant from my house but in opposite directions. I have a choice of 5 bus lines that service those three stops, so currently I just check each stop and compare times – and walk to the stop with the soonest arrival.

    Same with my work location. And my daughters school has a bus line and a MAX stop, same type of situation.

    Having a simple multiple stop ID interface would be useful for users yet require minimal work on your part. :)

Leave a Reply to Chris Smith Cancel reply

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