| QUOTE (lignumaqua @ September 18, 2013 09:36 pm) |
My comment 'not on a map' was related to the difficulty of interpreting the results, not of creating the map. Image may be NSFW. Clik here to view.  |
Thanks for explaining although I am now even more puzzled. My expectation is that clustering based on FPs (rather than numbers of caches) makes interpretation EASIER. The challenge was to find an efficient way to trick the Google Maps clustering function to provide this map based on FPs. I'll come back to this after the next point ...
| QUOTE (lignumaqua @ September 18, 2013 09:36 pm) |
If we are looking for quality, not quantity, then I've tried the following procedure, which seems to give some aid. 1. Filter the database to caches with favorite points > 5 (or other perhaps higher value you choose). This is our quality filter. 2. Map this selection using the GoogleMapsV3 macro 3. Right-click on the map and set the clustering grid size to 100. This will cluster most caches and the cluster size will now be a good indication of local density. |
This looks rather like what I wrote in my first post as a not so ideal solution as it does not differentiate between caches with 150FPs and ones with 5 FPs ...
| QUOTE (Image Maker @ September 17, 2013 03:08 pm) |
| I could also filter to have all caches with (e.g.) >10 FPs and map these, but there is no "weighting" so 10 caches with 10FPs each will result in a much higher "density" than 2 caches with 50FPs each, although both have a sum of 100FPs. |
My aim is to display real FP density, rather than the density of caches with a fixed threshold number of FPs. For example, 3 close caches with 150 FPs together would show the number 150 on the cluster, while 10 close caches with "only" 80 FPs altogether would show 80 on the map (assuming there are no other caches with FPs nearby).
The trick to achieve this could be to ask Google Maps to display the each cache multiple times, to match the FPs each cache has. If the number of items to display would be prohibitive to performance or break something then divide the FPs being requested by a fixed number => Caches with lots of FPs still have a bigger impact on the chart and you still end up with a FP density chart ... just with smaller numbers.
Image may be NSFW.
Clik here to view.
The picture is of course a cache density map but please try to imagine these numbers as being the sum of the FPs of the underlying caches. The 'single' cache in the middle of the picture would represent an *unknown* number of caches, one of which has 1 FP. The '6' next to it represents an *unknown* number of caches with a sum of 6 FPs, and so on. I say 'unknown' as the number of physical caches involved is not important at this time, just the sum of the FPs. The numbers would result from duplicating each cache FP times (and not showing caches at all for 0 FPs).
Now you can really see where FPs are concentrated.
I hope I have been able to make my idea a bit clearer.
Thanks again.
P.S. One last point ... A conceivable argument against this approach is that you can perhaps no longer see the cache names (I guess labels would have to be off for performance reasons). However this is not the aim here. Once you have figured out which area you want to visit, you can then use the normal Google Maps V3 functionality to look at what is physically at this location.