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

Reply via email to