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)
There are still tests failing, but this change addresses some of the new failures after 4b163e0482 (which is an awesome improvement despite the test failures :).
Bootstrap CSS sets the max-width for images to 100%. This makes it so
OpenLayers maps don't render (the layer container has 0 width, so all images
are given the same). Even if our layer container had a more sensible width
(e.g. 100% of the viewport), we would still have issues with tiles that are
larger than the viewport.
Since the OpenLayers stylesheet may be loaded before or after bootstrap.css,
we should use !important when setting the max-width to none for images we
control.
As suggested by @mpriour, it would be nice if the user could determine how
date values are encoded in literal elements. Extending this beyond date
values, we can provide an `encodeLiteral` method that can be overridden to
provide application specific behavior.
Bing Layers should fetch metadata over HTTPS when the document is server over HTTPS. Rewriting image URLs to use HTTPS will be handled separately (see #700).
The [URI standard](http://tools.ietf.org/html/rfc3986#section-4.2) allows for URI without a scheme. Where http is used to load the app, using a schemeless URL for the Bing metadata loads a script using http - and the same goes for https.
To make custom builds easier, it's convenient to have a OpenLayers.Request depend on OpenLayers.Request.XMLHttpRequest (see 18b4d6808d). This makes it so we don't know which is going to be included first. To get around this, we can be careful about when we define OpenLayers.Request.
After the website infrastructure changes (cadb20c18a), the release script now puts stuff in /osgeo/openlayers/sites/openlayers.org (instead of /osgeo/openlayers/docs).
The svn interface to our repos on git is not behaving well. This is resulting in the website, examples, and api docs not being updated when they should (`svn up` is not doing what it should).
Instead of using svn checkouts, we should use clones of the git repos. At the same time, it makes sense to organize things a bit. These changes depend on a new structure on the openlayers.org machine:
/osgeo/openlayers/repos - clones of our openlayers, docs, and website repos
/osgeo/openlayers/sites - sources for openlayers.org, dev.openlayers.org, and docs.openlayers.org
Where things are "built" (e.g. minifying js and modifying example markup to point to that js), changes are now made outside of the repo cleans. Having dirty repos was another source of build failures.
Changes still need to be made to the release process/script.
When we upgraded to git, we didn't fully change over the way the website and examples are built. The cron job that runs the update script only built the website & examples if the revision returned by the svn interface to the GitHub repo was different than the previously stored revision. At some point, using `svn info` on the repo stopped being reliable. For example, this is what I get when running this today (in 2012):
svn info https://github.com/openlayers/openlayers/
Path: openlayers
URL: https://github.com/openlayers/openlayers
Repository Root: https://github.com/openlayers/openlayers
Repository UUID: d631b94f-4ba7-6298-eb8f-ce57b7db7bff
Revision: 5488
Node Kind: directory
Last Changed Author: schuyler.erle
Last Changed Rev: 5488
Last Changed Date: 2006-05-12 12:35:22 -0700 (Fri, 12 May 2006)
(Last change looks like it was 6 years ago.)
We should be using a proper clone of the git repo and building the website and examples out of this. Until then, we can at least use `git-ls-remote` to check what the latest HEAD from the canonical repo looks like. This should get the website and examples building again (they stopped being updated a few weeks ago).
After great sleuthing from @elemoine, we have a solution closer to the heart of the problem. In a funny twist, the excessive call to `updateSize` ended up hinting at the solution. Thanks to `git bisect` for making things a bit easier.
The Yahoo API doesn't accept quotes in the callback (e.g. foo['bar']). Since the callback registry is an object and all identifiers are prefixed with "c" now, we can use dot notation.
In f08119b01e, the default syntax for the script protocol's callback made it so the callbacks looked like `OpenLayers.Protocol.Script.registry[c1]`. This essentially breaks the script protocol everywhere except where `c1` is defined and equals "c1" (the string).
Tests with this change demonstrate that default callbacks will now look like `OpenLayers.Protocol.Script.registry['c1']` (properly accessing the `c1` property of the registry object).
Sticking with sans-serif gives a more uniform experience on desktop Webkit, Safari on iOS, and the default Android browser.
Using `-webkit-tap-highlight-color` gets rid of the blue highlight when clicking on the map tiles or zoom control.
The UTFGrid layer's `getTileInfo` method was not correctly handling dateline wrapping (and was a bit more complicated than it needed to be). Since it would be useful to all grid layers to be able to retrieve a tile and pixel offset for any map location, this functionality deserves to be on the Grid layer.
The WMTS layer currently exposes a `getTileInfo` method that is used within the layer and by the WMTSGetFeatureInfo control. This method could be renamed to `getRemoteTileInfo` or something to differentiate it from a method that gets locally cached tile info. Until that change is made, the method on the Grid layer will be called `getGridData`.
The zoom control allows for zoom in/out links that can be styled with CSS.
Note: This change was originally captured in #269. It involves nice additions thanks @ahocevar. The changes were unintentionally merged and then reverted with fb3caf1561, so the history of commits is not immediately apparent (though still likely there somewhere due to the magic of git).
Previously, a map could not be destroyed if it included a permalink control without an "element". In addition, a permalink control could not be destroyed if it didn't have a reference to a map.
Tim Schaub