Hey- Ivan Grcic wrote: > Hi, I'll try to make some little example tomorrow, because I think > there is some strange behavior when you supply resolution array to > vector layer with cluster strategy. Then the problem will be little > bit clearer I guess...
It was an oversight to have the cluster strategy call layer.getResolution() instead of layer.map.getResolution(). The patch for http://trac.openlayers.org/ticket/1820 addresses this. Tim > > Ivan > > On Mon, Nov 10, 2008 at 6:49 PM, Tim Schaub <[EMAIL PROTECTED]> wrote: >> Hey- >> >> Alexandre Dube wrote: >>> Hi Eric, >>> >>> Ok, I understand what you mean. But I already set specific scales to >>> the vector layer that are supposed to give the same resolutions I need. >>> I mean : >>> >>> Base layer (map) has scales in its options: [ 100000, 50000, 25000, >>> 10000, 5000, 2500, 1000, 500, 250, 100] >>> Vector layer has scales in its options: [10000, 5000, 2500, 1000, 500, >>> 250, 100] >>> >>> So I expect the vector layer to have the good corresponding >>> resolutions, but it hasn't. Maybe that is the issue. Any thoughts ? >> Only the resolutions in your base layer are respected. Individual >> resolution values on all overlay layers are ignored. When your map >> changes resolution, layer.calculateInRange is called for each overlay >> layer. If this returns false, the layer is not displayed. >> >> The layer.calculateInRange method checks layer.minResolution and >> layer.maxResolution. If map.getResolution returns a value that is >> between the min/max for the layer (inclusive), calculateInRange returns >> true. (The exception to this is when layer.alwaysInRange is true.) >> >> If you are encountering a situation where calculateInRange does not >> return the appropriate value, or if you think the precision in the scale >> to resolution conversion is not consistent, please start a new thread >> (this has nothing to do with vector layers or the cluster strategy). >> >> Tim >> >>> Alexandre >>> >>> Eric Lemoine wrote: >>>> Hi Alexandre >>>> >>>> If you want your vector layer to be visible only for a subset of the >>>> base layer's resolutions you should set maxResolution and/or >>>> minResolution in your vector layer options. >>>> >>>> If you pass an array of resolutions to the vector layer, you can end >>>> up with vectorlayer.resolutions[i] != baselayer.resolutions[i], where >>>> i is any index of the vector layer's resolutions array. >>>> >>>> And I think you are hitting the above case, which is making the >>>> cluster strategy doesn't behave as you expect it to. >>>> >>>> So I don't see anything wrong with the cluster strategy relying on >>>> this.layer.getResolution. >>>> >>>> I'd really like to hear what others think about that. >>>> >>>> Cheers, >>>> >>>> Eric >>>> >>>> 2008/11/7, Alexandre Dube <[EMAIL PROTECTED]>: >>>> >>>>> Hi devs, >>>>> >>>>> I got a problem using the cluster strategy. At first, it didn't >>>>> seemed to work at all. I always got the same number of feature with or >>>>> without the cluster strategy applied. After a few search, I found out >>>>> the problem was at line 143 : *var* resolution = >>>>> *this*.layer.getResolution(); >>>>> >>>>> I just replaced the line for : *var* resolution = >>>>> *this*.layer.map.getResolution(); and it worked. >>>>> >>>>> The reason is : >>>>> >>>>> My base layer has 10 fixed scales ( which gives 10 resolutions), from >>>>> 0 to 9. My vector layer has only 7, which represents resolutions 3 to 9 >>>>> of the base layer's scales, but the vector layer itself has his own >>>>> scales array from 0 to 6. So, the line 143 which called resolution 3 >>>>> from the base layer calls resolution 3 from the vector layer, which is >>>>> wrong ! >>>>> >>>>> Anyone else noticed this ? >>>>> >>>>> -- >>>>> Alexandre Dubé >>>>> Mapgears >>>>> www.mapgears.com >>>>> >>>>> _______________________________________________ >>>>> 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
