Clicking on lines, not just stops, should bring up real-time information

[TransitScreen]

Because of the density and layout issues, lines are usually much easier to select than stops (at least on the desktop version).

So long as there is a 1:1 mapping between lines and stops, there's no reason not to display the same real-time arrival information for lines as for stops (assuming the user will go to the nearest stop, whose name could even be part of the bubble text).

I'm only calling this "Nice to Have" for now, but it should be a very simple change. I can take this patch, unless Andy wants it.

[chosak]

There shouldn't necessarily be a 1:1 mapping between lines and stops (say, for example two metro or bus lines that go on the same path). Right now unfortunately pulling in data from multiple agencies can result in redundant lines on the same path, but ideally these should be merged together into a single line. In that case you'd want to show all information relevant to all routes on that line.

I'm also not sure this is the most user-friendly behavior, especially when clicking on a line far from its origin point. Say you do a search at a very zoomed-out level, and then click on a route far away from the search point (for example, search is in downtown DC and you click at the end of a Metro line because it's easier to click on out there away from the congestion). Is the user expectation really that the line popup will show wait times for the stop located in the downtown, far from your click?

[TransitScreen]

It's true that in the future we should merge lines, but when that happens, we can merge the real-time information from multiple lines (or leave it out, if it turns out to be ambiguous in some way).

I think the semantics of clicking far away are fine. You've already specified where you are, now you're specifying where you want to go. (If you were interested in looking for departure times at tysons corner instead of Rosslyn, you would have double-clicked there.)

[TransitScreen]

I have a short patch that is almost done for this. There's only one thing that confuses me -- in the leaflet data model each segment is associated with multiple services...each of which seems to be associated with the same stop, which forces me to filter the list of stops to remove duplicate stops. Is this a bug, or are these services real (e.g. short-turn metro services, etc.?)

[chosak]

Thanks for working on this.

Each stop is associated with multiple services (e.g., the Rosslyn metro stop has the services "Orange line to Vienna", "Orange line to New Carrollton", "Blue line to Largo Town Center", etc.), and each service consists of a number of segments. Because the segment popups list the routes that travel that segment, each segment object has a reference to the services that travel over it. It sounds like you're then iterating over the services in order to get the stops.

I can imagine that if there's a stop where the same line goes to multiple places (say, from Rosslyn you might have "Orange line to New Carrollton" and "Orange line to Stadium-Armory"), you might encounter multiple services of the same color on the same segment (the segment from Rosslyn to Foggy Bottom would contain both NC and S-A trains). Then when you're going through the services for that segment you might find multiple that refer back to Rosslyn. In that case, the data is correct, and it would just be necessary to filter the stops so as not to have duplicate predictions.

Is this what you're encountering, or is it something else? Can you provide a specific example?

[TransitScreen]

Yes, that's exactly it. What I'm seeing is (for the blue/orange line
between Foggy Bottom and Rosslyn) multiple references to the F-B stop,
which need to be filtered to remove duplicates.

I'm also planning to add the originating stop name to the output (only
when you click on a line, not a stop). That's because as we consolidate
route segments, I believe there should be multiple originating stops
with services traveling on a segment. Right now I think we only ever see
one.

Matt

On 1/27/2012 9:59 AM, Andy Chosak wrote:

Thanks for working on this.

Each stop is associated with multiple services (e.g., the Rosslyn metro stop has the services "Orange line to Vienna", "Orange line to New Carrollton", "Blue line to Largo Town Center", etc.), and each service consists of a number of segments. Because the segment popups list the routes that travel that segment, each segment object has a reference to the services that travel over it. It sounds like you're then iterating over the services in order to get the stops.

I can imagine that if there's a stop where the same line goes to multiple places (say, from Rosslyn you might have "Orange line to New Carrollton" and "Orange line to Stadium-Armory"), you might encounter multiple services of the same color on the same segment (the segment from Rosslyn to Foggy Bottom would contain both NC and S-A trains). Then when you're going through the services for that segment you might find multiple that refer back to Rosslyn. In that case, the data is correct, and it would just be necessary to filter the stops so as not to have duplicate predictions.

Is this what you're encountering, or is it something else? Can you provide a specific example?

---

Reply to this email directly or view it on GitHub:
#59 (comment)

[chosak]

Agree, that would make sense to clarify what stops the predictions are for.

[TransitScreen]

There's one difficulty: After I find the stop, I don't really want to show services that aren't traveling along the selected segment (like ones that go in the opposite direction). However, I'm not sure how to test for this, because the real-time destination (prediction.destination, from real-time API) comes from a different source than the segment's destination (src.segment.destination, from GTFS).

Are we capable of matching destinations yet, or just stops (modulo issue #64)?

[chosak]

No. Ideally the solution to #64 would allow each prediction to be associated with a service, which would let you do what you want.