[OpenLayers-Dev] bbox strategy and zooming

[Tim Schaub]

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