[Users] Tree node disabling with min/max scale

Matt Priour mpriour at kestrelcomputer.com
Fri Oct 22 20:53:54 CEST 2010


Added a patch to ticket #235 [1]
I will add tests later tonight, my manual test on several layer types worked 
as expected. It turns out that the layer's 'visibilitychanged' event never 
fires when the layer goes out of range. This actually makes sense when you 
consider that if OL did actually turn off the layer when it went out of 
range, then it would have to know to turn it back on when it came back in 
range. Rather, OL just stops drawing the out of range layers if 
calculateInRange() returns false.

It appears that OL updates the inRange property for all layers (visible or 
not) after the map's moveend event but before it actually does any 
redrawing. I attach a map moveend listener for each LayerNode that could 
reasonably be auto-disabled. I also evaluate the inRange property or result 
of the calculateInRange function before the layer node is rendered.

[1] http://trac.geoext.org/attachment/ticket/235/autoDisableLayerNode.patch

Matt Priour
Kestrel Computer Consulting

--------------------------------------------------
From: "Alexandre Dube" <adube at mapgears.com>
Sent: Friday, October 22, 2010 11:49 AM
To: <users at geoext.org>
Subject: Re: [Users] Tree node disabling with min/max scale

> Hi Pierre,
>
>   In a way, the needs are the same.  We all want to have nodes
> reflecting to layers or paramlayers to disable when out of specific 
> scales.
>
>   When dealing with LayerNodes, it's okay ( and I'd say recommended )
> to use the OpenLayers.Layer 'inRange' property that is already
> calculated from many properties such as minScale, maxScale,
> minResolution, maxResolutions, resolutions, etc.  It would be kinda
> 'duplicate' to define that information in the layertree nodes as well.
>
>   For the paramnodes, that's an other story.  "param layers" are
> specific to the OpenLayers.Layer.WMS layer object and there is no
> "min/max scale/resolution" information per param layer in it.  Unless
> there a plans to integrate that kind of information in OpenLayers, I
> think the best approach would be to use a plugin.
>
>   So in brief, for LayerNodes it could be dealt by default by the
> "visibilitychanged" event and "inRange" layer property inside the class
> itself and for ParamNodes we could use a plugin.  How about it ?
>
> Alexandre
>
>
>
> On 10-10-22 03:43 AM, Pierre Giraud wrote:
>> Hi all,
>>
>> Sorry about that but I forgot to mention that there's something
>> special with the code I proposed.
>>
>> In my case, I had to deal with LayerParamNodes which are not tightly
>> bound to a layer but to a WMS sub-layer. I couldn't listen to
>> "visibilitychanged" because the OL Layer visibibility doesn't change
>> actually.
>> Code is better than talks so imagine the following tree (manual) 
>> configuration:
>>
>> {
>>      text: "Tourisme et vie local",
>>      children: [{
>>          text: "Tourisme",
>>          children: [{
>>              nodeType: "gx_layerparam",
>>              text: "Piste de ski",
>>              item: "pistes_ski",
>>              maxScale: 50000
>>          }, {
>>              nodeType: "gx_layerparam",
>>              text: "Piste de ski de fond",
>>              item: "pistes_fond"
>>          }]
>>      }]
>> }
>>
>> In this example, the maxScale value is set adequately to the
>> configuration in the mapfile. This is a bit specific because it is
>> configured manually, but we could imagine a way to get this
>> information by reading Capabilities.
>>
>> So, the goal is probably not the same as the one Alexandre or Matt are
>> trying to reach.
>>
>> Regards,
>> Pierre
>>
>>
>> On Thu, Oct 21, 2010 at 9:54 PM, Andreas Hocevar<ahocevar at opengeo.org> 
>> wrote:
>>
>>> Hi,
>>>
>>> I think the approach with the visibilitychanged event has less overhead. 
>>> And if people prefer a plugin, it could also be combined with a plugin 
>>> approach: whenever a layer node is added to the tree, the plugin could 
>>> register the event.
>>>
>>> But even if it's going to be default behavior, it can easily be disabled 
>>> by making the css class for the disabled layer configurable.
>>>
>>> Having said that, I don't have a strong opinion on plugin or not, but I 
>>> do like the visibilitychanged approach better.
>>>
>>> Regards,
>>> Andreas.
>>>
>>> On Oct 21, 2010, at 21:14 , Eric Lemoine wrote:
>>>
>>>
>>>> On Thu, Oct 21, 2010 at 8:14 PM, Alexandre Dube<adube at mapgears.com> 
>>>> wrote:
>>>>
>>>>> Matt,
>>>>>
>>>>>    Like I mentioned, I would need this feature rather quickly.  Do you
>>>>> wish to do the fix ?  If not, I'm willing to make the changes (with 
>>>>> the
>>>>> appropriate ticket + patch).
>>>>>
>>>>>    Andreas, do you agree with the change or would you rather see it as 
>>>>> a
>>>>> plugin as Pierre and Matt proposed ?
>>>>>
>>>> A plugin would be great.
>>>>
>>>>
>>>> --
>>>> Eric Lemoine
>>>>
>>>> Camptocamp France SAS
>>>> Savoie Technolac, BP 352
>>>> 73377 Le Bourget du Lac, Cedex
>>>>
>>>> Tel : 00 33 4 79 44 44 96
>>>> Mail : eric.lemoine at camptocamp.com
>>>> http://www.camptocamp.com
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at geoext.org
>>>> http://www.geoext.org/cgi-bin/mailman/listinfo/users
>>>>
>>> --
>>> Andreas Hocevar
>>> OpenGeo - http://opengeo.org/
>>> Expert service straight from the developers.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at geoext.org
>>> http://www.geoext.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>>
>
>
> -- 
> Alexandre Dubé
> Mapgears
> www.mapgears.com
>
> _______________________________________________
> Users mailing list
> Users at geoext.org
> http://www.geoext.org/cgi-bin/mailman/listinfo/users
> 


More information about the Users mailing list