Skip to content
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

Closed
wants to merge 10 commits into from
Closed

Conversation

Kenny806
Copy link
Contributor

Adresses issue #1573 . Preparation for clustering, with an example that clusters random points and prints the clusters to console. Things to be done:

  1. Tests
  2. Refactoring
  3. Not clustering features outside the given extent
  4. Recalculating clusters on zoom/extent change
  5. Clicking on cluster should zoom to the extent of the clustered features
  6. (maybe add support for more clustering algorithms?)

Any other suggestions are welcome.

@tschaub
Copy link
Member

tschaub commented Mar 26, 2014

Clicking on cluster should zoom to the extent of the clustered features

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.

@ahocevar
Copy link
Member

@Kenny806 Did I misunderstand @jachym, or are you attending the OSGeo code sprint in Vienna? If so, we can take a look at this pull request together tomorrow.

@Kenny806
Copy link
Contributor Author

@ahocevar I was there, but I left yesterday, just a few hours after @jachym

@Kenny806
Copy link
Contributor Author

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?

@tschaub
Copy link
Member

tschaub commented Mar 29, 2014

As suggested by @twpayne, this could be implemented as ol.source.Cluster. This source would take another vector source in its constructor. Requests to loadFeatures(extent, resolution, projection) could trigger cluster calculation based on features in the underlying source. This should likely wait until the work on #1744 is complete.

An alternative would be to work in the idea of a customizable transform before adding loaded features.

@Kenny806
Copy link
Contributor Author

Kenny806 commented Apr 7, 2014

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.

@melechi
Copy link

melechi commented May 9, 2014

Hi @Kenny806, any update on this?

@Kenny806
Copy link
Contributor Author

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.

@melechi
Copy link

melechi commented May 10, 2014

Thanks @Kenny806, I look forward to trying it.

@mvaivre
Copy link

mvaivre commented May 22, 2014

Yes @Kenny806 ! I can't wait to test it ;)

@jachym
Copy link
Contributor

jachym commented May 24, 2014

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?

@mvaivre
Copy link

mvaivre commented Jun 7, 2014

That's strange. Is there anyone to help @Kenny806 and @jachym ? I'm sure the clustering functionality is awaited by a lot of people...

@elemoine elemoine modified the milestones: v3.0.0, v3.0.0-gamma.2 Jun 26, 2014
@elemoine elemoine self-assigned this Jul 3, 2014
@tonio tonio added the feature label Jul 3, 2014
@elemoine elemoine mentioned this pull request Jul 3, 2014


/**
*
Copy link
Member

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.

@pagameba
Copy link
Member

pagameba commented Jul 8, 2014

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.

@Kenny806
Copy link
Contributor Author

Kenny806 commented Jul 9, 2014

Thanks for the help, @pagameba, I will try to fix this soon :-)

@pagameba
Copy link
Member

pagameba commented Jul 9, 2014

no problem, happy to help out and I'd like to see this make it in to 3.0.

@elemoine
Copy link
Member

elemoine commented Jul 9, 2014

I also plan to review this. (But I probably plan too much…)

@elemoine elemoine removed this from the v3.0.0-gamma.2 milestone Jul 11, 2014
* @param {number} resolution
*/
ol.source.Cluster.prototype.loadFeatures = function(extent, resolution) {
if (extent !== this.getExtent() || resolution !== this.getResolution()) {
Copy link
Member

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 to setExtent so the extent is never the same and loadFeatures is called continuously because clear followed by addFeatures 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_)

@pagameba
Copy link
Member

@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.

@Kenny806
Copy link
Contributor Author

@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.

@pagameba
Copy link
Member

You are welcome :)
Please rebase and fix your commit messages up to match the guidelines, in particular you should begin each commit message with a (capitalized) verb (i.e. Fix jsdoc instead of jsdoc fixed).
Also, the commits should be squashed and reorganized - one for each source file adding a new class, one for the example and one for the tests. The history of how it got to this point doesn't need to be preserved for merging.

@ahocevar
Copy link
Member

@marcjansen is going to rebase and merge. Thanks @Kenny806 for the continued work on this.

@marcjansen
Copy link
Member

I'll clean the history and then merge. Thanks everybody so far.

var source = new ol.source.Vector();

var clusterOptions = {
'source': source
Copy link
Member

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

@marcjansen
Copy link
Member

@Kenny806 I think we need a CLA from you before we can merge this.

* @typedef {{features: (Array.<ol.Feature>)
* }}
*/
olx.ClusterFeatureOptions;
Copy link
Member

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

@fredj
Copy link
Member

fredj commented Jul 24, 2014

@marcjansen please see fredj@80ba469

Fixes some issues in externs/olx.js

@marcjansen
Copy link
Member

Thanks, @fredj. Let's see if we can get the cla in time...

@bartvde bartvde modified the milestones: v3.0.0-gamma.4, v3.0.0-gamma.3 Jul 25, 2014
@bartvde
Copy link
Member

bartvde commented Jul 25, 2014

closing this one in favour of #2439

@bartvde bartvde closed this Jul 25, 2014
@marcjansen
Copy link
Member

#2439 is the replacement PR with a clean history and the changes suggested by @fredj,

@Kenny806
Copy link
Contributor Author

I have just sent the CLA. Let me know if there is anything else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet