Map elevation graph

I’ve started to slowly understand (I think, maybe) the (twisted) “logic” of the elevation graph at the bottom of the map display on the app screen. So, if my understanding is correct:

  1. The elevation graph covers a semi-random stretch of road which may or may not be a subset of the route you have selected;
  2. That semi-random selection is subject to change at each intersection you pass;
  3. Your position on the elevation graph also results from a semi-random selection, which is also subject to change at each intersection;
  4. And to top it all, the direction you are going on the graph is also semi-random and subject to change at each intersection.

So, assuming my understanding is close to correct - is the above considered a feature set, or a major bug?

It’s not semi-random, it is defined by the route you chose and changes at intersections in order to show the segment your route covers. Elevation works the same way, and the direction as well. It’s definitely a cluster and very confusing currently… especially for New York routes. Definitely not a feature, and not really a bug since this seems to be how they intended it to work… it just is what it is for now.

When the UI update is finally pushed its supposedly going to have a fix for that. See the quote in this video at 0:55. https://youtu.be/MrNNN_jkIug

I hope the person who came up with that idea is now at Facebook, Snapchat or some other company with useless apps. Imagine for a second the power/HR graph changing direction, or the map sometimes having your marker going backwards.

@Robert_C I am sure Zwift is aware of this. There are multiple posts about this.

If you look at Richmond UCI course forward you will see how the Map is intended to work. When there was only a few routs and all of then in the same direction the graph was correct.

with more routes and all different directions it is a lot harder to have the graph showing the same direction, I assume each section of road has one graph thus if you go reverse it change direction.

I assume every section of road form intersection to intersection has its own graph. Zwift don’t know what direction you will turn so it does not know what graph will com up next. Races and group rides is different.

I am sure there will be updates when the new UI comes out. It will be nice if it can be improved somewhat.

Nah, the graph seems to be based on some default turns at each intersection which may or may not match your route. For instance for the Astoria Line 8 route in NYC, you get either the graph for the Park perimeter loop for the direction you’re riding at any given time or basically a long flat line for the crossovers.

1 Like

I’d venture that once you select a route, knowing the elevation profile for that route is trivial. Somehow Zwift Insider manages to do it, without direct access to the app data. It’s no harder than showing the route on the map, which Zwift of course does - wait, they actually don’t. That must be another feature.

Once I select a route or an event, of course the app knows - it will do all the turns on my behalf.

Zwift insider does it by just riding the route and plotting the GPS data on strava. Yes Zwift does have the graph, but they need to program it into their game, and that takes time and effort and they have to prioritize what to do.

I said Races and Group rides are different, Yes if you pick a route and not turn zwift should know. But its is not in the program yet.

They did take the time to program it into the app. They just did it in an indecipherable way. That’s what SQA is all about: the earlier you fix a bug, the cheaper it is to fix it. I hope for them (and their investors) they get this before diving into hardware, the fix cost vs schedule progress is exponentially larger when real objects get involved.

Yes they did but then there was only two routes in Watopia and two in Richmond (all routes was single direction), but Zwift grew very fast and little things like that did not.

You are correct.

I believe that what is seen in the game today with respect to the aggravating nuances (graphs, occasional incorrect data, random glitches, etc.) is due to continuously building onto a basic program that didn’t have many routes (at first), and not modifying how those “features” interact as the program expanded.

What started as a game, has now become a platform that people want to use for accuracy in their training, riding, and races. Nobody’s fault, really, but I do believe Zwift needs to focus more on getting things right the first time by implementing a true Quality Assurance branch.

It’s almost as if the users are being tasked with QA of each software release.

1 Like

It’s a classical modern phased-release app dev issue. You want a market-ready release candidate el pronto, you take a bunch of innocent-sounding architectural decisions along the way, and onwards you go, until the consequences of those decisions rear their ugly head. No wonder “refactoring” (a kind word meaning “fixing the growing mess”) is a hot sw dev trend.

This said, when I’m paying a significant monthly fee for an app, I expect to see such cleanups having an appropriate level of priority against features development (and beautifying Richmond). If there are resources available for a wonky steering feature that seems to be already forgotten, there should also be resources available to make sure time/distance remaining are meaningful, data displayed is usable, and details like that (or an HR graph that boasts a dumb coding error screaming at you on My Zwift and does not get fixed).

1 Like