Mouse wheel scroll should zoom in/out over mouse pointer location

[sderle]

at present it simply zooms in/out over the map center. this is actually kind of counterintuitive.

[fredj]

MouseDefaults.js patch (mouse wheel)

[fredj]

MouseDefaults.js.diff patch should fix it.

Note that the mouse position is stored in defaultMouseMove and used in onWheelEvent because mozilla has a bug with clientX and clientY and the DOMMouseScroll Event. See  https://bugzilla.mozilla.org/show_bug.cgi?id=352179

Tested with FF 1.5 and IE 6.0

[crschmidt]

Needs review, but is also pending on an ICLA. Mail sent to dev list looking for fredj.

[sderle]

I have reviewed this patch and I approve it for application to trunk, pending receipt of the submitter's ICLA.

[euzuro]

patch applied to trunk with r1945. thanks frédéric!

[euzuro]

I'm reopening this ticket because I believe that it can be made better. This is based on comments from users@ list by John Cole:

I saw that mouse wheel zooming recently changed to zoom to the point under
the mouse.  Unfortunately, there is a problem with the current
implementation.  It would be nice to have an option to use the simpler zoom
in/out on center also.

When you allow multiple zooms on the mouse wheel, you will end up somewhere
other than where your mouse is.  The reason for this is the new center point
is calculated with the new zoom level boundaries, instead of the original.
The mouse zoom should not update the extent until the map has reloaded.

For an example, using the SVN openlayers, bring up a map with the
mousedefault control, put the mouse over a feature near the edge of the map
and give the mouse wheel a good turn up (zoom in), the new zoom point will
have drifted way off, and your feature will not appear on the map.  If you
scroll only on click, it works perfectly.

Contrary to previous belief, gmaps does not zoom in on the mouseposition point, but rather zooms in/out in a manner such that the mouseposition point's geoequivalent remains the same at the new zoom level. Which is to say that if you're looking at a map of europe and you hover over moscow way on the far right and then you mousewheel in or out... at the new zoom level, moscow will still be exactly where it was (far right) in the previous level.

Obviously, this is not simple as it requires more than just a simple zoomIn() or zoomOut() -- it will require panning as well, or a calculation of the new centerpoint.

At any rate, I think J.C.'s comments prove this something that we should look into.

[euzuro]

furhter mousewheel-related comment from John Cole's email (see above) that I believe is worth looking into:

Finally,  when mouse wheel zooming, if you zoom in or out and back to your
original level, it should be treated as a pan or simply canceled, so the
layers don't (necessarily) have to be refreshed.

[openlayers]

MouseDefaults_2.js.diff should fix the mouse position problem reported by John Cole.

I needed to get the resolution for the next/previous zoom level and maybe

this.map.baseLayer.resolutions[this.map.getZoom() + 1]

is not the most elegant solution ...

fredj

[openlayers]

cleaner version: change Map getResolution to accept an optional zoom level. fredj

[sderle]

fixed by r2548.

[sderle]

actually not fixed yet.

[sderle]

During the hack week, I ran right past this comment (extracted from MouseDefaults.js into Handler/MouseWheel.js) without paying any attention to it:

// add the mouse position to the event because mozilla has a bug

// with clientX and clientY (see  https://bugzilla.mozilla.org/show_bug.cgi?id=352179)

// getLonLatFromViewPortPx(e) returns wrong values

Caching the mouse location on mouse move works around this -- in fact, this is what MouseDefaults used to do, only it's done in the MouseWheel handler now. Also fixed the math in Control.Navigation. See the attached patch.

[sderle]

see  http://trac.openlayers.org/ticket/341#comment:18 for description

[euzuro]

all tests pass in FF and in IE6. i dont know much about the handlers code, but this seems like a reasonable patch. maybe run it by tschaub or cr5. looks good by me though.

[crschmidt]

Committed in r2877. Good work, brings back functionality that we lost in the migration to the handlers code.