Bing: Map with Bing maps doesn't refresh when browser maximize

[jennyhe]

Report from Autodesk QA

Steps:

1. Restore down IE first.
2. Open the web layout with Bings maps by this IE.
3. Maximize IE.

Results: Bings maps doesn't refresh. Please refer to the attached png file.

Expected results: Bing maps should refresh as others consumer layers.

[chrisclaydon]

This problem occurs because the class OpenLayers.Layer.VirtualEarth in the version of OpenLayers.js used by Fusion does not contain an override of the base class onMapResize() method (which does nothing).

The version of this class in the trunk stream of OpenLayers does implement the method as follows:

    /**
     * Method: onMapResize
     */
    onMapResize: function() {
        this.mapObject.Resize(this.map.size.w, this.map.size.h);
    },

Pasting this into the OpenLayers.js used by Fusion resolves this defect. I will attach a patch for this.

[chrisclaydon]

Patch to add onMapResize method to OpenLayers.Layer.VirtualEarth class

[chrisclaydon]

Submitted patch (reviewed by Mike Adair):

http://trac.osgeo.org/fusion/changeset/2023

[liuar]

Information from Jenny - When testing on the latest build, I noticed although the Bingmap refreshes correctly, the layer in map doesn't.

[madair]

ok now I've figured out what "restore down" is and the patch does indeed solve the issue. I don't understand the issue being re-opened, what do you mean by "the layer in map doesn't (refresh)"

Note also that the PNG attached is showing Chrome and not IE

[liuar]

Actually, the defect had been partial fixed. After restore and miaxmize the browser, the MapGuide Map and Bing Map is not matching anymore. If user pan/zoom in/zoom out the map, then the MapGuide map and Bing Map can match.

[chrisclaydon]

I've added !OpenLayersPatch2.patch. This resolves the problem where other layers do not resize correctly when the base layer is a Bing map.

The cause of the problem is that after VEMap.Resize() has been called on the Bing layer, it still takes a while before this layer adjusts to the change. In the meantime, the other non-base layers try to resize too, but their offsets are calculated incorrectly, because they rely on the base layer to calculate the pixel offset of their top-left corner in mapping coordinates.

The patch adds an event handler to redraw all the non-base layers when the VEMap object has actually finished resizing, and is thus able to return the correct pixel offsets.

I will be making this change to the adsk/2.2gp sandbox. Please review and let me know if it should go into trunk.

[madair]

redoing the patch without all the whitespace changes and for the OpenLayers 2.9.1 version and applying to trunk. This fixes the issue of overlays not lining up when then map initially loads.