New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
preliminary version of clusters #1903
Conversation
This should be application specific behavior. It would be nice if a cluster carried some information about the features it represents (count, extent, maybe list of ids). But behavior when clicking on a feature should be determined by the application. I look forward to taking a closer look at this later. Just wanted to add a quick comment. |
I am having a bit of trouble with recalculating the clusters on zoom/extent change. I need to listen to a map event (preferably moveend, which seems to be fired less often than postrender, but still is fired avery time when needed). Which means that either ol.Cluster should have a 'map' property, in order to be able to listen to events dispatched by map, or ol.Map must have a property which would store active ol.Cluster instances so that ol.Map can call the reclustering method when needed. I prefer the latter option. Currently, ol.Map has properties like controls_, so I was thinking about adding a strategies_ property to ol.Map (OL2 had a 'strategies' namespace, which included clustering) and renaming ol.Cluster to ol.strategies.Cluster. Any thoughts? |
As suggested by @twpayne, this could be implemented as An alternative would be to work in the idea of a customizable transform before adding loaded features. |
Thanks for the input @tschaub, I have implemented it in today's commit. Could you take a look at the code when you have the time to do it? Right now, I believe that tests and some typdefs are the only things that are missing. |
Hi @Kenny806, any update on this? |
Hi, I haven't touched this in a while. Right now, I only need to write some tests and make the build process pass (on my local machine, everything passes, but the Travis CI build fails), otherwise everything seems to be working. I will try and look into it this week , thanks for the reminder. |
Thanks @Kenny806, I look forward to trying it. |
Yes @Kenny806 ! I can't wait to test it ;) |
Hi there, me and @Kenny806 do have same strange experience: the ./build.py integration-test works at ours desktops, but fails in travis. Any hint here? |
|
||
|
||
/** | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this requires a description to build.
Ok, with these changes, this PR will build when rebased on master. I only looked at the minimum to get travis happy. There probably needs to be more documentation and annotations in the source, and I didn't look at the test or example. |
Thanks for the help, @pagameba, I will try to fix this soon :-) |
no problem, happy to help out and I'd like to see this make it in to 3.0. |
I also plan to review this. (But I probably plan too much…) |
* @param {number} resolution | ||
*/ | ||
ol.source.Cluster.prototype.loadFeatures = function(extent, resolution) { | ||
if (extent !== this.getExtent() || resolution !== this.getResolution()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it turns out this isn't a great test for several reasons:
- the extent returned by
this.getExtent
comes from an internal rbush thing and not from a previous call tosetExtent
so the extent is never the same and loadFeatures is called continuously becauseclear
followed byaddFeatures
triggers a new map render. - you cannot compare extents this way, you need to do something like
!ol.extent.equals(extent, this.getExtent())
For the purpose of caching the currently rendered extent, I think a separate instance var will be needed (perhaps clusteredExtent_
)
@Kenny806 I've updated my copy of your branch with most the of the changes above. Please feel free to use whatever you want from that branch however you want or to ignore it altogether :) In particular, I was messing around with the example so you probably want to change that back. It would be good, though, to at least through more points at it and perhaps try to label the clustered features with the count of features clustered or something. |
@pagameba many thanks for your comments and for implementing them as well! I have applied patches from your commits on this branch. Now I just hope to finish writing tests ASAP. I am also thinking about modifying the example to show how many features is in each cluster (just like you suggested). This should probably be application specific behavior, so it would be nice to have in the example. |
You are welcome :) |
@marcjansen is going to rebase and merge. Thanks @Kenny806 for the continued work on this. |
I'll clean the history and then merge. Thanks everybody so far. |
var source = new ol.source.Vector(); | ||
|
||
var clusterOptions = { | ||
'source': source |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the quotes are not necessary
@Kenny806 I think we need a CLA from you before we can merge this. |
* @typedef {{features: (Array.<ol.Feature>) | ||
* }} | ||
*/ | ||
olx.ClusterFeatureOptions; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
olx.ClusterFeatureOptions.prototype.features
is missing
@marcjansen please see fredj@80ba469 Fixes some issues in |
Thanks, @fredj. Let's see if we can get the cla in time... |
closing this one in favour of #2439 |
I have just sent the CLA. Let me know if there is anything else |
Adresses issue #1573 . Preparation for clustering, with an example that clusters random points and prints the clusters to console. Things to be done:
Any other suggestions are welcome.