visibleLayers and setVisibleLayers

[HeathClark]

So I started playing with a simple custom legend by trying the following code against a DynamicLayer:

  var vL = df_layer_data.visibleLayers;
  var layer_id_index = dojo.indexOf(vL, 2);

                if (layer_id_index != -1)
                    vL.splice(layer_id_index, 0);
                else
                    vL.push(2);

  df_layer_data.setVisibleLayers(vL);

I fully expected to see Layer #2 (a pipeline layer in this case) toggle visibility.  However, it didn't.  After a few minutes of "hacking", I found the problem, the service is a compilation of grouped feature classes and the setVisibleLayers call doesn't like having the ID's for the group layers in the array.

If setVisibleLayers (and maybe other functions) doesn't like and can't handle group layers, why does visibleLayers return them?  There might just be a great answer to that and would really like to hear it so I can learn something new today (or whenever).

[HeathClark]

I agree with hzhu, the actual returned results DO include group (and sub-group) layer ID's as shown in my attached screenshot which is nothing more than

  alert(dynamic_layer_data.visibleLayers);

Screenshot #1 is the alert display, #2 is the rest page details for the service (Layer 0 & 4 are group layers, 20 is a subgroup).

I am running version 2.2 of the jsapi.

I would really like to know the how/why's of getting different information between ESRI and "us"

I can handle the removal of group layers (and sublayers) via code, and actually have plans to use the group layer ID's to control toggle of all children layers, but I would still like some answers/guidance.

(thanks hzhu for using ESRI standard mapservices to document issue, then its not "well it must be your data....")

[HeathClark]

Some more notes to add to the discussion:

A mapservice with sublayers will toggle layer visibility with or without removing the subgroup.layerid from the setVisibility array


Allowing the group layer id's to be included in the setVisibility array has the following effects:

Toggle group visibility (adding/removing group layer id from array) has no effect on children layers IF THEY are already visible.  If a child layer is not visible, making the group layer visible/not visible will effect behaviour of child.  In other words, if the default visibility is false when the service is added, then you can effect child visibility with the group layer (addition or removal) from setVisibility array otherwise if default visibility is true, group layer toggle has no effect on child visibility.

While I don't want to publish a service with all child layers default visibility set to false, this MAY allow group layer toggle to function as outlined by Doug.  You could publish it that way, then on onLayersAddResult set them back to true (along with their checkboxes in your custom legend).  But that is extra coding, and who wants to that?

Any more comments/ideas?

[HeathClark]

Interesting that this discussion has gone cold.  I still would like some input on the following issues:

- Why setVisibility has problems if group layer id's are included in the array (and default layer visibility is set to true for children layers)?

- Why setVisibility does not work with a large list of layers? 

(EDIT)

It does work with a large list of layers IF/WHEN you are using a proxy page. - DUH!!

[TonyBacon]

Interesting that this discussion has gone cold.  I still would like some input on the following issues:

...

It does work with a large list of layers IF/WHEN you are using a proxy page. - DUH!!

Do we take that as sarcasm? Who would think that using a proxy page would have any affect at all in that situation. Not me.

It is interesting that this went cold. I have a custom layer control that I developed, started work on prior to ESRI including one in the API. It still handles situations that ESRI's control does not. I also encountered the group layer issue but have yet to dive into gaining a full understanding of it. As I read this post I was hoping to see a response from Mr. Neilson / SharpGIS.

I wonder how ESRI's layer control handles group layers. Anyone try that out? Hoping to avoid a couple days of experimenting.

Thanks

[StevenGriffith]

I think I've got this figured out, and why things are (seemingly) working whacky

given the layer structure

[0] - group layer 0       (visible)
[1] - - layer 1             (hidden)
[2] - - layer 2             (visible)
[3] - - group layer 3     (hidden)
[4] - - - layer 4           (visible)
[5] - - - layer 5           (hidden)

If you look at the layer.visibleLayers array you should see values [0,2,3] for the visible layers. To turn off layer 2, the visibleLayers array needs to be set to: [3]. Please note that layer 0 is missing, even though it is visible. If you include layer 0, you will "turn on" all of group layer 0's sublayers!

The key to making it work: When setting visibility for sublayers, only include "leaf" layerids. The sole exception to this, is of course, if you're turning "on" a group layer, in which case you want to include the group id number in the array.

Steve G.

[HeathClark]

Steve you are exactly correct in your analysis.  The method works on small services (small number of layers).  The challenge is making the method work on a service with a large number of layers (100+).  The method "errors" by cropping your service to the current extent and it does not change visibility on the selected layer(s).  Has anyone successfully implement a layer legend with visibility options on a service with a large number of layers (100+) and group layers?

//Update
Large map service (618 layers of which 70 or so are group layers)
REQUIRES a proxy page - however, setting the alwaysUseProxy=true; is what causes the "error" of cropping the service (and not changing visible status). I can only guess the proxy requirement is due to the large number of layers, although why setting alswasyUserProxy=true causes errors is more than puzzling.

[GabiVoicu]

I am still not getting the same results with the group_layer_id issue, however, the bigger challenge right now is the fact that the setVisibleLayers method crashes the service with a large number of layers in the array (500+ for a large area map that is our production service representing 80 facilitieis across 6 counties).  It creates a cache image of the current screen when I toggle a layer, then if I zoom-out / pan, all I get is that cached image of the dynamic service with no-redraw / refresh.  All other services respond correctly.

I agree, some insight/input from ESRI staff would be great on both issues.

this code pasted here fixed similar issues on my app


  //if there aren't any layers visible set the array value to = -1
        if(visible.length === 0){
          visible.push(-1);
        }


Thank you