An app developer should be able to perform client-side customization of banner instructions

[akitchen]

In order to satisfy #637 , at least two pieces of functionality are needed, one of which already exists

New functionality: Allow an app developer to customize the visual instruction (AKA the banner text) before it is displayed (for example, adding/removing text or converting to a custom shield). This would take the form of an optional delegate method resembling willDisplayVisualInstruction:(MBVisualInstructionBanner *)instruction where the instruction could be altered (or an alternate value returned) before the banner is displayed. We may need to consider adding other delegate methods related to banner sub-components for finer-grained control -- let's discuss based on more concrete use cases.

Existing functionality: Allow an app developer to customize a spoken instruction before it is generated and played -

mapbox-navigation-ios/MapboxNavigation/RouteVoiceController.swift

Line 306 in 99cd0f0

optional func voiceController(_ voiceController: RouteVoiceController, willSpeak instruction: SpokenInstruction, routeProgress: RouteProgress) -> SpokenInstruction?

Once applications implement these two methods, it should be possible to more easily work around cases of arcane road classifications and missing shields.

[akitchen]

Per #637 It should be possible to alter the visual instruction so that a shield can be drawn

[1ec5]

Fixed in #1530.

Once applications implement these two methods, it should be possible to more easily work around cases of arcane road classifications and missing shields.

I’m not especially confident that the application would have enough context to intelligently refine data coming from the Directions API using what’s implemented in #1530. That would require the Directions API to expose more structured data that OSRM or Valhalla provides. (And the router in turn might need to expose more of what OpenStreetMap provides.)