Google Maps centre moves to the SE on changing layers

[CharlesHarrison]

Using IE 6 or 7 and OL 2.7 or /dev/, if you change the page layout under DHTML, all sorts of problems occur, one of the most disastrous being that the map centre may move several kms to the SE and back as layers are switched.

I've also seen something similar with a vector feature being left too far south when an Ordnance Survey map is recentred and zoomed, but if the layer is hidden and reshown using the layer switcher, then the feature reappears in the expected place. (I've feeling that might be a timing issue, trying to draw the features too soon after the map has recentred - I've no idea whether it's caused the same way as the Google problem or not)

I've seen various other bugs that seem to relate to this ...

 http://trac.openlayers.org/ticket/1797  http://trac.openlayers.org/ticket/830

... as well as this FAQ ...

 http://faq.openlayers.org/google/why-does-the-map-move-to-the-southeast-when-i-switch-to-a-google-maps-layer/

... all of which suggest the problem has been fixed, but it hasn't. See the following page for a demo of this and other IE specific bugs (this page uses /api/, but I've just satisfied myself again that it also happens under /dev/):

 http://www.macfh.co.uk/Test/SatelliteCalculator.html

[CharlesHarrison]

Changing title as now seeing this in FF3 also.

Load the following URL ...

 http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculator.html?iWhereHow=C&iUKPost=rg6+4aw

... wait for the values in the calculator (loaded from the URL) to stabilise, then press the button to create the Google map. Zoom in to max - 2. Switch to the satellite layer. Should be ok. Once the map has finished loading, show it in the Print Preview. Close the preview and switch base layers again. The map will move to the SE.

[CharlesHarrison]

Replying to CharlesHarrison:

Changing title as now seeing this in FF3 also. Load the following URL ...
 http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculator.html?iWhereHow=C&iUKPost=rg6+4aw
... wait for the values in the calculator (loaded from the URL) to stabilise, then press the button to create the Google map. Zoom in to max - 2. Switch to the satellite layer. Should be ok. Once the map has finished loading, show it in the Print Preview. Close the preview and switch base layers again. The map will move to the SE.

Also happening with ...

 http://www.macfh.co.uk/Test/Google_with_OpenLayers.html

[CharlesHarrison]

Replying to CharlesHarrison:

Also happening with ...
 http://www.macfh.co.uk/Test/Google_with_OpenLayers.html

As requested, a slightly simplified but functionally equivalent version of the test page:

 http://www.macfh.co.uk/Test/GoogleOpenLayersBugs.html[[BR]]

1) FF3 Printing Bug - drag the map so that the marker is near the top edge about 1/4 map width in from the left hand edge and print (without using Printview). The marker will either have gaps in it, or the missing pieces will be printed displaced and at the wrong angle. This does not happen with the Satellite or, zoomed out 2 levels, the Streets Layer

2) FF3 Printview Bug - Go into Print Printview. Close the Printview. Change to another baselayer. The map moves to the SE.

When I first wrote the Satellite Calculator page about 6 months ago, I tested it exhaustively under 2.7 /api/, and none of this was happening, but it's now happening under both 2.7 and 2.8RC2 (this demo uses the latter). As explained above, this seems to be a regression.

[crschmidt]

If it's happening under 2.7 and 2.8, it's not a regression in OpenLayers: Since '2.7' is a fixed set of code, there can be no OpenLayers regressions in that code. Instead, what you are probably seeing is a change in the Google Maps API.

This doesn't make it not a bug, but does make it not a regression in OpenLayers.

It is possible that the recent changes to #1797 may improve this some -- the Google Maps API changed since our most recent attempt to fix the problem.

[CharlesHarrison]

Replying to CharlesHarrison: I appear to be getting a number of false hits in my website stats on this, so let me confirm that the correct URL for my post (Comment 2) is:

 http://www.macfh.co.uk/Test/GoogleOpenLayersBugs.html

It would a good idea if someone authorised to edit Comment 2 could seperate the URL from the BR markup.

[ahocevar]

Please try if the latest patch attached to #1797 fixes the issue.

[CharlesHarrison]

Replying to ahocevar:

Please try if the latest patch attached to #1797 fixes the issue.

Can't comment about about the patch because I have no idea how to apply it, but the problem persists loading OpenLayers both with current ...

http://openlayers.org/api/OpenLayers.js

... and with dev ...

http://openlayers.org/dev/OpenLayers.js

[CharlesHarrison]

Replying to CharlesHarrison:

 http://www.macfh.co.uk/Test/GoogleOpenLayersBugs.html

In the hope that it will make for easier testing, I've altered the above example to use dev rather than current ...

http://openlayers.org/dev/OpenLayers.js

[tschaub]

Replying to CharlesHarrison:

Replying to CharlesHarrison:

 http://www.macfh.co.uk/Test/GoogleOpenLayersBugs.html

In the hope that it will make for easier testing, I've altered the above example to use dev rather than current ... http://openlayers.org/dev/OpenLayers.js

It looks to me like the problem described in the title of this ticket no longer exists on the above example. This was addressed in #1797.

Thanks for updating your example to use the latest from the trunk. This simplifies things.

I'm closing this ticket (calling it fixed with r10021). If you have another issue, please open a new ticket with a title that describes the issue (ideally one ticket per issue).

Thanks.