Metro's GTFS data
Hello Developers! I haven't introduced myself properly yet. I am a developer working for Metro's Dept. of Creative Services. I will save a more general introduction for another post. But first I would like to dive into this discussion the GTFS data set.
michichan makes good observations about our scheduling, especially how we define lines and routes. I am not an expert in this area, but I know that the size of our system compels us to make these kinds of articulations in the data. I'm sure that there were no arbitrary decisions made about the data, and that the care definition of line and route is born out of the constraints of this medium.
I encourage everyone to download the Schedule Viewer and load up the data set. When you start working with our schedule data the first thing you'll notice is how large it is. I understand that it takes up to an hour to load, parse and validate the whole set even on a speedy quad-core machine.
This release of the GTFS data contains another surprise. We make two system-wide changes to service each year (we call them "shake-ups"), and that time is coming soon. Study the GTFS archive to see how the good people in Service Planning represent these changes. The complexity of the system never fails to thrill me.
Note that I moved michichan's post from the main list to the place below. This move was in no way meant to diminish michichan's comment. We simply want make sure that it's clear who works for Metro and who is a member of the developer community.
Comments on this entry:
-
June 15, 2009
Just for a means of background, I have never worked for Metro but I have a great knowledge of how they schedule. The way MTA schedules is very different than other transit properties that I have encountered. I have been going through the GTFS data and I have noticed what some may consider bugs or disparities in the data but it's a part of the way MTA has been doing scheduling for decades. This is something, as transit developers, we need to get used to.
MTA (and the former SCRTD) uses what they call LINES. A "LINE" is a single schedule that may contain multiple "ROUTES". For example, Line 152 (Fallbrook/Roscoe) contains the schedule information for routes 152 (the main route), 153 (the alternate route via Sun Valley Station) and the 353 (the limited version of the 152). As mentioned already in the documentation, the limiteds (with the exception of 305) are not shown in the routes.txt because they mirror their parent local routes. But also, when a route has an alternate route under a different route number, it will appear under this line. For example, the 153 will appear with the 152. The route_id in the trips.txt will be 152 and the only way you will distinguish this trip as a 153 is by using the stop_headsign in stop_times.txt.
Another scheduling method that MTA uses is to create two different routes that are not branch or alternate routes but are "interlined" where most buses from one route continue via another route. A couple of good examples of this arrangement includes Line 230, which includes Route 230 (Laurel Canyon) and Route 239 (White Oak/Rinaldi) and Line 243 which includes routes 242 (Tampa) and 243 (Winnetka). In these cases, the trips for both streets show under one route_id. Like with the branch route example shown above, the only way you can distinguish the trips is through the use of the stop_headsign in stop_times.txt. Even worse, there is currently text in the stop_headsign field that says "change route to..." for these types of routes. This will drive confusion from both a developer and from a end-user point of view. Now while this scheduling junkie does not mind the line level of scheduling, I think that for public facing applications, it would be better to put the route data in at the route level. This is a new project for Metro. I am always available for consultation. Michelle A. Eyre
