Give selected itinerary paths higher z than unselected paths

[lederer]

IOW, turn this…

into this…

[flibbertigibbet]

Due to the opacity on the itinerary layers, overlapping routes will always have dot bleed-through. The alternative is to turn off opacity, in which case nothing beneath an itinerary linestring will be legible.

[flibbertigibbet]

Only manipulating z-index results in this:

[flibbertigibbet]

695 does what I think this is asking for.

Now that I look at it, I think the reasoning behind the old style/behavior is that it makes it obvious that the highlighted itinerary changes on hover, in the common case that two itinerary lines overlap completely. In bringing to front with full opacity, it looks like nothing happened on the map.

[lederer]

@flibbertigibbet Is there a practical way we can detect when multiple itinerary lines overlap completely, so we can eliminate duplicates (ie, suppress all but one of them from appearing)?

[flibbertigibbet]

When the itinerary lines overlap, they are not duplicates; they are different trips that happen to follow the same path (say, via different modes or at different times).

[lederer]

Different modes makes sense.

But trips that are entirely duplicative (in mode and path) except for their timing — those should be deduped. Users can choose alternate timing via the options menu.

Are those sorts of dupes easy enough to detect?

[flibbertigibbet]

Again, there are no duplicates. Timing option is respected.

Maybe try plotting a few trips to see overlapping, differing trips?

[lederer]

Maybe I'm not following correctly?

Here is a walk+transit trip I queried a few minutes ago, with no timing option set:

https://www.gophillygo.org/map/directions?origin=39.9616133%2C-75.1541914&originText=990%20Spring%20Garden%20St%2C%20Philadelphia%2C%20Pennsylvania%2C%20USA&mode=TRANSIT%2CWALK&destination=40.0773701%2C-75.2026087&destinationText=Anderson%20St%2C%20Philadelphia%2C%20Pennsylvania%2C%2019118

It returned 3 trips. 2 of them were exactly the same from origin to destination — path, modes, itinerary — except their timings were 10 minutes apart. That's what I mean by duplicates, in this context. I'm proposing that in such cases, we only show one of those.

[flibbertigibbet]

Right, and for that trip, the next bus in 10 minutes is among the top three best routes available, and so belongs in the results list. If the user toggles to the next 15 minute increment, they wouldn't even see that option.

[flibbertigibbet]

A Certain Other Trip Planner used to behave the same way, as I recall, until they added their Schedule Explorer a year or two ago and put in schedule-derived trip frequency info to the trip summary, which presumably also takes into account time of day and day of week, and which we don't nearly have the resources to go re-implement ourselves now.

[lederer]

So, to try and distill the comparative negatives of the two approaches:

• If we suppress the second trip, there's no way for it to surface (unless we use departure/arrival time increments smaller than 15 min, which for now I'd argue against for simplicity's sake).

• If we don't suppress the second trip, we're foisting a confusing, noisy experience on our users. Functionally, yes they're different "trips" so to speak. But experientially they seem like dupes until you spend the time to scrutinize them enough to find the timing difference.

Agreed, a proper schedule-derived trip frequency component in the trip summary would solve this but is out of scope. But might we be able to pull off a quick-and-dirty cheap version that let's us avoid both negatives?

I think it comes down whether it's easy enough to detect these sorts of "dupes" within the top 3 trips that surface. If they're easy to detect, then could we:

• Suppress all but the first one
• Change the origin timing format to, say, "at 12:37pm (Too soon? Leave by 12:38pm)"
• Change the subsequent transit and destination timing formats to "at 1:46pm (or 1:56pm)"

[flibbertigibbet]

What you're proposing would be much work and still loses information. I fail to understand why we can't simply redesign the linestring color highlighting with the understanding in mind that overlap is common.

We've already decided changing the styling to show the different modes along the route. How about we address that first?

[lederer]

FWIW, there may be some confusion at play. The linestring color changes implemented in #695 are good and strictly speaking they do solve this github issue.

The discussion I started with "Is there a practical way we can detect…" wasn't about calling that into question, it was about trying to find an affordable solution to resolve a pain point in the product that came up in this thread ("the common case that two itinerary lines overlap completely").

I should have made that a new issue. Regardless, if it's "much work", then it's not practical now. I'd hoped it was easy enough, but if not, so it goes. Perhaps we'll revisit in later revisions.

[flibbertigibbet]

Okay.

Yes, munging together multiple trips to add multiple special cases that break the many forms of timing formatting and time/distance duration calculations involved would be much work, and doubtless introduce issues, while making separate trips no longer individually accessible to the user. There's only a maximum of three possible itineraries we ever display to start with, so I'm not seeing benefit to combining them. Presumably the departure time in the trip summary should be visible enough that users can see the difference.

I think once we modify the linestrings to show modes (#440), and consequently, change the background trip styling, it will be much easier to see what's going on with the map interactivity generally, and so adequately address the issue.

[lederer]

We may have to disagree on "seeing benefit to combining them". In my view, there is a cost, born by users, to not combining them: duplication & noise = confusion. Eliminating that cost amounts to the benefit. But not worth fixing this round, given the dev costs you mention.

I suspect mode colors won't help in the case when the only difference between trips is the origin/destination timing (like the example pasted above). But when overlapping paths have different mode segments, I agree mode colors should help quite a bit.