Expose current bearing in public API

[oscarlorentzon]

Exposing the current bearing makes it possible to rotate a marker on a map according to the current point of view.

The bearing value is relevant for panoramas as well as perspective images and should be exposed always.

Currently the direction component does the calculations necessary to retrieve the bearing. This code should be moved to the state and handled correctly. The bearing should be exposed as an observable/event on the viewer.

The edge data currently contains a property called worldMotionAzimuth. Potentially the name and calculations for that one should be changed.

• Bearing calculations in state
• Use bearing observable in direction component (and future bearing component)
• Expose bearing as event/observable on viewer.

[oscarlorentzon]

The horizontal field of view could also be a property on a struct containing the bearing in the bearing event/observable.

[oscarlorentzon]

There is also a case for exposing an API method getBearing on the Viewer class that can be called at any time without the need to listen to the bearingchanged event.

For the bearingchanged event there are different ways to handle it:

1. Send an event for every change in bearing with decimal precision.
2. Send an event when the rounded whole number part of the bearing has changed.
3. Send an event for a subset of the whole numbers in the 360 span, like for 0, 22.5, 45, 67.5... (related to 360 / 16)

The method chosen has an impact on the API usage implementation and the performance. More events will be sent for the first option, and the API user will have to do the filter/mapping herself.

@gyllen Thoughts?

[gyllen]

@oscarlorentzon Can we use some kind of throttle on the observer? So it only updates at the most every 100ms or so?

[oscarlorentzon]

I do not think that operators like throttleTime, bufferTime or debounceTime should be used in the library for synchronous cases like this. The library should emit when things change. The library needs to ensure that it is performant enough to emit things correctly. In this case the performance hit will be small.

The important questions are:

1. Should we both expose a bearingchanged event as well as a Viewer.getBearing method?
2. Do you need to get a bearingchanged event with a bearing (in degress) with decimal precision, whole numbers, or a set of fixed values with larger interval between them. This relates to rotating a marker on the map when the bearing of the camera in mjs changed.
3. Should we expose the bearing in degrees or radians?

[gyllen]

0. Im not sure if the library updates really fast internally we might consider throttling it
1. I think it makes sense to have both, you want to receive updates but you will also need to be able to check current state.
2. With throttling we can use decimals. If no throttling we can maybe use 1 decimal or something to keep the events to a minimum.
3. I would say degrees (for ordinary people)