Hey- Ivan Grcic wrote: > There you go: a ticket and an example > http://trac.openlayers.org/ticket/1835 > http://dev.openlayers.org/sandbox/igrcic/openlayers/examples/strategy-bbox.html
Thanks for the detail. The strategy was not registering for layer visibilitychanged. The patch for 1835 corrects this. Tim > > Cheers, Ivan > On Fri, Nov 14, 2008 at 5:40 PM, Tim Schaub <[EMAIL PROTECTED]> wrote: >> Hey- >> >> Ivan Grcic wrote: >>> Hi, ive tried Tims patch and i must say im pretty happy with it. Tnx Tim! >>> >>> I dont need to filter data depending on number of features >>> (maxfeatures), but to show all the currently available data for area, >>> then the cluster strategy jumps in and takes care that there are not >>> too many features rendered. Perfect. >>> >>> Now the only problem is that one when upon activateing layer, it has >>> to be nudged a bit for features to load (moveend effect) >>> >> Ivan, can you open a ticket and post an example that reproduces this >> specific problem? It would be great to have a record of it. Also, if >> you write back here with the ticket number, it would be good to have as >> part of this thread. >> >> Thanks, >> Tim >> >>> >>> On Thu, Nov 13, 2008 at 9:08 PM, Eric Lemoine <[EMAIL PROTECTED]> 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. >>>> >>>> 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 <[EMAIL PROTECTED]>: >>>>> 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@openlayers.org >>>>> http://openlayers.org/mailman/listinfo/dev >>>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@openlayers.org >>>> http://openlayers.org/mailman/listinfo/dev >>>> >>> >>> >> >> -- >> Tim Schaub >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> > > > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
