The HERE SDK enables you to build a comprehensive turn-by-turn navigation experience. With this feature, your app can check the current device location against a calculated route and get navigational instructions just-in-time.
Navigation is supported for all available transport modes. The transport mode can vary across the
Route, for example, if you walk through a park to reach a sightseeing spot, you may need to leave the car. After the route is calculated, the transport mode is attached to each
Sectionof the route. For car and truck routes, the location of the device will be map-matched to the streets, while for pedestrian routes, locations are matched to unpaved dirt roads and other paths that would not be accessible to drivers.
Even without having a route to follow, the HERE SDK supports a tracking mode, which provides information about the current street, the map-matched location and other supporting details such as speed limits. This mode is for drivers only.
Note that the HERE SDK provides no UI assets for maneuver arrows to indicate visual feedback. Instead, all information that is available along a route is given as simple data types, allowing you to choose your own assets where applicable.
A tailored navigation map view can be optionally rendered with the
startRendering() is called, it will add a preconfigured
MapMarker3D instance in form of an arrow to indicate the current direction - and incoming location updates are smoothly interpolated. In addition, the map orientation is changed to the best suitable default values.
Voice guidance is provided as maneuver notifications that can be fed as a
String into any platform TTS (Text-To-Speech) solution.
Offline guidance is supported. Turn-by-turn navigation and tracking fully works offline on already cached or downloaded offline map data - as long as the route does not reach regions without cached or preloaded map data.
The basic principle of turn-by-turn navigation is to frequently receive a location including speed and bearing values which is then matched to a street and compared to the desired route. A maneuver instruction is given to let you orientate where you are and where you have to go next.
When leaving the route, you can be notified of the deviation in meters. This notification can help you decide whether to calculate a new route. And finally, a location simulator allows you to test route navigation during the development phase.
Application developers using turn-by-turn navigation are required to thoroughly test their applications in all expected usage scenarios to ensure safe and correct behavior. Application developers are responsible for warning app users of obligations including but not limited to:
Before you can start to navigate to a destination, you need two things:
Routeto follow. The
Routemust be set to the
VisualNavigatorinstance to start navigation.
VisualNavigatorinstance where you are.
Unless you have already calculated a route, create one: Getting a
Route instance is shown here. If you only want to start the app in tracking mode, you can skip this step.
During turn-by-turn navigation, you will get all
Maneuverinformation from the
VisualNavigatorinstance - synced with your current
Location. As long as you navigate, do not take the
Manueverdata from the
You have two choices to start guidance. Either by using the headless
Navigator- or with the help of the
VisualNavigator. Both provide the same interfaces, as the
Navigatoroffers a subset of the
VisualNavigator, but the
VisualNavigatorprovides visual rendering assistance on top - with features such as smooth interpolation between discrete
Another requirement is to provide
Location instances - as navigation is not possible without getting frequent updates on the current location. A possible implementation can be found on GitHub.
It is possible to feed in new locations either by implementing a platform positioning solution or use the HERE SDK positioning feature or by setting up a location simulator.
The basic information flow is:
Location Provider => Location => VisualNavigator => Events
It is the responsibility of the developer to feed in valid locations into the
VisualNavigator. For each received location, the visualNavigator will respond with appropriate events that indicate the progress along the route, including maneuvers and a possible deviation from the expected route. The resulting events depend on the accuracy and frequency of the provided location signals.
Next, we can create a new
VisualNavigator instance and set it as listener to the
LocationProviderImplementation from above. Note that the
VisualNavigator class conforms to the
LocationListener interface that defines the
onLocationUpdated() method to receive locations.
If you do not plan to use the
VisualNavigator's rendering capabilities, you can also use the
Navigator class instead. This class uses the same code under the hood and behaves exactly like the
VisualNavigator, but it offers no support for rendering a specialized navigation view.
You can either react on the location updates yourself or use the
VisualNavigator for this.
Typically, during navigation you want to:
Each new location event results in a new
NavigableLocation that holds a map-matched location calculated out of the original GPS signal that we have fed into the
VisualNavigator. This map-matched location can then be consumed to update the map view.
One caveat is that getting location updates happens in most cases frequently, but nevertheless in discrete steps - this means that between each location may lie a few hundred meters. When updating the camera to the new location, this may cause a little jump.
On the other hand, when using the rendering capabilities of the
VisualNavigator, you can benefit from smoothly interpolated movements: Depending on the speed of the driver, the missing coordinates between two location updates are interpolated and the target map location is automatically updated for you.
A usage example is available on GitHub as part of the Navigation example app. This app provides a testable driving experience. However, it does, not cover every aspect of a full-blown production-ready application. For example, the app does not show how to enable getting location updates while an app may operate in background. If you are interested in such behavior, you can check the related section in the Get Locations guide. More code snippets and examples will follow soon.