Route names are formatted strangely when route_short_name is missing

[bbodenmiller]

Per https://github.com/SoundTransit/soundtransit-rds/issues/22#issuecomment-167672625 real-time ferry data is now in OBA. When looking at stop 7 I can't tell which rows corispond to which ferries as multiple have the same headsign and no route number:

Additionally selecting view route map is resulting in:

[barbeau]

@bbodenmiller Interesting, and cool that real-time ferry data is now included! I'm guessing this is a GTFS data issue, as route_short_name and route_long_name are both required in the GTFS spec - or there is some really weird formatting in the text. I can't seem to pull up a "stop 7" in Puget Sound - can you hit the menu button and do "Show Stop Details" to get the stop code? Or, even better, if you could hook up to Android Studio and run a development build, and grab the API URL it's using. Or, paste the link from the OBA Puget Sound website showing the arrival info for this stop and I'll grab it from there.

[bbodenmiller]

[barbeau]

Ah, got it - the agency_id is 95 - http://pugetsound.onebusaway.org/where/standard/stop.action?id=95_7.

Here's the API request: http://api.pugetsound.onebusaway.org/api/where/arrivals-and-departures-for-stop/95_7.json?key=TEST

Looks like route_short_name isn't provided in the response:

data: {
entry: {
arrivalsAndDepartures: [
{
arrivalEnabled: true,
blockTripSequence: 0,
departureEnabled: false,
distanceFromStop: 601.124216990771,
frequency: null,
lastUpdateTime: 0,
numberOfStopsAway: 0,
predicted: false,
predictedArrivalInterval: null,
predictedArrivalTime: 0,
predictedDepartureInterval: null,
predictedDepartureTime: 0,
routeId: "95_47",
routeLongName: "Bremerton - Seattle",
routeShortName: "",
...

As mentioned above, route_short_name is required in GTFS:

https://developers.google.com/transit/gtfs/reference?hl=en#routestxt

So this is a data issue, but I'll leave this open to see if we can improve the handling of bad data like this.

[barbeau]

Just opened this data issue with Sound Transit - https://github.com/SoundTransit/soundtransit-rds/issues/51.

[barbeau]

Sound Transit correctly pointed out that in the description of the fields in the GTFS spec, route_short_name OR route_long_name is required - you don't have to provide both. So, we should handle the case where route_short_name isn't provided as valid data.

[barbeau]

From https://github.com/SoundTransit/soundtransit-rds/issues/51#issuecomment-170429678:

There does seem to be one oddity with how OneBusAway is handling the trip headsigns of the ferry data.

In trips.txt, the raw ferry data has the headsign values of "To X" - for example, "To Seattle".

However, looking at the OneBusAway server response for the request: http://api.pugetsound.onebusaway.org/api/where/arrivals-and-departures-for-stop/95_7.json?key=TEST

...it seems like the "To " portion is trimmed off the tripHeadsign field for the arrivalsAndDepartures elements (i.e., the individual arrival time records):

arrivalsAndDepartures: [
{
arrivalEnabled: true,
...
tripId: "95_37501101615",
tripHeadsign: "Seattle",  // <-- This doesn't match GTFS
...

...but in the references section at the bottom of the response the tripHeadsign for the same trip matches the original GTFS value:

references: {
...
trips: [
{
...
id: "95_37501101615",
routeId: "95_37",
routeShortName: "",
serviceId: "95_20160110",
shapeId: "95_37",
timeZone: "",
tripHeadsign: "To Seattle",   // <-- This matches GTFS
tripShortName: ""
},

I haven't had a chance to look at the server code to see what's going on, but even if there is some filtering in place to remove prefixes like "To" in headsigns it should be consistent across the same fields in the response for the same trip.