[OpenLayers-Dev] bbox strategy and zooming
tschaub at opengeo.org
Wed Nov 12 16:29:43 EST 2008
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.
> 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
> 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.)
> 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.)
>> Christopher Schmidt
>> Dev mailing list
>> Dev at openlayers.org
> Dev mailing list
> Dev at openlayers.org
OpenGeo - http://opengeo.org
Expert service straight from the developers.
More information about the Dev