My application uses CustomDataSource to load entity data, and I have things working more or less the way I want them to. The data I'm showing is getting kind of busy, though, so I'm starting to look at clustering. The problem is, the individual DataSources that I use for my top-level entity types have natural subdivisions that would make whole-DataSource clusters combine items in a confusing way: think about a server-side data category of Fruit loaded into a single CustomDataSource, but I don't want to cluster Apples with Oranges.
Is there a simple way to do this within the framework, without adding an abstraction layer of my own on top? I notice that EntityCluster emits an event after deciding what to group together, but provides no way to decide which entities within a DataSource should go into each cluster.
I was thinking of making a DataSource type that is comprised of other DataSources (such that each child could have its own EntityCluster property), or maybe subclassing EntityCluster so that its grouping logic only puts Entities with a `parent` property in clusters with other Entities that share the same `parent`. Has anybody done something similar already? Is there another ready-to-go solution that I'm not seeing?
The Starburst Demo we have on sandcastle shows a more manual grouping of entities, if that helps. Entity Clusters currently do not provide a way of knowing which entities are being clustered/declustered, but it has been requested. We have an issue open here, and I’ve gone ahead an bumped it.
I'm not sure that the demo or linked issue are exactly what I'm talking about.
I specifically want a small change to the current default clustering behavior (hiding groups of entities that are too close at the current zoom level, and replacing them with a group placeholder) but I'd like to avoid re-writing the clustering logic myself, using a more manual approach like the Starburst demo.
If I read the linked issue correctly, it's about exposing the entities that just stopped being clustered when you zoom in -- that is, instead of getting the cluster/group entity, plus all the entities that are being hidden, you'd also get the entities that were hidden at the previous zoom level but aren't anymore. This doesn't address the "apples vs oranges" concern.
I think what I'm looking for is one of two things:
1. If a DataSource could "own" another instance of a DataSource (think `mySource.addChild(anotherSource)`), then each child could be configured with its own EntityCluster options while retaining the ability to manipulate this "source-of-sources" as a single unit (add/remove, show/hide, hook change events, etc).
2. If EntityCluster could provide a hook when it's *about* to decide what gets clustered, in addition to the current event that fires *after* clustering is decided, then I could create dynamic clusters. Something like `mySource.clustering.binFunction = ent => ent.fruitType;`. Then in `EntityCluster.createDeclutterCallback` all the entities would be broken out by fruitType and the clustering algorithm would iterate over each bin and cluster only those Apples that are close enough (and repeat for Oranges, Bananas, etc).
Does that makes sense? I'm pretty sure neither of these solutions exists in the API today but I was hoping maybe something similar might, or at least one of them might have been implemented by somebody else already.