Introducing myself and tleave.com

[Aaron VanDerlip]

Hello,

My name is Aaron VanDerlip and earlier this year I wrote an web app for looking up commuter rail trains.  I did this primarily to see if I could improve on the existing online schedule and to use TurboGears for a project.  I started this application before the the MassDOT initiative to get developers involved as well as before the release of the Google data. Because of this, the application uses a python based scraper that walks through all of the MBTA rail schedules and loads that train information into a database.

I find the app an improvement over the current online schedule for the following reasons:

1. During the work week, I really only care about getting from my home to North Station and back, the rest of the schedule information is not important to me.
2. I really only want to know when the next several trains are leaving, trains that have left earlier than the current time are not relevant to me.
3. By discarding the above information, allows the display to be larger and more streamlined
4. The app determines the schedule you need by calculation the direction (inbound or outbound) and the timing (weekday, Saturday, or Sunday)

I use this app daily for my own purposes as to figure out when I should leave home/work to catch the next train and overall I feel that is a significant improvement over the current online MBTA commuter rail schedule. It has one shortcoming in that it does not handle transfers for lines that have two end destination, for instance the Newburyport/Rockport line. As such the the train finder will show fewer outgoing trains since it does not account for trips made possible by transferring at a station. In order to enable this would require introducing a more complex algorithm and possibly redoing the data structure.


If you are interested, check out tleave.com.  The app is under the MIT license.

Thanks,
Aaron

On Fri, Dec 4, 2009 at 2:45 PM, Josh <joshua...@eot.state.ma.us> wrote:

David.

Here is an answer from the MBTA reqarding your inbound/outbound pairs
questions:

We don't currently tie together inbound and outbound stops, so there's
no good way right now to provide that to developers.  We'll make a
note of it for future consideration.

 I'm not aware of a command to get configuration information on a
single stop, but we'll also make a note of this for the future.

Josh


On Nov 26, 9:43 pm, DavidN <davidknew...@gmail.com> wrote:
> First of all I want to thank everyone who's responsible for getting
> this trial feed organized - this is an exciting development for the
> MBTA and I think when extended to all routes it's going to make using
> the public transport in Boston much more attractive. I've already been
> asking people I know to email the MBTA encouraging them to keep going
> with this project.
>
> I've put together a little mobile-friendly page to lay out the bus
> predictions for each stop athttp://davidn.co.nr/mbta/(orhttp://www.clickteam.info/davidn/mbta/mbtabuses.phpwithout the
> redirect), and I've had a couple of suggestions from people on the
> "b0st0n" livejournal community where I linked it for testing (the
> original post is here:http://community.livejournal.com/b0st0n/6833157.html
> )
>
> The biggest question was whether the feed provides a way to recognize
> two stops as pairs of inbound and outbound? There are a number of
> stops that have the same name in the feed but are treated as separate
> stops for each direction - it's possible that I could just recognize
> identical names manually as they come in. Also, it seems unusual (but
> by no means disastrous or anything) that the stop ID number is
> provided at the end of the "name" attribute - it's not something that
> I would expect end users to need to know.
>
> Related to that, does a command exist just now to just get information
> about a single stop? (By providing a stop ID, to get back its name and
> lat/lon co-ordinates - in my situation it would be useful just to have
> the coordinates provided as part of the predictions element.) At the
> moment, my predictor pulls the entire routeConfig information out and
> builds an array out of it, which seems like it might be... slightly
> impractical when the feed grows.
>
> Thanks again for getting this started, and happy Thanksgiving from a
> British immigrant organizing his first one :)
>
> David N.

--

You received this message because you are subscribed to the Google Groups "MassDOTDevelopers" group.
To post to this group, send email to massdotd...@googlegroups.com.
To unsubscribe from this group, send email to massdotdevelop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/massdotdevelopers?hl=en.

[Jehiah Czebotar]

Hi Aaron, nice work!

This sounds like exactly the same thing that i originally got
frustrated with LIRR schedules, and it seems like we ended up with a
very similar solution. I've since expanded my schedules to cover
multiple agencies, including MBTA (also before GTFS was available),
and you can see my version here
http://thenexttrain.com/at/mbta/salem/to/north-station/

In general it's great to see developers scratching their own itch when
it comes to transportation problems, and i'm encouraged that with open
data we'll see even more of these sorts of hyper-local applications.

--
Jehiah

[Aaron VanDerlip]

Hi Jeniah
Does your application handle station transfers?  That is the one sticking issue with my current app.  Currently it under reports the next available train because you can take more frequent trains to a station at a hub, and then take a train that runs from an end station to that hub. You can piece this together using the printed schedule.  For an example, on the MBTA look at the evening trains for the Rockport/Newburyport lines, you can take the train from North Station to Rockport at 10:40 PM, transfer in Beverly to pick up a train that only runs between Beverly and Newburyport if that is your final destination.

Aaron