d2a32d5 accidently changed the number of assertions in the
test_selectFeature function, so the change in behavior that no
beforefeaturemodified event is called any more in non-standalone mode got
unnoticed: Before unhacking ModifyFeature, the SelectFeature control
called the beforeSelectFeature method directly. Now, without a built-in
SelectFeature control, we need to call it from the selectFeature method in
both standalone and non-standalone mode.
With two nested controls (DragFeature, SelectFeature), which - among
others - activated two OpenLayers.Handler.Feature instances, the
ModifyFeature control was fragile and hard to debug.
The issue that @iwillig, @bartvde and myself tried to track down was
that the two Feature handlers interfered with each other, making it hard
to select features on mobile devices, and causing points to jump during
dragging because of not updated last pixel positions.
With this refactoring, there are no more nested controls. All that's left
is a Drag handler. All tests pass. I had to remove one test that checked
for dragging of an unselected point while another was selected, because
now (and partially even before this change, thanks to the ugly drag
handler hack that is now removed) dragging a point will also select it,
saving the user an extra click.
Quick explanation:
Let targetCenterPx be described by PX and PY. Let oldRes and newRes be R0 and R1 respectively. Let centerPx (center after zoom) be described by CX and CY. And assume there is some anchored pixel point out there that represents the same map location before and after zoom. Let this be the origin OX and OY.
We want to recenter the map on the provided box. This means the map distance between the origin and box center at R0 is the same as the map distance between the origin and the map center at R1.
That is,
R0 * (OX - PX) = R1 * (OX - CX), and
R1 * (OY - PY) = R1 * (OY - CY)
Or, solving for OX and OY:
OX = (R0 * PX - R1 * CX) / (R0 - R1), and
OY = (R0 * PY - R1 * CY) / (R0 - R1)
The properties
* layers
* queryVisible
* url
* layerUrls
* infoFormat
* vendorParams
* format
* formatOptions
should all be visible in the public API since they are essentially very
convenient to use when customizing the control.
The geodesic-property is used inside of our examples, yet isn't officially
part of the public API.
The displaySystem-property provides a very useful way of configuring the
output of the measurements and should be promoted as well.
IE9 leaks when `navigator.geolocation` is accessed (see #461). The goal of this change is to avoid that leak in builds that include the Geolocate control but do not use it.
The navigation control gets better defaults, and the MouseWheel handler
gets a new maxDelta option, which can be used to avoid huge zoom level
jumps on heavy wheel/pad movements.