Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Strategies for a MapView with LOTS of pins/annotations

I'm interested to hear how others have handled the situation of a MapView with too many annotations. This seems like a pretty common thing that several app developers must run in to, but I haven't seen too many best practices or defined strategies for overcoming it.

Example Situation

You have an app that places an annotation at every gas station. When zoomed in to a pretty tight level, you may see a dozen or so pins. But the more you zoom out, the more you see, until it becomes problematic for both usability and performance.

My Idea (Feedback on this please)

Conceptually separate the MapView into a grid of 100 cells (10 high x 10 wide). When any cell contains more than X number of items, instead of displaying those annotations, display a single annotation [of a different color] centered in that cell. This annotation, when selected, displays how many items there are in this cell, and tells the user they need to zoom in. This annotation would also likely have a button that performed the zoom for them.

— asked September 20th 2010 by Bart Lewis
  • mapview

6 Answers

  • I also have a need for something like this.. but the points on my maps are fairly static. I was planning on handling this on a web page. But was thinking that using some kind of json file to create a map would also be an option. I would just refresh the JSON file from the web.
    I was also going to use DRUPAL as my backend JSON and/or web server.

    — answered September 20th 2010 by vincent youmans
  • I have a similar situation. I have decided to limit the number of pins for each query. So I do SELECT … LIMIT 200. It seems like the map view can handle a lot of pins, just not adding a lot at a time. Are you seeing the same thing, or does the performance suffer for you just by having a certain number of pins present period?

    I also allow the user to jump to another location at any time, and when I do that I call removeAllAnnotations() first so the old ones at the previous location are not kept in memory, just in case the number of pins present does affect the performance. If the user pans the map around I do add new ones as they go, but don't remove the old ones.

    I'd like some help in this area too, to improve map view performance.

    — answered September 20th 2010 by Randy Hall
  • This isn't a solution but you can see how clustering annotations would look. Toward the bottom you'll see DTClusterMaker.


    — answered September 20th 2010 by John McKnight
    1 Comment
    • Right. I found that as well. The thing I don't like about that implementation is that the clustered pin's action simply unclusters it. Makes way more sense to me to have the action be a zoom to point.

      — commented September 20th 2010 by Bart Lewis
  • I have this issue too, I have over 900 POI's and its growing, adding markers on the map severely slows the device, removing the animations speeds up the process slightly, but still not good enough, I have got around it by only showing some of the markers at a time, they can be split by who owns them. But its not an ideal solution, I would much rather see a Titanium implementation of marker clustering.
    Especially as a webview, whilst would work, doesn't have tight integration with passing data from a SQLite db, which is how I have stored my data.

    However, if anyone has a working example they could share it would be so much appreciated, either via webview or native maps.

    — answered January 13th 2011 by Ian Tearle
  • The problem of many Pins on a map exist on any client. Javascript, mobile of desktop. The only efficient way to handle this is to incorporate the pins as pixels on the map tiles themselves.

    If the limit is 200, 900 or as I experienced with JavaScript: 16000 is somewhat dependent on the device, gfx cpu and the amount of ram.

    If one needs to many pins on a map, setting these with the client will eventually slowly and steadily kill your app.

    If google offers layering with pixels in the bitmaps I am not certain about, but the tileserver we use in our company does. We used ESRI and put the pins on the tiles using layered maps on the ESRI server. I am not certain if the map functions in appCelerator supports this, but I am pretty certain the webView does.

    Annotations are added on the client only for the pins visible in the display, limited to an amount which one safely can assume the client can handle.

    I offer no solutions here, but adding more than a limited number of pins in a map on the client will eventually lead to a grinding halt on your device…

    — answered January 13th 2011 by Harald Sakshaug
    1 Comment
    • I think everyone gets that adding many pins on a map is an issue, and im pretty certain we would all like to see a solution where by a tested means (on web at least) of clustering markers natively with appcelerator or a means of integrating device app data with a webview offering clustering services. Your option does not seem valid nor does it help anyone else who has posted on this subject. The only live app I have seen which does clustering is the National Trust app, but I cannot figure out which they used, a web container or a native maps hook. I would love to know.

      — commented January 13th 2011 by Ian Tearle
  • The only right solution is to use a clustering. In the web google map api world are lot of solutions. In relation of zoom level (in our world = region) a part of markers (in our world = annotations) will suppressed displaying of superfluouses annotations. There are a lot of rules to do this.

    What we need is a annotations manager. It collects teh annotations and controls displaying of annoations.

    Any ideas?

    — answered August 8th 2011 by Rainer Schleevoigt
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.