[OpenLayers-Dev] bbox strategy and zooming

[Christopher Schmidt]

On Wed, Nov 12, 2008 at 01:56:11PM -0700, Tim Schaub wrote:
> Hey-
> 
> Christopher Schmidt wrote:
> > On Wed, Nov 12, 2008 at 09:25:20AM -0700, Tim Schaub wrote:
> >> 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.
> > 
> > I don't understand this. It seems to me that even with the 'smarter
> > merge' you describe below, you'd still want a way to limit the amunt of
> > data returned from the server at once -- if nthing else, then to limit
> > server processing at some point.
> 
> Right.  Communicating this limit is protocol specific.  Correct?

I think it is protocol specific in the same way that  the way filters
are communicated is protocol specific, yes.   

> >> 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.
> > 
> > 
> > I don't see how either of these two methods mentioned above helps in the
> > use case I mentioned -- specifically, that I only want to request from
> > the server a limited number of features which match my query parameters,
> > and if the total is more than that, I want to ask again when the filter
> > changes in a way that will affect the question. 
> > 
> 
> I was talking about how the bbox strategy could be made smarter.  It 
> doesn't seem to me like limiting the number of features returned has 
> anything to do with the bbox strategy.
> 
> In general, I *think* you are talking about making the strategy more 
> aggressive with regard to determining when the current feature set is 
> invalid.  In your specific case, this has to do with some limit that you 
> specified in a previous request.  How this limit is communicated only 
> the protocol knows.  

Well, I'd say that this could be defined as part of knowledge that both
the Strategy and Protocol know (in the same way that filters are), but
this is still the job of the protocol to serialize/cmmunicate, yes. 

> Perhaps the limit wasn't even communicated by the 
> protocol, but was instead configured on the server.

Possibly.

> Someone else might have a specific need to make the strategy more 
> aggressive because the server returns more detailed data based on the 
> extent of the request (I don't know, just making things up here).

Sure.

> Anyway, both of these specific needs could be satisfied by providing an 
> option to make the strategy more aggressive.  I'm only suggesting that 
> that option is not *just* about maxFeatures (or limit, or whatever your 
> protocol may use to communicate that only a subset of the total features 
> that meet some criteria are returned).

Okay.

> And, limit (and sort) should be treated separately from filters (in the 
> general sense).  I can filter a set and ask for the first 10.  Or maybe 
> 10-20.  Or I can filter a set then sort the results and then ask for 10 
> (whatever, just mentioning that they are separate operations).

Sure.

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?   

Regards,
-- 
Christopher Schmidt
MetaCarta