[OpenLayers-Dev] bbox strategy and zooming

Tim Schaub tschaub at opengeo.org
Wed Nov 12 16:12:28 EST 2008


Hey-

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

Ok, I'm not sure I see what you mean here.  Keep in mind that the 
cluster strategy doesn't know anything about bbox, and vice-versa.

Can you separate out your ideas into things that have to do with 1) 
requesting new features based on changing map extent, and 2) creating 
new features that represent clusters of proximate features?

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


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



More information about the Dev mailing list