route_id vs route_short_name

[Will]

We've been requesting against the Bus Time API using the route_short_name, but have realised that some routes have recently ceased working. In particular, the "M34-SBS" no longer works. I believe we should instead have been using the route_id for requests against the API e.g. "M34+" in this case. Is that correct?

Best wishes,
Will

[Frumin, Michael]

Will, yes, that is correct.

What I believe you and other developers who use Bus Time, OneBusAway, or other GTFS-based systems can/should do is to adopt the distinction between the system's route ID and the customer-facing route id.

GTFS calls these, respectively, route_id and route_short_name. In the Bus Time SIRI API, we use the GTFS route_id for the LineRef item (both in the RESTful queries and in the outputs/results) and the GTFS route_short_name in the PublishedLineName item (results only).

Which is to say that you need to query the system based on route_id/LineRef, but show customers the route_short_name/PublishedLineName.

For MTA, it so happens that for most routes the route_id and route_short_name are identical. But as you have found, this is not the case for the SBS routes. If you look through the new MTA Bus Co GTFS, you will find more examples where they differ.

Thanks,
Mike

[Michael Smith]

One thing to note is that GTFS data is very flexible. Transit agencies do all sorts of "interesting" things with it. Don't expect an application that works with NYC data to work with data from other agencies.

Mike

[Frumin, Michael]

I half agree with Mr Smith. Yes, people do crazy things with GTFS.

Yet, many apps from Google Transit on down seem to work with GTFS data from many many agencies.

Clearly the real-time world isn't as standardized as the schedule/GTFS world, but I like to think we have established some very straightforward and workable conventions around the use of SIRI for stop- and route-level real-time info with consistency of identifiers to static GTFS.

Anyone agree or disagree?

Thanks,
Mike

[Michael Smith]

The NYC MTA further standardizing things is indeed helpful. It would be great of additional agencies followed those standards and it certainly would make third-party apps easier to develop.

And one thing to keep in mind is that just because many GTFS apps appear to work doesn't mean they always do. The resulting issues can be rather hidden when a trip planner is used because such clients don't make all of the information as obvious.

Mike

[Matt]

Let me give you an example what NJ Transit does not have in their GTFS,

For the train numbers, they are used in block_id instead of trip_short_name. The calendar_dates.txt is similar to the LIRR because NJT GTFS does not use calendar.txt

As for the bus route numbers... Not only do they have the route number on route_short_name column, but they also have it in the trip_headsign column with each trip's destination.

They don't use the route_id column as an internal reference, but it would be nice if they did.

What they do have, which because their fare system is so complex is they put "-Exact Fare" at the end of the trip_headsign column only on bus routes where the fare payment is exact and the driver has no change.

NJ Transit should do what Metro North does and put stop_URL link to every train station and light rail station because they have a page to each of those stations on their website.