Reimplement current road name label atop navigator status/electronic horizon

[1ec5]

#590 (comment) pointed out examples of the current road name label being unreliable, resulting in the user puck being off from the street source, failing to pick up the road name. A solid fix for this issue would require significant changes to the Directions API, but we do have opportunities to improve the quality of our vector tile–powered workaround:

• The invisible line style layer that we query should vary in width the same way that the visible road layers vary in width: based on the zoom level and road class. A lot of the current unreliability is probably due to the invisible layer being only 1 pixel wide.

  mapbox-navigation-ios/MapboxNavigation/RouteMapViewController.swift

  Line 776 in 026fddd

  streetLabelLayer.lineWidth = NSExpression(forConstantValue: 20)

• For numbered roads, we should show the route number next to the road name (previously Don't use ceremonial name when way is interstate #291). A road feature’s ref attribute provides only the bare number in most cases, not the prefix or shield that we’re accustomed to from the Directions API. But we can use the shield and reflen attributes to get the shield image from the style and insert it into the label as part of an attributed string. The style images should already look pretty crisp at the size needed for that label.
• I haven’t checked, but the upcoming Streets source v8 probably introduces some changes to the representation of road labels that could help us more straightforwardly determine the current road’s name.

/cc @mapbox/navigation-ios @danesfeder

[1ec5]

The invisible line style layer that we query should vary in width the same way that the visible road layers vary in width: based on the zoom level and road class.

The line style layer isn’t really invisible: it just happens to be occluded most of the time by the road, landcover, and water layers. So we’ll need to ensure that the added line style layer is no wider than the existing layer for that road.

[1ec5]

A lot of the current unreliability is probably due to the invisible layer being only 1 pixel wide.

Turns out #1076 quietly slipped in a fix for this issue. Now the line is 20 points wide. Not sure if that has improved the reliability at all.

A road feature’s ref attribute provides only the bare number in most cases, not the prefix or shield that we’re accustomed to from the Directions API. But we can use the shield and reflen attributes to get the shield image from the style and insert it into the label as part of an attributed string.

The Mapbox Streets source reference lists the valid shield values. Mapping them to Directions API refs would be a bit tricky, so for now let’s focus on using the shield values as-is to grab images out of the style using MGLStyle.image(forName:).

[1ec5]

Per mapbox/mapbox-navigation-android#1016 (comment), we can avoid false positives in the form of bike paths while driving by filtering the style layer by road class.

[1ec5]

#2456 would add the current road name outside of turn-by-turn navigation using a more reliable source.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[1ec5]

As of #2410, PassiveLocationDataSource posts a notification on each location update that contains the current road name, but only during free-driving, not during turn-by-turn navigation. This information is much more reliable than feature querying because it relies on map matching, which respects the road network’s topology unlike the map tiles.

During both free-driving and turn-by-turn navigation, the electronic horizon feature added in #2834 posts a notification on each location update that contains the current road name and ref, among other information. This would be a shoe-in replacement for feature querying, except that the e-horizon notification does not include enough information to choose a route shield. So we probably would need to retain the feature querying step but use the e-horizon information to more reliably choose from among the feature querying results. That would allow us to remove the gangliest part of the feature querying code.

[ShanMa1991]

It's fixed in #3019 .