How to select a set of points to display from a larger set of points?

[djeyewater]

For a given view / boundary box, I might have 200 points that fall
within those coordinates. 150 of those points might have the same (or
nearly the same) co-ordinates, and 50 have different co-ordinates. If
I only want to display 50 points for the given boundary box / view,
how would you select which 50 of the 200 to display?

Would you do some calculations to work out the distance of each point
from every other point so you can get the greatest coverage of points
for the given view / boundary box? This seems like it would be quite
resource intensive to calculate.

Or would you just select 50 random points? If you did this, would you
employ some sort of method to ensure that the same 50 points are shown
every time for the given view / boundary box?

Or would you use some other method to select which 50 of the 200
points to show?

Thanks

Dave

[Rossko]

> For a given view / boundary box, I might have 200 points that fall
> within those coordinates. 150 of those points might have the same (or
> nearly the same) co-ordinates, and 50 have different co-ordinates. If
> I only want to display 50 points for the given boundary box / view,
> how would you select which 50 of the 200 to display?

Can you tell us why you would want to do that? There may be another
strategy.

[djeyewater]

This post here explains the thinking behind it:
http://bbs.keyhole.com/ubb/ubbthreads.php?ubb=showflat&Number=46113#Post46114

Basically, if you have a lot of points, you only want to serve a
limited number of these to the user, partly because it could take them
a long time to download a KML file with many points, but mainly
because Google Earth will become very slow if you try and load too
many points into it.

[Rossko]

The most elegant approach would be to run some sort of server side
clustering ; aggregate nearby objects into a single placemark, with
some sort of synthesized description about the merged representation
e.g. "22 things here". There's be no actual loss of detail on your
end display, no mysterious omissions (so far as the end user is
concerned).

There are some well known techniques to do this sort of thing used
with the Maps APIs, they are generally written to aggregate by
proximity in one way or another. There are open-source javascript
'clusterers' that you can lift the techniques from and implement in
the language of your choice. I haven't seen one that outputs KML
directly, but that's just a matter of formatting.

Aggregation to a particular number of points in view would require
some further work.
However, if your objects truly have a high degree of position
coincidence , you might not need to go that that far, just "cluster"
in a standard way by proximity.

[SlowTarget]

http://www.travelodge.co.uk/explore_the_uk/

saw this site... and thought of you ... but I think its javascript
rather than KML

An elegant solution - exactly as described.

Circles with numbers in where icons would otherwise overlap (or a
"synthesized description about the merged representation") , and the
circle gets bigger as the number gets bigger.
The site is far more elegant than my explanation though...

[djeyewater]

Thanks for the info Rossko, and thanks for the example SlowTarget. I
think 'cluster' must have been the secret keyword I was missing when
searching for info. I get a lot of useful results when searching for
"google maps cluster php", but haven't had the time to look into it
properly yet. Anyway, certainly looks like what I wanted.

Cheers

Dave