[OpenLayers-Dev] bbox strategy and zooming

[Tim Schaub]

Hey-

Ivan Grcic 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? )
> 

Well, not necessarily.  I could create a bunch of features 
programmatically and add them to a layer.  Given a cluster strategy, the 
layer would end up getting clusters to render instead of my original 
features.  Who knows, someone might also have their own custom strategy 
that is responsible for requesting features.  Or there could be a paging 
strategy stuck in there - so features are first paged and then clustered.

I think it is important to keep these behaviors separate when talking 
about potential enhancements.

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

Ok, ready.

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

Yup.  Agreed (with the first sentence).  This is about making the bbox 
strategy more aggressive with regard to determining when the previous 
set of features is invalid.  And, it should be an *option* to configure 
the strategy to be more aggressive.

One simple solution would involve keeping track of previous resolution 
in addition to previous extent requested.  The invalidBounds method 
could optionally compare the new resolution to the old one.  You might 
want to say if old != new, then invalid.  Someone else might want to say 
if 1/2 < (old/new) < 2 then invalid.  Would be nice to do a bit of 
thinking about how to characterize this option.

I think the next part of the paragraph is about making the cluster 
strategy smarter - so that it doesn't waste time calculating clusters 
for features that are outside of the map viewport maybe?  Not sure. 
Anyway, we have to also consider that the cluster strategy doesn't know 
anything about when new features are going to be requested.  It could be 
that the user has a fixed strategy, or a bbox strategy with some custom 
ratio.  In any case, the user might pan over to some area where clusters 
have not yet been calculated.  Don't think I'm really following here, so 
I'll stop.

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

Ok, now this is about the cluster strategy.  Most of it at least.  Only 
the cluster strategy knows about clusters.

So, it sounds like you want to stop calculating clusters at some 
resolution maybe?  Maybe not.  Please clarify if that is wrong.

Also, I've noticed problems using the bbox strategy that I think are 
what you are referring to.  I've assumed it is because the "moveend" 
event is not properly fired - but I have to look into it more closely.

> 
> Thats all from me now,

Thanks.  Please clarify anything that you think has not been understood. 
  (In threads with new subjects if appropriate.)

Tim

> 
> Redargs,
> 
> Ivan
> 
> On Tue, Nov 11, 2008 at 7:48 PM, Christopher Schmidt
> <crschmidt at metacarta.com> 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 at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.