"No remaining scheduled departures" wording

[werebus]

I was showing the site to some of the South Deerfield crowd this morning, and I noticed this.

I pulled up the page for Whately Park and Ride, and noticed that it said, ""No remaining scheduled departures." This is somewhat true, because Avail only returns departures in the the next 3(4?) hours. The 8:05 bus had just left, and the next departure after that isn't until 14:15.

No one in their right mind would wait 6 hours for bus (Google says I can walk to Transit from there in 3), but my first thought was, "Oh, it's broken." Should we say something softer here?

I notice that a RouteDirection has an IsDone attribute:

[
    {
        "LastUpdated": "/Date(1424361141404-0500)/",
        "RouteDirections": [
            {
                "Departures": [],
                "Direction": "Southbound",
                "DirectionCode": "S",
                "HeadwayDepartures": null,
                "IsDone": false,
                "IsHeadway": false,
                "RouteId": 20046,
                "RouteRecordId": 11
            }
        ],
        "StopId": 9990,
        "StopRecordId": 276
    }
]

Could we do something with that?

[werebus]

It turns out that the current limit appears to be 6 hours in the future.

FWIW, I found (with an incredibly scientific survey) exactly 5 cases in the entire PVTA system where this can happen

• The aforementioned Route 46
• Route 38, only where it doesn't overlap with routes 31/36 and only during January and Spring Break
• Route 14E only where it doesn't travel along the same route as Route 14
• Some stops on the Route 27
• Some of the Palmer Village Shuttle

[sherson]

Hmmm... I'm not sure what the limit is, but here's what I've observed with Route 45:

A couple days ago, it wasn't showing any outbound departures at Gulf Rd at 8:17 AM (even though one was scheduled at ~12:39 PM):

This morning at 4:39 AM, it showed a scheduled outbound departure in 2 hours, but nothing inbound (an inbound bus is scheduled at ~7:18 AM):

At 5:02 AM, that ~7:18 AM inbound bus popped in (well, that's when I noticed it):

Which makes me think it's ~2.25-2.5 hours.

BTW, thanks for listing those examples. Looks like Route 27 is in the lead with its 10h20m gap.

While Avail considers what to do, perhaps we could change the text from No remaining scheduled departures to No upcoming departures... but I'm not sure that's much better.

[dfaulken]

I would vote for being accurate as possible. If we can get them to figure out what the actual upper bound is, we can just specify that in our text: "No departures within 3 hours" or something. The nice thing is, if the number's small enough like 2 or 3, this will also apply to cases like the 38 on a Thursday night, which is (I think) the minimum time we have between the last bus going back for the night and the first bus coming out on a particular route.

[sherson]

Ah, I missed IsDone in @werebus' initial comment (color me embarrassed). Yeah we should use that to determine what the text should be.

[dfaulken]

We looked at the isDone attribute for a route that had no departures within 3 hours, but did have some after that, and it had the correct value (false), despite the API returning no stop departures.

We should also look at the 33 when it ends around 9:30 pm tonight to make sure that stops along that route have isDone set to true. For instance, Mill Hollow Apts. has stop ID 21 (link).

[sherson]

Leaving this open while Avail investigates the inconsistent behavior. It should look 180 minutes in the future, but sometimes departures do not show up until they're a little over 2 hours away. So we've temporarily set it to read No departures in the next two hours.

[dfaulken]

Watched the 33 tonight, confirmed this works as fine.

[werebus]

Leaving this open until we hear back from PVTA on the 2 vs 3-hour thing.

[sherson]

I've been watching this sporadically over the last few days and BusInfoBoard renders the correct text. Usually I see buses in the feed anytime they're within 3 hours, but not always. For instance, at 10:05 AM this morning, Thayer St outbound (stop 99) showed:

<ArrayOfStopDeparture xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <StopDeparture>
    <StopId>99</StopId>
    <StopRecordId>243</StopRecordId>
    <RouteDirections>
      <RouteDirection>
        <RouteId>20045</RouteId>
        <RouteSortOrder>65</RouteSortOrder>
        <RouteRecordId>10</RouteRecordId>
        <Direction>Southbound</Direction>
        <DirectionCode>S</DirectionCode>
        <IsHeadway>false</IsHeadway>
        <IsDone>false</IsDone>
        <Departures/>
      </RouteDirection>
    </RouteDirections>
  </StopDeparture>
</ArrayOfStopDeparture>

However, there is a bus scheduled to leave that stop at 12:30 PM. Other stops on that trip also didn't show departure information.

As a test, I logged into block 45-3 in bus 3222. A few minutes later, the departure information did start appearing, though that could be a coincidence (I expect it is, given the behavior I observed previously). Will try logging in again with a bus/stop combination that's closer to the 3 hour mark.

I observed that once the stop departure info started appearing for Thayer St, it started appearing for all stops more-or-less three hours in advance... I reloaded http://bustracker.pvta.com/InfoPoint/rest/stopdepartures/get/[stopID] for a few stops along Route 45 three hours in advance and watched them change from the above to containing departure information.

[dfaulken]

Observed this behavior at 12:25 am:

I suspect that this is because while there is a departure from SAB, it's one that's excluded by default (Bus Garage via CMPSCI) - but there are genuinely no departures from GRC or Haigis. Not sure though.

[werebus]

I agree with your hypothesis. That makes sense.

[sherson]

To clarify, you specified Bus Garage via CMPSCI via the excluded_trips query string? (AFAIK, nothing is excluded by default... or am I missing something?)

Avail confirmed that they have an open ticket and are investigating the two vs three hours issue.

[dfaulken]

Oh yeah, you appear to be correct. My query string was http://umts.github.io/BusInfoBoard/?stops=58+72+73.

[sherson]

Right, that's what I figured (which unfortunately means it's not from excluded departures). Will look at the feed next time we see this behavior.

[sherson]

I brought this up at yesterday's Avail meeting and emailed Andrew about it.

[werebus]

So, does there remain any issue here with BusInfoBoard? It sounds like this is just a duplicate of umts/pvta-avail#321

[sherson]

Agreed, closing

[dfaulken]

I think there is another component to this issue, which is making BusInfoBoard make as accurate a statement as possible, given that umts/pvta-avail#321 has been an issue for over two years. But if we think we've done our best there, then I'm fine with calling it a duplicate.

[sherson]

Will reopen this is Avail improves things on their end.