Add shift for location of camera.

[Chaoba]

Resolves #14846
Shift is not used on camera, so it will show wrong location when using location shift.
In this PR, we implement shift in CameraPosition.Builder().build() method for the origin location. Also add test demo in test app.

[LukasPaczos]

The idea to re-use the shifter implementation of Point from the mapbox-java is clever, but it's going to work only for the LocationComponent. Every call to MapboxMap's camera APIs is still going to result in an incorrect camera position.

I'd rather call CoordinateShifterManager#getCoordinateShifter and use it in the CameraPosition#Builder that will handle both of the cases. Also, keep in mind that if the builder is used to shift coordinates, the CameraPosition#DEFAULT should be initialized using the builder as well.

Additionally, do we have to "unshift" the coordinates when we call CameraPosition#target getter?

[Chaoba]

@LukasPaczos If make shift in CameraPosition#Builder it could be shifted twice or even multiple times since we don't know the passed in param target is shifted or not.

Btw, we can't unshift location in china plugin.

[LukasPaczos]

Thanks for the updates @Chaoba. I revisited the setup and here are a couple of thoughts:

• Currently, this simple assertion is going to fail, which feels unacceptable to me:

LatLng latLng = new LatLng(50, 16);
cameraBuilder.target(latLng);
CameraPosition position = cameraBuilder.build();
assertEquals(latLng, position.target);

• I looked through the code, and in most of the places, the geometry objects are passed to the NativeMapView and then to core.
• How about we introduce a new shift method in the classes found in the com.mapbox.mapboxsdk.geometry that is going to return a new object with shifted geometries, without changing the original? We could call this method in the NativeMapView, right before it's passed to core.
• One missing piece is the MapSnapshotter#nativeInitialize which passes the whole camera object directly and would have to be shifted there.
• Another arising problem is round-tripping - our use-case doesn't expect it, so below assertion is always going to fail:

map.setCameraPosition(value);
assertTrue(value, map.getCameraPosition);

• However, for other applications (are there any?) we could still include the unshift calls in constructors that are called from core.

Let me know what's your take @Chaoba. Any other thoughts @mapbox/maps-android?

[Chaoba]

@LukasPaczos Thanks for your thoughts. If we add a shift method, then in which situations should we call it and which situations should we use the origin one? How to prevent shift multi times?

After due consideration I think we shift location in CameraPosition is not a good idea, we should shift location out of it.

[LukasPaczos]

in which situations should we call it and which situations should we use the origin one? How to prevent shift multi times?

We should call it right before geometry is passed to the core (for example in the NativeMapView). This way C++ objects will be shifted and Java objects will always be unshifted. I don't think we can run into double shifting this way unless we take into account round-tripping, but since our use-case doesn't provide a reverse algorithm, there's nothing we can do about it.

[tobrun]

We are removing platform code from gl-native in #15970. If you want to see this PR merged, it will require re-implementation in https://github.com/mapbox/mapbox-gl-native-android.