markerclusterer - separate overlay into two different panes

[GoogleCodeExporter]

Using release 2.0.1 I have had to move the overlay rendering of the cluster 
icon to different pane to ensure normal marker icons do not appear behind the 
cluster overlays.  Unfortunately, this has the side affect of eliminating the 
ability to interact with the overlay via clicks, which would result in a zoom 
if enabled.

As I understand it, normal markers are rendered along with a separate 
transparent clickable element of the same size in a different pane on the map.  
Cluster icons (overlays) would be completely compatible with other marker 
objects if the same or similar were done.  In fact, I suspect simple z-index 
values could also be applied if a method were provided as well, giving complete 
control.

Here's the change I made to render the cluster icon in the pane with the normal 
markers - which partially address this need.

(at or around line 120)
//this.getPanes().overlayMouseTarget.appendChild(this.div_);
this.getPanes().overlayLayer.appendChild(this.div_);  //added to make sure 
clusters fall behind markers

Thanks for considering this!

P.S. I think the rendering the cluster in the overlayMouseTarget somehow causes 
some issues with zoom and scroll sometimes causing cluster icons to not appear 
at certain zoom levels, but I could be wrong.

Original issue reported on code.google.com by d...@daleshaw.com on 8 Sep 2011 at 6:05

[GoogleCodeExporter]

I believe the reason for putting cluster icons in the overlayMouseTarget pane 
was to ensure they would always be "frontmost" so you could easily click them 
to zoom in.

Even if you could live without that capability, since the cluster icons are not 
implemented as standard markers, moving them to the overlayLayer pane will 
involve a bit more work than the one line change you're suggesting. There might 
be issues when trying to click a cluster icon in the shadow of an InfoWindow, 
for example. I suppose they could be converted to standard markers, but that 
might cause side effects I haven't thought of.

Original comment by garylitt...@gmail.com on 8 Sep 2011 at 9:31

[GoogleCodeExporter]

Sorry - I never meant to imply that my one-liner would solve the problem.  I 
was simply providing the partial solution of how to move the image portion to 
the overlayLayer.

I propose that the clickable elements are separated in the very same manner as 
those of the standard markers - which seem to work fine in conjunction with 
shadows, etc.  If it works for markers, what would make it different for the 
cluster overlays?  Marker images already reside in the overlayLayer if I 
understand correctly.  The same sized transparent clickable element is in the 
mouse target.

BTW - I think shadows are in a  different/lower non-interaction pane, but I 
could be wrong.

Original comment by d...@daleshaw.com on 9 Sep 2011 at 4:43

[GoogleCodeExporter]

Ok - had a closer look at the code...

Every place that "this.div_" is manipulated and shown/hidden, couldn't we just 
also produce a second transparent "this.clcikDiv_" of the same size (and 
position) that is placed in the overlayMouseTarget pane while the image resides 
in the overlayLayer?  Then any event bindings can be pointed at the clickDiv_ 
instead?

Original comment by d...@daleshaw.com on 9 Sep 2011 at 5:11

[GoogleCodeExporter]

That would be how to do it but then it does involve there being double the 
amount of divs in use.

Original comment by lu...@google.com on 14 Sep 2011 at 5:16

[GoogleCodeExporter]

Doesn't seem to be worth the effort especially since you'd lose what I think is 
an important feature: clustered markers appear in front of all other markers.

Also, creating another set of DIVs in the overlayMouseTarget pane may not work 
if you're working with optimized markers. If I remember correctly, doing this 
caused problems with MarkerWithLabel, so MarkerWithLabel markers are not 
optimized.

Original comment by garylitt...@gmail.com on 18 Sep 2011 at 2:36

[GoogleCodeExporter]

Original comment by garylitt...@gmail.com on 29 Sep 2011 at 8:04

• Changed state: WontFix