Here's a really ugly hack that gives you a workround.
http://econym.org.uk/temp/polartest2.htm
It's probably the ugliest hack I've ever written, but it won't mess
anything up unless you create a polar map type that actually uses zoom
level 17.
It works by testing whether the zoom level is 17, and if so the custom
.fromPixel.toLatLng() tells a lie that fools the API into doing the
right thing.
The hack has to be so ugly because you can't get at the code where the
bug really is. The GPolygon code and GLatLngBounds.intersects() are
inaccessible.
One downside is that you don't get any optimisation for off-screen
polylines. All the polylines are always rendered. If you zoom in to the
max zoom level in my example in MSIE and then try dragging the map,
you'll notice that it takes MSIE about 10 seconds to redraw all the
off-screen polylines. But I imagine that might be a modest price to pay
for being able to plot polylines at all.
I've logged an issue.
http://code.google.com/p/gmaps-api-issues/issues/detail?id=709
You might want to add your star to it.
--
http://econym.org.uk/gmap
The Blackpool Community Church Javascript Team
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Maps API" group.
To post to this group, send email to Google-Maps-API@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Maps-API?hl=en
-~----------~----~----~----~------~----~------~--~---
