[OpenLayers-Dev] Cluster strategy getResolution bug ?

Ivan Grcic ivan.grcic at geofoto.hr
Mon Nov 10 14:31:22 EST 2008


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

Ivan

On Mon, Nov 10, 2008 at 6:49 PM, Tim Schaub <tschaub at opengeo.org> 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 <adube at mapgears.com>:
>>>
>>>> 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 at openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>>
>>>>
>>
>>
>
>
> --
> Tim Schaub
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Ivan Grcic



More information about the Dev mailing list