0.10 enclosingCameraPosition

[westnordost]

Follow-up of #1961

I am trying to use the new method MapController.getEnclosingCameraPosition, unfortunately, it is not as helpful as it could be.

My Use Case

The user looks at an arbitrary rotation and tilt at the map and taps on a pin. The map should zoom to and zoom in or out to show the highlighted map feature but keep the previously set rotation and tilt because by pressing back, the app will un-select the highlighted map feature and return to the previous view position. It would be very disruptive for the user if the returning to the previous view involved changing the rotation and tilt.

Another use case: Imagine an app where you can activate a navigation-view (map view follows position and rotation). If you wanted to zoom to a feature, you will likely want to keep the rotation and tilt.

[rugk]

Any news here? @matteblair

This is blocking the lib upgrade for StreetComplete, see streetcomplete/StreetComplete#1279 for a quite long time now.
IMHO it's not good we have to use outdated libs. Especially as also some features of SC could be implemented with the new lib.

(Note: I have no idea of the internals/technological issues here. Just trying to mediate.)

[matteblair]

I think the use case here is pretty achievable with the current behavior of this method.

A reasonable interaction would be to 1) store the camera position before focusing on a feature, 2) focus on a feature by flying to the enclosing camera position (in a top-down view), then 3) re-applying the store camera position when you leave the focus.

If you wanted to focus on a feature while keeping the user's rotation and tilt that gets tricky, but you could probably get a good enough result by adding padding to the enclosing camera position call based on the amount of tilt and rotation.

[westnordost]

This solution works well for features that have more or less the same width and height. For other features, such as streets, rivers etc this won't work because the resulting bbox can be very different depending on the rotation and tilt. Adding a padding in this case is not a good workaround because the necessary padding can vary greatly depending depending on the elongatedness of the feature. Am 4. Dezember 2019 08:30:16 MEZ schrieb Matt Blair <notifications@github.com>:

…

I think the use case here is pretty achievable with the current behavior of this method. A reasonable interaction would be to 1) store the camera position before focusing on a feature, 2) focus on a feature by flying to the enclosing camera position (in a top-down view), then 3) re-applying the store camera position when you leave the focus. If you wanted to focus on a feature while keeping the user's rotation and tilt that gets tricky, but you could probably get a good enough result by adding padding to the enclosing camera position call based on the amount of tilt and rotation.

[westnordost]

The current code I use is this:

1. find the max zoom level that still contains the feature (getMaxZoomThatContains) in current rotation and tilt.
   1. To do that, the bbox of the currently displayed area is found (getDisplayedArea).
   2. and the bbox of the feature is compared with the displayed bbox. If it is half the width/height, the max zoom that still contains the feature is one more than the current zoom level, if it is double the width/height, it is one less, etc
2. zoom to that zoom level (zoomAndMoveToContain) and re-center the view on the center of the feature

[westnordost]

(my info is outdated now)