[OpenLayers-Dev] bbox strategy and zooming

Tim Schaub tschaub at opengeo.org
Thu Nov 13 15:52:02 EST 2008


Eric Lemoine wrote:
> Thanks for putting this patch together Tim.
> Initially Chris wanted that the bbox strategy behave aggressively on
> zoom in, but, as an optimization, only if the number of features in
> the layer is not lower than the maxfeatures value set in the protocol.

Ok, I think by "not lower than the maxfeatures" you mean equal to the limit.

So, you (or Chris) wants to request new features when zooming in if 
layer.features == some limit?

I assume you also would like the same behavior when zooming out, right? 
  If you start zoomed in and you see the top 10 pizza joints, when you 
zoom out, you want that top 10 list refreshed (note this behavior is not 
assumed on something like google maps, but I can see why you'd want to 
make it an option).

That sounds like a pretty simple strategy.  Register for zoomend, check 
if layer.features == limit and call layer.refesh({force: true}).

I don't see why this has to be strictly coupled with the bbox strategy. 
    I was originally hoping that we could compose complex behavior with 
many small parts.  I keep seeing this tendency to lump everything 
together so maybe it's no hope.


- A valid point may be raised here that it is weird that some strategies 
would call protocol.read and others would call layer.refresh.  This is 
weird.  We should probably have the layer loop through all strategies 
calling something common.  Strategies would have a chance to modify some 
context object (adding a limit param or a bbox filter or whatever). 
Finally this context would get sent to protocol.read.  Deserves more 
discussion anyway.

> The change you're proposing wouldn't allow this. The change I proposed
> involved adding a new Integer option to the bbox strategy. If that
> option is null the strategy behaves as currently. If it's non-null
> then it behaves aggressively if the number of features in the layer is
> not lower than the option value.
> Chris was concerned with configuration data duplication - maxfeatures
> is kinda set in the protocol as well as in the strategy; which doesn't
> bother me actually.
> You may concerned with the fact that my proposed option targets a
> specific case (maxfeatures-parameterized requests) and doesn't address
> other, maybe more common, cases. I actually don't see other cases when
> a more aggressive mode makes sense, but that's probably just me.
> Cheers,
> Eric
> 2008/11/13, Tim Schaub <tschaub at opengeo.org>:
>> Hey-
>> Christopher Schmidt wrote:
>>> I'm still lost as to how to go about coding what I want :) I want to
>>> have maxfeatures, and more aggressive invalidation because of it. Any
>>> suggestinos as to how I might go about implementing that, or should I
>>> just toss together something and people will look at afterwards?
>> If you haven't already tossed something together, see the patch for
>> http://trac.openlayers.org/ticket/1830.
>> Set resFactor to 1 if you want to request features with every change in
>> resolution.
>> Tim
>>> Regards,
>> --
>> Tim Schaub
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>> _______________________________________________
>> 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