Viewport and Pincount

[lmorroni]

My goal is to be able to get a list of all the markers in the current viewport. My starting point for this has been pincount. My theory is that pincount needs to be accurate first before I can expect to receive a valid list of markers. What I am finding is that the pincount does not behave as I would expect. If I load my site, I get n number of pins. If I pan around the map, I continue to get n or a little more than n. I would expect the pincount to decrease as I go from the full view of everything down to a smaller sampling. I have also experienced instances where the pincount will double and continue to double as I move around the map. I am leveraging loadStart and loadEnd to see what the value of pincount is.

            window.onload = function () {
                var googlemap = new Anycluster("gmap", anyclusterSettings);

                googlemap.loadStart = function () {
                    console.log("Loading started->" + googlemap.pincount);
                };

                googlemap.loadEnd = function () {
                    console.log("Loading ended->" + googlemap.pincount);

                };
            }

Is this a bug or me?
Thanks!
Larry

[biodiv]

This is a bug. Pincount only works for the first time you load a map (maybe a zoomlevel).
For getting a list of markers on the viewport (or any other area) we could use

anyclusterInstance.getAreaContent(area,function(markerList){
    doSomeThingWithMarkers
});

with area being something like

{'left':float, 'top':float, 'right':float, 'bottom':float}

which is already implemented. This function currently is used by the grid cluster - it queries the content of a grid cell in this case.
For the ease of use I will implement a function like getViewportContent that passes the viewport as the area to this function.

[lmorroni]

That sounds good. I am wondering what your thoughts are on the ability
to draw a polygon to define the bounds? I am certain that I will need
that functionality at some point. It seems like anycluster relies
heavily on the viewport's rectangular dimensions.
Larry

biodiv mailto:notifications@github.com
May 7, 2014 at 5:30 PM

This is a bug. Pincount only works for the first time you load a map
(maybe a zoomlevel).
For getting a list of markers on the viewport (or any other area) we
could use

|anyclusterInstance.getAreaContent(area,function(markerList){
doSomeThingWithMarkers
});
|

with area being something like

|{'left':float, 'top':float, 'right':float, 'bottom':float}
|

which is already implemented. This function currently is used for the
grid cluster - it queries the content of a grid cell in this case.
For the ease of use I will implement a function like
|getViewportContent| that passes the viewport as the area to this
function.

—
Reply to this email directly or view it on GitHub
#15 (comment).

http://www.getpostbox.com

[biodiv]

That is a good point. Getting all markers within a geometry (polygon/s or rectangle/s or circle/s) is easy, we should implement the area in the geojson format right away when sending to the server - instead of using top,left etc. You will then simply have to pass a geojson object of any kind to getAreaContent. The google maps api supports geojson, so getting the object directly from the api after drawing on the map should be possible.

[lmorroni]

Working through this a little more, I want to run another idea by you. Your current getClusters function call takes a viewport as input. I am wondering why we wouldn't want to be able to simply pass a geojson to this instead of a viewport. You already convert the viewport to geojson inside the function. This would give us the added benefit of being able to draw a polygon on the map and having a geojson representation of the polygon passed to getClusters. A use case for this might be a stretch of river that the user wants to view results for. They would draw a bounding polygon around the river. When the polygon is closed, an event would be fired and getClusters would returns markers just for that bounded area.

[biodiv]

fixed with the latest commit