Currently, the only metric we have for each cluster is the number of points in each cluster.

I ran into this "limitation" when wanting to display a number on each cluster which was an aggregation of a custom property on each of my points. For example, each point may have a population property, and I want each cluster to show the total population.

This PR allows points passed in to have an additional property specified by metricKey and a custom reducer function specified by metricReducer.

Now, one can compute metrics on clusters that are based on other dimensions (like population) and compute things like averages, min, max, etc.

I am creating server side clustering for my map. When I use PHP and Mysql for create the clustering it is taking more time. So I am planning to use this project I have few doubts

How to run this project as server? If I pass My lat and lang points into this project this will convert everything to cluster? How to expose API for markers to cluster?

Please help me. I am waiting for your response

I thought a lot about API design for cluster property aggregations because once we commit to a particular API, it will be difficult to change, and doing support/maintenance for such a complex feature may be a big burden.

In this PR, I'm proposing an alternative implementation to #12 and @redbmk's fork, inspired by the map-reduce concept. It should hopefully eliminate all the API ambiguity and make writing custom aggregations easier.

• the initial function returns the initial properties of a cluster (before accumulation)
• the map function specifies how to interpret individual points (as opposed to clusters) when accumulating properties
• the reduce function does the accumulation and is similar to Array reduce.

Here's an example of aggregating point counts per category, an equivalent to this big 50-line example by @lamuertepeluda:

initial: function () {
    return {categories: {}};
},
map: function (properties) {
    var categories = {};
    categories[properties.featureclass || 'uncategorized'] = 1;
    return {categories: categories};
},
reduce: function (accumulated, properties) {
    for (var id in properties.categories) {
        accumulated.categories[id] = (accumulated.categories[id] || 0) + properties.categories[id];
    }
}

And here's a slightly bigger example for the sum, min, max, avg (equivalent to this example by @redbmk in the cluster-agg-hash-array branch)):

initial: function () {
    return {
        count: 0,
        sum: 0,
        min: Infinity,
        max: -Infinity
    };
},
map: function (properties) {
    return {
        count: 1,
        sum: properties.myValue,
        min: properties.myValue,
        max: properties.myValue
    };
},
reduce: function (accumulated, properties) {
    accumulated.sum += properties.sum;
    accumulated.count += properties.count;
    accumulated.min = Math.min(accumulated.min, properties.min);
    accumulated.max = Math.max(accumulated.max, properties.max);
    accumulated.avg = Math.round(100 * accumulated.sum / accumulated.count) / 100;
}

Note that the example above does not rely on internal properties like numPoints and if you need a count for the average calculation, you just calculate it manually.

If we add fallbacks for the map option (return point properties directly) and the initial option (return {}), we can also support code similar to @redbmk's examples (with just the reduce function), although clear separation of the three concepts makes it much easier to follow what's going on in my opinion.

The performance overhead is acceptable — ~18% both time and memory overhead (compared to current master) when providing a reducer, and otherwise zero time overhead and ~10% memory overhead. We might be able to reduce it further too.

I'm keeping the discussion about the Mapbox GL style spec / JS API separate since it shouldn't rely on a specific Supercluster implementation.

@redbmk @lamuertepeluda @johnlaur @cyrilchapon @aparshin @ben657 @georgeke @vibze @ryanbaumann @davecranwell @lucaswoj what do you think?

Hi, this is more a question that a bug report. I've noticed that in my application supercluster calls the reduce function is not called for each of the points in the final cluster, but at least one point is skipped. Am I missing something or it shouldn't behave like that?

Hi, we are using the supercluster library and in IE it is throwing the error supercluster not defined. In chrome it is working fine.

we are using the example from here. It is in ES 6 but we did convert to ES 5

https://bl.ocks.org/ryanbaumann/01b2c7fc0ddb7b27f6a72217bd1461ad

this is the code we are using. (even without array.from, it is giving the error)

function performSuperClustering(propertyToAggregate, clusterRadius, clusterMaxZoom, secondaryPropertyToAggregate, mapName) {
            return supercluster({
                radius: clusterRadius,
                maxZoom: clusterMaxZoom,
                initial: function initial() {
                    return {
                        count: 0,
                        sum: 0,
                        min: Infinity,
                        max: -Infinity,
                        unique: 0,
                        uniqueSecondary: 0,
                        consolidatedArray: [],
                        distinctArraySecondary: []
                    };
                },
                map: function map(properties) {
                    return {
                        count: 1,
                        sum: Number(properties[propertyToAggregate]),
                        min: Number(properties[propertyToAggregate]),
                        max: Number(properties[propertyToAggregate]),
                        unique: 1,
                        uniqueSecondary: 1,
                        consolidatedArray: Number(properties[propertyToAggregate]),
                        distinctArraySecondary: app.getContentForDistinctSecondary(mapName, secondaryPropertyToAggregate, properties),//properties[secondaryPropertyToAggregate] + "}{" + properties["alertLocation"] + "}{" + properties["alertTitle"], //SUJAN
                        placeholder: Number(properties[propertyToAggregate])
                    };
                },
                reduce: function reduce(accumulated, properties) {
                    accumulated.sum += Math.round(properties.sum * 100) / 100;
                    accumulated.count += properties.count;
                    accumulated.min = Math.round(Math.min(accumulated.min, properties.min) * 100) / 100;
                    accumulated.max = Math.round(Math.max(accumulated.max, properties.max) * 100) / 100;
                    accumulated.avg = Math.round(100 * accumulated.sum / accumulated.count) / 100;

                    if (accumulated.consolidatedArray.indexOf(properties.consolidatedArray) == -1 && properties.placeholder != null) {
                        accumulated.unique += properties.unique;
                        //alert(acculumated.unique + " AND standalone unique: " + properties.unique);
                        accumulated.consolidatedArray.push(properties.consolidatedArray);
                        accumulated.distinctArraySecondary.push(properties.distinctArraySecondary);
                    } else {
                        accumulated.unique += properties.unique;
                        if (Array.isArray(properties.consolidatedArray)) {
                            accumulated.consolidatedArray = [].concat(_toConsumableArray(accumulated.consolidatedArray), _toConsumableArray(properties.consolidatedArray)); // PROBLEM
                            accumulated.distinctArraySecondary = [].concat(_toConsumableArray(accumulated.distinctArraySecondary), _toConsumableArray(properties.distinctArraySecondary));
                        }
                        var temp = new Set(accumulated.consolidatedArray);
                        var tempSecondary = new Set(accumulated.distinctArraySecondary);
                        accumulated.unique = temp.size;
                        accumulated.distinctArraySecondary = Array.from(tempSecondary);
                        accumulated.uniqueSecondary = tempSecondary.size;
                    }
                }
            });
        }

Help is much appreciated. thank you.

I need to identify cluster markers for adding or removing from map. When zoom changes Supercluster generates new cluster marker even if there are no changes for that marker. cluster_id is not reliable, so is there any way to generate hash from leafs or something else that is performant because marker cluster can have 2 children or 2 million. Thanks.

supercluster.min.js:1 Uncaught TypeError: Cannot read property 'range' of undefined at e.getClusters (supercluster.min.js:1)

Someone knows how to solve it? thanks

Before anything, I'd like to thank you very much for this package!

I don't have an idea why this is happening, but sometimes (apparently randomly) this error occur when calling .getClusterExpansionZoom() method.

Cannot read property 'x' of undefined

Object.getChildren
index.js:84

The getChildren() method tries to read from origin.x, but origin variable is undefined. The origin var, as we can see, is created in the following line:

var origin = this.trees[clusterZoom + 1].points[clusterId];

It is undefined because (as in one of my debuggings) clusterZoom = 12 and clusterId = 21, and this.trees[13].points only have 19 entries (0 to 18), thus, this.tree[13].points[21] returns undefined.

Any ideas why is that error occurring? Thanks! =)

This makes map/reduce more convenient to use by making it possible to omit the initial function in most cases.

When initial is omitted, the reducer will use the mapped values of the first reduced item as the initial value. So trivial cases like +, min and max will work seamlessly without the need for initial.

It's kind of breaking, but I doubt many people depended on initial returning {} by default, so maybe it's OK to release this as a minor semver update.

cc @redbmk

#94 implements index-based ids for the returned cluster nodes. Some GeoJSON input may not have feature ids, or may use string feature ids which do not work with geojson-vt.

Proposal

generateLeafIds: enables generation of ids on the leaf nodes, ensuring uniqueness across leaf nodes and cluster nodes. Overwrites any existing id values.

Pros: Simple and efficient solution to create GeoJSON and VT spec compliant id attributes for all nodes. Cons: id value for a feature can change between different invocations of the API, and depends on the input GeoJSON features.

When the bounding box covers bother sides of 0 (Quandrant 4 and 1 of a circle). for example index.getClusters([2, -10, -178, 10], 1) I expect it to return the points from 0 to 2 and -178 to -180.

I've wrote a test:

describe('group', () => {
  const createSpot = (horizonral, vertical) => {
    return {
      type: "Feature",
      geometry: {
        type: "Point",
        coordinates: [horizontal, vertical]
      }
    }
  }

  var index = supercluster({
    radius: 0.01,
    maxZoom: 1,
    extent: 512
  })

  it('should group spots near the edge', () => {
    index.load([
      createSpot(-179.989, 0),
      createSpot(-179.990, 0),
      createSpot(-179.991, 0),
      createSpot(-179.992, 0),
    ])

    const spots = index.getClusters([2, -10, -178, 10], 1)

    return expect(spots.length).toEqual(4)
  })
})

But it fails. Am I missing something? Isn't the horizontal range -180 to 180 (vertical 90 to -90)? http://wiki.openstreetmap.org/wiki/Bounding_Box

Hey team 👋

Thanks a lot for the work put on this project that I really enjoy. I would enjoy it even more if there was official TypeScript type definition available. Since rollup is already used, it will be straightforward to add the types directly to the repo https://github.com/rollup/plugins/tree/master/packages/typescript. Another approach would be to add a .d.ts file to DefinitelyTyped.

I can take care of it if you want 👍

What do you think of this idea?

Hi,

I've been tinkering around with supercluster and deck.gl to visualize large datasets. I'm using synthetic dataset of a 600 by 600 grid to test performance and wanted to better visualize/understand the individual clusters. I was hoping to get fairly disjoint clusters at any radius I selected, but for the most part( other than a radius of 70), the clusters frequently overlap and exhibit interesting fractal patterns.

The images I'm displaying below show children points and polygon overlay of each cluster generated by supercluster(at the specified zoom level). Each picture has a different radius value ranging 20, 40, 70, 80, and 100 units. (The children are fetched via getLeaves(id, Inifinity) per cluster;

I'm interested in knowing if the fractal patterns clusters exhibit is expected/usual using supercluster(or perhaps my synthetic data is causing issues with the underlying algorithm). And also if is any parameter tuning that can be done to mitigate the effect.

If a codesandbox is desired I can try to get it set up, the only issue being the data usually causes the website to be unresponsive so I can try to generate a smaller set that exhibits the same behavior.

Thanks

Hi!

I recently started to get familiar with the package. Thanks for the awesome work so far!

I've noticed one unexpected behavior so far which is having the point_count_abbreviated property with two different types, number and string. It was unexpected because we already have point_count property which is always number and well the format of long number's point_count_abbreviated property should always be string anyhow. So I would suggest to have this point_count_abbreviated field as string by default.

What would be thoughts on this?

This is not necessarily an issue with supercluster (assuming it expects all longitudes to be within the [-180, 180] range), but it causes issues with maplibre-gl and mapbox-gl.

For example, a point with coordinates [-181, 0] renders fine in a non-cluster mode in the two mentioned libraries, but it doesn't render in a clustered geojson source. Here's an example showing this issue: https://codepen.io/kaveh/pen/mdBqrYq. The red layer is for non-clustered points (shows 2 rendered points) and green is for clustered (shows only 1).

I could fix my coordinates before adding them to source in those libraries, but I thought if the same data works in non-clustered mode, it should work with clustered mode too and that's why I submitted the fix here.

There's the getClusterExpansionZoom which gives the zoom level at which the existing cluster is breaking into more clusters/markers.

It would be handy to be able to zoom into a marker so it appears unclustered. The use case for this is when I select an entity related to the marker outside of the map and I need to focus on the marker in case it's out of bounds or clustered.

Or is there a way to do this with the existing methods?