[OpenLayers-Dev] bbox strategy and zooming

Ivan Grcic ivan.grcic at geofoto.hr
Wed Nov 12 11:16:01 EST 2008


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 <ivan.grcic at geofoto.hr> 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
> <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
>>
>



-- 
Ivan Grcic



More information about the Dev mailing list