[OpenLayers-Dev] bbox strategy and zooming

[Christopher Schmidt]

On Thu, Nov 13, 2008 at 01:52:02PM -0700, Tim Schaub wrote:
> Hey-
> 
> 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?

Well, to be honest, I was adding more smarts to it because I thought
that perhaps you would object to something as simple as the resolutino
changing :) But yeah, I was imagining that if you had only 3 pizza
joints, that you already had them all (as you zoomed in) and that it
would not matter beyond that point if you talked to the server more. 

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

Right. Google Maps doesn't do *any* view-based refresh, afaik, so I'm
not sure it's a very useful comparison :)

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

That seems reasonable; I guess I didn't really know if that would work
as you went through other strategies, but it seems sane. 

> I don't see why this has to be strictly coupled with the bbox strategy. 

Agreed.

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

Yeah, I actually thought that this was the 'filter' list/array:
essentially, perhaps strategies should be adding protocol neutral
request-controls into a shared space, then at the end of the strategy
list, pass it off to the protocol.

Regards,
-- 
Christopher Schmidt
MetaCarta