Draggable vector geometry breaks when near edge of map and map is zoomed in

[CharlesHarrison]

There was some further discussion about this in Ticket #1860 after that problem was fixed. Basically there are two symptoms, which may be of two underlying problems or just different symptoms of one underlying problem.

1) Zooming when a marker, consisting of a vector geometry/collection, is near the edge of the map breaks the marker.

This can be demoed here:

 http://www.macfh.co.uk/Test/UKOrdnance_Survey_with_OpenLayers%20-%20Marker%20Bug.html

A fix for this zoom bug is to define a zoomend listener that removes and replaces the marker, as follows ...

"zoomend": UKOSZoomEnd

function UKOSZoomEnd( anEvent )

{
if( UKOSMarkerF != null )

{
UKOSVectorL.removeFeatures( [UKOSMarkerF] );
UKOSVectorL.addFeatures( [UKOSMarkerF] );
}

}

This listener is the only functional difference between the buggy and the following working demo ...

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

2) At high zooms, graphics which are part of the marker disappear. This seems to be related to Ticket #1782, seems most prone to happen in Firefox 3, and can (sometimes) be demoed here ...

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

... or here ...

 http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculator.html

For the latter, choose, say, 'UK Placename' or 'World Placename' under 'Entry Method', type in 'London' or wherever, tab out of the entry box to set the value typed, then click each map button. Two maps will be drawn. Putting either or both to near maximum zoom may well lose the graphic in its marker.

I was hoping that Patch #1782 would fix both problems, but it doesn't. This is how the two bugs and that patch interact:

Without zoomend listener and without Patch 1782: 1 and 2
With listener and without Patch 1782: 2
Without listener and with Patch 1782: 1
With listener and with Patch 1782: Initially everthing looks alright, but if a situation is created where formerly 1 would have occurred, we now have 2 instead!

[crschmidt]

CharlesHarrison: Your demonstrations both use openlayers.org/api/OpenLayers.js. This code does not include the fix for #1782. Can you explain how you are including #1782 in these demos? Or is it that you expect if a developer downloads the HTML and modifies it, it will still demonstrate the problem? (I'm more likely to poke at it and possibly kick it to 2.8 if you can set up a copy against trunk for me: just change /api/ to /dev/...)

[CharlesHarrison]

Replying to crschmidt:

Hi Chris, thanks for the prompt response.

Your demonstrations both use openlayers.org/api/OpenLayers.js. This code does not include the fix for #1782. Can you explain how you are including #1782 in these demos?

Formerly I had set up a special test page rather in the manner you describe, but pasting in the patch rather than calling /dev. However, I've encountered so many mapping bugs in so many different browsers that various test pages have changed functions more than once. Currently, there is no test page for this bug/these bugs that includes the patch, but the live Satellite Calculator page linked above includes it (from line 1366), and so does the test calculator page that I wrote to demo all the IE mapping problems (from line 1346):

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

Or is it that you expect if a developer downloads the HTML and modifies it, it will still demonstrate the problem? (I'm more likely to poke at it and possibly kick it to 2.8 if you can set up a copy against trunk for me: just change /api/ to /dev/...)

(Just to note, as you probably realise, this could only work under localhost, unless you change the mapping API keys to ones of your own, mine are tied to www.macfh.co.uk)

I don't think that will be necessary! Under localhost on my PC, I've just tried including /dev rather than /api in the bug demo page, and both problems seem fixed.

So why the results above? Just to be certain, I tried pasting in Patch #1782 rather than calling /dev, and all but the last combined result are still reproducible. There must be something else fixed in /dev that also fixes these problems!

As the fixes are already in /dev, presumably they will go live with v2.8. Is there a date for that yet?

[crschmidt]

Target date is April 20th.

So, trunk fixes all your problems. Great! I'm closing this ticket as worksforme, in that case.

Thanks for the help.