Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fitBounds and jumpTo should refer to each other or be renamed #3482

Closed
tmcw opened this issue Oct 28, 2016 · 5 comments
Closed

fitBounds and jumpTo should refer to each other or be renamed #3482

tmcw opened this issue Oct 28, 2016 · 5 comments

Comments

@tmcw
Copy link
Contributor

tmcw commented Oct 28, 2016

Many examples use fitBounds and I and others have had trouble figuring out that fitBounds and jumpTo, methods that don't sound like each other at all, do the same thing with/without animation.

Documentation proposal

For fitBounds:

Pans and zooms the map to contain its visible area within the specified geographical bounds. This uses animation to make the transition smooth: you can move to a new area or zoom level instantly by using jumpTo.

For jumpTo:

Changes any combination of center, zoom, bearing, and pitch, without an animated transition. The map will retain its current values for any details not specified in options. You can move to a new area or zoom level with a smooth animation by using fitBounds.

API Proposal

  • fitBounds
  • animateFitBounds
@tmcw
Copy link
Contributor Author

tmcw commented Oct 28, 2016

Actually this was based on a misconception, that jumpTo could also accept a bounds. What is the best and most obvious ways to fit to a bounds without animation? On a thorough read of the current documentation, I do not see it.

@jfirebaugh
Copy link
Contributor

Previously: #1473.

@lucaswoj
Copy link
Contributor

lucaswoj commented Nov 1, 2016

Would it be fair to close this as a duplicate of #2801?

@tmcw
Copy link
Contributor Author

tmcw commented Nov 1, 2016

If you add more detail, sure - while #2801 discusses that the names need an update, this issue proposes a potentially new method entirely or a potentially new camera option in order to alleviate a gap in the current API.

@tmcw
Copy link
Contributor Author

tmcw commented Jun 26, 2017

Closing in favor of #2801

@tmcw tmcw closed this as completed Jun 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants