stop camera animation when constrained by maxBounds

[andrewharvey]

When using flyTo with a maxBounds set on the map, the camera will keep trying to animate when hitting the bounds.

https://jsbin.com/ritikupaqe/edit?html,output

Should we change this so that when the transform becomes constrained, the animation is stopped at that point?

[stevage]

Interesting. In this case, you're doing something totally unreasonable: saying "I never want to see anything outside this box", and then trying to move the camera a long long way outside the box. Are there reasonable use cases where this is a problem? I kind of think it would be fair for mapbox-gl-js to return an error here.

[andrewharvey]

I think it's fair enough to have either option

a) let the application developer do their own checks before calling any of the camera setters, and/or
b) the camera setters to do their own internal check and return an error when the requested camera is outside the maxBounds

It should be clear who is responsible for that check.

Are there reasonable use cases where this is a problem?

The GeolocateControl with a maxBounds set on the map when a user is located outside the maxBounds.

The problem here is the geolocate event is triggered after setting the camera to the new view so you can't currently deal with this case in your application.

The workaround I have at the moment for this is https://bl.ocks.org/andrewharvey/6c6282db4a7c9b316ebd51421160c5e4

We could build in checks into the GeolocateControl to detect and report back on this, but I'm not sure of the best place in the "stack" for the check to happen.

[stevage]

Oh, yeah, that use case - happens a lot when someone in Europe makes a cool map and you try to view it from overseas and...yep.

Maybe the issue that "max bounds" isn't really a meaningful concept for a map, it's really a constraint that should be applied to individually to different actions, like user scroll, geolocating, manually triggered by code...

[andrewharvey]

Another design is build the check into all the camera setters and if a request comes in which would end with the camera outside maxBounds, then don't change the camera and trigger a 'outside max bounds' event.

That way no matter what's making the changes to camera, the application developer can detect via the event.

Either way we're going off a tangent from the "stop camera animation when constrained by maxBounds" issue 😉

[mollymerp]

yeah, I think this is undesired behavior/a bug. I am in favor of emitting an error and bailing if someone wants to animate to a place outside of the constrained bounds. @mourner @lbud does that make sense to you?

[andrewharvey]

closely related to #3231

[andrewharvey]

Interesting. In this case, you're doing something totally unreasonable: saying "I never want to see anything outside this box", and then trying to move the camera a long long way outside the box. Are there reasonable use cases where this is a problem? I kind of think it would be fair for mapbox-gl-js to return an error here.

Another use case is you have an area of interest for your application (e.g. an administrative district) and want to keep the map within this area, but you want to flyTo a location that's right on the edge. Naturally the flyTo would try to get the location in the center, but constraint by the maxBounds it would still get the location in the view, just not the center.

In that case I don't want an error or it to bail, as it's totally reasonable to request, I just expect the animation to stop once the camera hits the constraint and is no longer changing.

[planemad]

Been hitting this issue as well, thanks @andrewharvey for the workaround.

At worst the current behavior makes for a poor user experience if it ends up being an ocean and all you see is a blank map with no context.

At best it would take you to a part of the map that may not be relevant for your location.

emitting an error and bailing if someone wants to animate to a place outside of the constrained bounds

👍 As a developer this is exactly what id be expecting, allowing me to control what happens in such a use case. Related: #6789

but you want to flyTo a location that's right on the edge .. In that case I don't want an error or it to bail, as it's totally reasonable to request

It seems an acceptable assumption that areas exactly at the maxBounds edges are not going to be usable. Developers should add sufficient buffer to their bounds to factor that in.

[andrewharvey]

While emitting an error back sounds good, I'm not sure how this would be implemented in practice. Since map.flyTo` returns the map object so we can't just return an exit code of 0 for success and non-zero for an error.

Without a good way to do that, perhaps it is reasonable to expect the API user to make their own check before calling flyTo and then document exactly what will happen if you call flyTo (or any other camera operation) outside the maxBounds.