Hey- This has gotten too scattered for me to follow, but I'll put in a few thoughts.
The BBOX strategy is intentionally lazy. And I agree that we can add properties to make it more aggressive (optionally). I think it is short-sighted to tie this property to a maxfeatures or limit parameter in a request. Part of the intention with strategies was to improve the behavior of vector layers with regard to merging newly requested features with existing ones. I think Ivan is wandering into this territory below. The merge methods implemented so far are simplistic. A smarter merge would consider the fids of existing features before ditching all & adding new. In addition, the bbox strategy could be enhanced to only remove features that were outside the new bbox before requesting a new batch. All these were improvements that motivated the strategy code in the first place. And it makes sense to implement them correctly. Tim Ivan Grcic wrote: > Maybe even better, instead of completely removing features from > cluster, when bounds are invalidated, we can maybe store them in some > secondary cache variable. That way they wont be evolved in cluster > calculation when we zoom in some area, so after we can retreive them > easier, without making new getFeature requests back to server every > time bbox is changed. What do you think? > > > On Wed, Nov 12, 2008 at 4:11 PM, Ivan Grcic <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I also began using cluster strategy a lot recently, and im seeing lots >> of places where it can be improved. Here im talking only about using >> it with BBOX strategy, because Fixed strategy is of no use when we're >> talking about large number of features (1000+) (just to be sure, >> there is no other way to use cluster strategy except with Fixed or >> BBOX strategy right? ) >> >> Im activating my WFS layer only when you zoom in few levels, that way >> I kind of filter out my features a little bit. Also, I dont use >> maxFeatures because I need all my features to showup inside BBOX. >> (anyways maxFeatures for cluster doesnt have too much sense, but more >> for Paging strategy, right?) >> >> Ok...so here are my few tips where Cluster&BBOX strategy could and >> should be improved. >> >> 1) invalidate the previous dataset option when bbox changes is a MUST! >> Just take a look at this everyday example. When user opens out map, it >> first opens the view where you show the whole area (world, country, >> region...) At that time you load ALL the features inside vector layer >> (or the maxFeature set) and they stay there PERMANENTLY. As user zooms >> in to much smaller area (city), without invalidating the bounds, all >> the features remain inside layer, and we all know what does that mean >> when were talking about cluster strategy=recalculating all the >> clusters again. But we only need small number of features to be >> shown/calculated at this zoomlevel. So they have to be filtered out >> when we zoom in. >> >> 2) dont recalculate clusters if the layer is disabled >> (setVisibility=false) Here the BBOX does the right thing, if layer is >> disabled it doesnt load new features when we pan the map. Cluster does >> not, it keeps on recalculating features when we zoom in/out. Example: >> if i want to see/activate my cluster layer only after 5th zoom level, >> no calculation should be made when i play on level 0-4, because it >> slows down things pretty much, and the layer is no visible at all. >> Also thers is a bug with bbox strategy here, when you activate ur >> vector layer, the map has to be nudged just a little bit for bbox to >> load the features. Loading must occur on layer activation, as well as >> panning the map. I will fill a ticket on this. >> >> Thats all from me now, >> >> Redargs, >> >> Ivan >> >> On Tue, Nov 11, 2008 at 7:48 PM, Christopher Schmidt >> <[EMAIL PROTECTED]> wrote: >>> On Tue, Nov 11, 2008 at 07:36:22PM +0100, Eric Lemoine wrote: >>>> Yeah, we could add a new option to the bbox strategy. If its value is >>>> null the strategy behaves as currently. If it's non-null, the strategy >>>> fetchs new data on zoom in if the current number of features in the >>>> layer is equal or higher to the option value. Eric >>> I guess the only question then is whether the property should also be >>> used to construct a "Limit" filter that is passed to the protocol, or if >>> it is expected the information is passed directly during the creation of >>> the protocol (and therefore duplicated). >>> >>> (I'm pretty sure there's no "Limit" filter in OGC-land, so this would be >>> an extension of that model.) >>> >>> Regards, >>> -- >>> Christopher Schmidt >>> MetaCarta >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> > > > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
