Update marker positition without redraw all markers

[gendalf]

I have lot of markers, and I want update position ( from socket.io data, traking ). Update only one marker... not redraw all...

I tries send event to old position marker, and then use setPosition of marker.. but after this marker ignore all events.

Will be nice send events by some marker id or other property from object, not by postion

[dylanfprice]

Yes identifying markers by an id instead of position is a bigger refactor I want to do when I get a chance, I just haven't had the time so far. For now I'm sorry but you'll have to live with redrawing all markers.

However, instead of doing it the way you described, I would suggest just updating the position of your object (in your gm-objects array) and then broadcasting gmMarkersRedraw. This will ensure the marker still gets noticed by angular-gm for events and such.

[wpalahnuk]

dylan, my current code uses an id instead of the position, I'll clean it up and submit a PR when I get a chance, should be in the next week or so.

[kevin1024]

I'm also interested in this, since my use case involves having multiple markers at the same coordinates.

[kevin1024]

Actually, I just tried my own implementation. Instead of comparing by ID, it directly compares the MarkerOptions hashes. If they already exist, it doesn't touch them. Otherwise it removes or adds them to get the marker list in the correct state. It's working pretty well. I'll put it online once I clean it up a bit.

[wpalahnuk]

I really like this idea, I still think you should have ID's for the markers so you can retrieve them from the container, but using the MarkerOptions as the hash makes much more sense.

My only question is, does using MarkerOptions as the hash update the object when the position changes?

[kevin1024]

I still think you should have ID's for the markers so you can retrieve them from the container

Why do you want to get the markers back out of the container? If you want to manipulate something about the marker, you should manipulate the marker list that the directive is watching. There shouldn't be a need to touch the actual markers in the google map object. That's the nice thing about providing an abstraction around google maps :)

My only question is, does using MarkerOptions as the hash update the object when the position changes?

Yes, any of the markeroptions changing or the position changing will reflect on the map.

The only problem I have now is I'm worrying about performance, since I have to hash the contents of the MarkerOptions object to compare the two hashes for changes - right now I'm using JSON, but I'm going to have to do some kind of key sorting before serializing to JSON since the same object can serialize to different representations depending on the order that they keys get used.

Update: perhaps bencoding to hash the objects?

[wpalahnuk]

Why do you want to get the markers back out of the container? If you want to manipulate something about the marker, you should manipulate the marker list that the directive is watching. There shouldn't be a need to touch the actual markers in the google map object. That's the nice thing about providing an abstraction around google maps :)

The abstraction is great, but for some things you need a handle on the actual google.maps.Marker object rather than the data it was built from.

My use case for this is automatically opening infoWindows on certain markers depending on a url parameter. I don't think there is any other way to do this, other than having the handle to the marker object itself.

[dylanfprice]

@gendalf I just released angular-gm 1.0.0 which stores markers by their id instead of position. To achieve what you wanted, do

$scope.$broadcast('gmMarkersUpdate', 'myObjects');

whenever your objects change. This will not redraw the markers, it will simply recompute all the MarkerOptions. This should achieve what you want. You can check out the docs for gm-markers here.

You can see an example of the same basic idea, but for the gm-polylines directive in the polylines example.

If you switch to 1.0.0, make sure to read the migration guide since there are a few breaking changes. Let me know if this works for you and if I can close the issue!