search

aytee / google-maps-utility-library-v3

Automatically exported from code.google.com/p/google-maps-utility-library-v3
Apache License 2.0
0 stars 0 forks source link

Moved marker disappears when using Marker Clusterer (Plus) #167

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Demo link or sample code:

The default example with minor modification has this problem for both 
MarkerClusterer and MarkerClustererPlus:
* http://www.haz.ca/MarkerClustererExample.html
* http://www.haz.ca/MarkerClustererPlusExample.html

The only change is using absolute urls to load the latest javascript libraries, 
and adding draggable:true to the marker creation.

What steps will reproduce the problem?
1. Create all the markers / add them to a marker clusterer object.
2. Zoom in to see an individual marker.
3. Move the marker to a new location.
4. Zoom out until the clustering kicks in (and groups the moved marker with at 
least one other marker)
5. Zoom back in to see the marker that was moved.

Expected result:
The original marker that we moved.

Actual result:
The marker disappears (but is included in the clustering count when zoomed out).

Version:
Maps - v3
MarkerClusterer(Plus) - latest

Browser / Operating System:
Chrome / Linux

Additional comments:
I've additionally added this as a StackOverflow post:
* 
http://stackoverflow.com/questions/9981763/moved-marker-disappears-when-using-ma
rker-clusterer

Original issue reported on code.google.com by christian.muise on 4 Apr 2012 at 3:23

GoogleCodeExporter commented 9 years ago 
I believe this is the same bug I've described in another issue, 168.

Original comment by oliveira...@gmail.com on 11 Apr 2012 at 3:41

GoogleCodeExporter commented 9 years ago 
I am using this method until fix will available:

google.maps.event.addListener(marker, 'dragend', function(event) {
  var mk = new google.maps.Marker({
    map: map,
    position: marker.getPosition(),
    title: marker.getTitle(),
    draggable: true,
    Icon: new google.maps.MarkerImage("deptstore.png")
  });       

  this.mc.removeMarker(marker);             
  this.mc.addMarker(mk);
}); 

very dirty solution - it causes problems with event listerens attached to old 
marker, but it works for my purposes

Original comment by v.zoberg...@gmail.com on 11 Apr 2012 at 4:57

GoogleCodeExporter commented 9 years ago 
I was considering doing the same, but I have too much built into the individual 
markers (listeners and such) -- re-creating it all would be a major issue for 
my app.

Original comment by christian.muise on 11 Apr 2012 at 7:46

GoogleCodeExporter commented 9 years ago 
This doesn't resolve the core issue, but I've done some digging:
* The disappeared marker is visible, has the right icon, and is assigned to the 
correct map.
* The problem arises when a marker is moved, then the map is set to null, and 
then the map is set back to the right one.

  Because of these things, I've modified the code to always maintain the marker on the right map, but just change its visibility (rather than set the map to null). This won't work if you hide invisible markers from the count, and it definitely causes a hit in performance (noticed with my ~460 marker application).

  Attached is the revised (uncompressed) library, and a diff of the fix from the current version of MarkerClustererPlus:
- 
http://google-maps-utility-library-v3.googlecode.com/svn/trunk/markerclustererpl
us/src/markerclusterer.js

Original comment by christian.muise on 17 Apr 2012 at 4:24

Attachments:

GoogleCodeExporter commented 9 years ago 
I believe that this is not specifically related to the position property of the 
marker, but with any property.

I've described, in issue 168, the same strange behavior caused by changing the 
"x" property of google.maps.Icon.origin. I also perceive it when using 
animation. Try to set any icon to bounce once it is clicked and you shall have 
the same bug. But, if you undo the changes you've made before the marker is 
clustered, then the marker behaves normally, being clustered and unclustered 
when it should. I have tried that.

Position, icon, animation... My guess is that this bug is due any changes in 
the marker properties, and that if you write down the position of the marker, 
moved it, and restore its position manually you won't find that bug.

Original comment by oliveira...@gmail.com on 17 Apr 2012 at 5:18

GoogleCodeExporter commented 9 years ago 
Interesting. Well resetting the position is definitely out of the question 
(since dragging it to the new location is the whole point). Hopefully one of 
the clusterer devs will get around to looking at this.

Original comment by christian.muise on 17 Apr 2012 at 5:52

GoogleCodeExporter commented 9 years ago 
I think Christian's comment below implies a fundamental Google Maps bug:

"The problem arises when a marker is moved, then the map is set to null, and 
then the map is set back to the right one."

Can someone on the Google Maps team check out whether this a bug in the 
marker-handling library?

Original comment by garylitt...@gmail.com on 21 Apr 2012 at 3:57

GoogleCodeExporter commented 9 years ago 
I now have a minimalist example showing the bug in action with a single 
standard (but draggable) marker. Setting a marker's map to null, then setting 
it back to the map works perfectly until the marker is dragged, then it doesn't 
work at all.

I'll file a report.

Original comment by garylitt...@gmail.com on 21 Apr 2012 at 4:19

GoogleCodeExporter commented 9 years ago 
Thanks Gary. Where does it get filed? (I'd like to monitor)

Original comment by christian.muise on 21 Apr 2012 at 4:25

GoogleCodeExporter commented 9 years ago 
The bug has now been filed:

http://code.google.com/p/gmaps-api-issues/issues/detail?id=4091

Please begin starring the issue!

Original comment by garylitt...@gmail.com on 21 Apr 2012 at 4:28

GoogleCodeExporter commented 9 years ago

Original comment by garylitt...@gmail.com on 21 Apr 2012 at 4:31

GoogleCodeExporter commented 9 years ago 
Google has now fixed this bug in the latest version of the API.

Original comment by garylitt...@gmail.com on 24 Apr 2012 at 4:25