panTo should use tween if new center is in the current bounds + a ratio

[pgiraud]

I think that the comparison with the current bbox to choose if the panning is animated or not is too strict. We should add a ratio to the bbox before we check if it contains the new center.

[euzuro]

+1

[pagameba]

what sort of ratio do you think would be aesthetically pleasing? Or should it be definable through map options and default to some reasonable value (1.25?)

[sbenthall]

Patches added. As part of the solution to this, added a "scale" method to the Bounds basetype that scales the bounds with a ratio and an origin (the origin defaults to center). Added tests for this method.

For the actual panning feature, there is a new property, panRatio, on the map (that can be set in an option).

Waiting for review.

[elemoine]

sbenthall, just a comment related to the scale method in the OpenLayers.Bounds class. How about having: scale(ratio, x, y), scalePixel(ratio, pixel) and scaleLonLat(ratio, lonlat) with the last two being based on the first, to be in line with what's done with contains. What you think? It's up to you actually, your patches look to me anyway.

[pagameba]

When a bounds object is in pixel space, using scale() may result in non-integral values of left, top, right and bottom - is this okay (using scalePixel and scale LonLat could avoid this)

[euzuro]

this is all three of seb's patches bundled into one.

[euzuro]

pagameba -- i see you have some concerns with this patch. i'm assigning it to you... can you clarify what you think the issue is (and any proposed solutions you might have?)

[pagameba]

my concern was that the scale function magically determines if the passed in object is a LonLat or Pixel but doesn't attempt to ensure that Pixel values are integral values after scaling. Browsers ignore fractional pixel values as far as I know, but may deal with them in different ways (rounding, floor, etc) so I think it would be better if we are scaling pixel values to be intentional about making sure they are integral values. But maybe I am being paranoid or stupid about this in some way? Right now this is only going to be used for scaling lonLat bounds as part of the test in the panTo function. I'm not convinced this would ever be used to scale Pixel values that would consequently be used to *position* something in the browser in which case my concerns are not very valid.

Does anyone else have an opinion on whether we should care about ensuring Pixel values are integers or not? If yes, I'll make the necessary changes to the patch. If not, it can go in as is as I doubt it will cause any immediate problems.

[crschmidt]

Paul,

This code creates a bounds by scaling a ratio around an origin, and the origin can be a bounds. I don't see any reason to be concerned about this. (Certainly, we make no promises about members of bounds being integers.) With that in mind, although I understand your concern, I don't think it's relevant. We should treat values where we set some browser display pixels based on a bounds object with care, but I don't think this changes that at all.

With that in mind, I'd say that although I understand your complaint, I don't think it's really relevant to this.

I think this patch is fine as is.

[crschmidt]

(In [7678]) "panTo should use tween if new center is in the current bounds + a ratio". Add a bounds.scale method (takes a ratio and an optional center) and call it from the panTo to give a ratio we can pan inside of. Patch by sbenthall, r=me,elemoine (Closes #1341)