Seams appear between traffic congestion segments along route line at high zoom levels

[1ec5]

In OpenStreetMap, San Francisco’s Lombard Street has very granularly mapped curves, with nodes spaced approximately 2½ to 3 feet apart. At zoom level 18, which is higher than the default zoom level, the default route line drawn by NavigationMapView.showRoutes(_:legIndex:) begins to show seams between each traffic congestion segment:

These seams become more pronounced when the user zooms into the default maximum zoom level 22. The traffic congestion segments also become slightly misaligned from the route line casing:

Each segment has to be a separate line string, because it may need different styling than the neighboring segments. The style specification has line join options, but only for segments within the same line string.

One possible fix would be to display the entire route as a single line string and use a line gradient to apply the colors. This approach would depend on #2067. Unlike the dynamically deemphasized route line in #1307, this fix doesn’t require transitions of any sort, so it isn’t blocked by the map SDK. By representing the whole route’s congestion segments as a single line string, we’d also fix the misalignment between the congestion segments and the casing, which is already a single line string.

NavigationMapViewDelegate is currently designed to treat the congestion segments as separate features, hence the separate NavigationMapViewDelegate.navigationMapView(_:shapeFor:) and NavigationMapViewDelegate.navigationMapView(_:simplifiedShapeFor:) methods. Effectively, the fix would entail associating both style layers – the congestion segment layer and casing layer – with the simplified shape feature, and assuming that the style layer returned by NavigationMapViewDelegate.navigationMapView(_:routeStyleLayerWithIdentifier:source:) specifies a gradient style.

This change will be tricky from a backwards-compatibility standpoint, because it’s entirely possible that a developer may have already customized a layer (to get a different line width, say) without customizing the underlying shapes (because they’re happy with the current congestion segments). But another developer may have customized the shapes to disable the congestion segments. So it might be problematic to force the layer returned by NavigationMapViewDelegate.navigationMapView(_:routeStyleLayerWithIdentifier:source:) to have a gradient.

/cc @mapbox/navigation-ios

[1ec5]

One challenge with using a gradient is that the gradient’s stops are expressed in terms of a cumulative distance along the route line rather than a start and end coordinate. Any discrepancy between the cumulative distance and the route line as it’s rendered on the map could result in significant additive error by the end of the route. Therefore, it’s important to use the same distance formula as the map SDK, not necessarily the distance formula used by Turf or the Directions API.

[1ec5]

One possible fix would be to display the entire route as a single line string and use a line gradient to apply the colors. This approach would depend on #2067.

#2377 reimplemented the route line as a gradient instead of itty-bitty line segments.

One challenge with using a gradient is that the gradient’s stops are expressed in terms of a cumulative distance along the route line rather than a start and end coordinate. Any discrepancy between the cumulative distance and the route line as it’s rendered on the map could result in significant additive error by the end of the route.

#2737 will address one such discrepancy.