The task is quite common in map drawing applications and the solution is also common: 1. Create a spatial index - two-dimensional matrix where each item represent a cell on the screen. The number of cells/rows could be be calculated from screen/icon proportions. However the size of this index should be in longitude/latitude units (it should be scale independent - see below) 2. Only items from this index are shown on the map and only one icon can be shown on in a cell (you can have an icon which indicates multiple items per cell) 3. Number of cells is always the same and it much less than 7000 original objects. 4. Each time you change the scale of the map you clear this matrix and go through source objects and put an object into a cell if it is empty and objects lat/long belong to it. With 7000 items it should be fast enough but when you will have millions of them you may have two indices and use old index while a new one is being calculated asynchronously. This is why index must be in lat/long units, not screen pixels. 5. While the map is moving (finger is on the map) you don't need to update the matrix, only when the moving is complete. It also requires the index being stored in lat/long.
Such approach gives you flexibility (any scale, any number of objects) while the drawing complexity depends on the size of the matrix only. BTW: I also found overlay more efficient than itemized overlay. On Jan 21, 10:24 pm, Stephan Wiesner <[email protected]> wrote: > Thanks. > My current solution is still that I only display markers in a certain > radius of the center. That works fine, as the markers are peaks/cabins > in the swiss alps and the user knows where the peaks are anyway. > If I want to expand my app, though, I need a solution that scales. By > now I have found several Javasript APIs, that handle this problem in a > way similiar to what you suggested: by clustering markers. > e.g.:http://google-maps-utility-library-v3.googlecode.com/svn/tags/markerc... > > I haven't found the time to solve that yet, as it is not pressing at > the moment. But I will probably define areas (e.g. Berner Oberland, > Wallis, Tessin) and countries and cluster the markers located there. > > Stephan > > ------- > Interessiert an Android?http://android-schweiz.blogspot.com/ > Whant to learn German?http://german-podcast.blogspot.com > > On 21 Jan., 17:31, Brill Pappin <[email protected]> wrote: > > > > > > > > > We had an issue like that in an experimental app we never released. > > > What worked for us was that we merged points that were overlapping on the > > display depending on the magnification. > > > The further in you go, the more those merge point break out, which keeps the > > number of points to a manageable level for the developer and a usable number > > for the user. > > > You will need to create a custom point though so that it looks right and its > > clear that points are merged. > > > - Brill Pappin -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
