Los Angeles MTA Google Transit: Some first thoughts about the GTFS feed

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.