nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Najděte více příspěvků označených jako

Accepted answers

All comments

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

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.

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.

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

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

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

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

vizLayers_2.png

vizLayers.png

HemingZhu

I had some time today and just wanted to comment. Hopefully the following will help resolve any unsettled issues regarding visible layers and how to control them.

I did some fact checking and as expected visibleLayers returns an array of visible layer index values and does not return group layer index values. See my screen shots.

The key way to dynamically manipulate what's visible is by adding or subtracting layer index values in an array which gets passed into setVisibleLayers(). This can be done by using native splice and push JavaScript methods. See this Esri sample, specifically the toggle function.

http://help.arcgis.com/en/webapi/javascript/arcgis/help/jssamples_start.htm#jssamples/widget_legendvisiblelayers.html

As for a limit to the number of layers which can be passed into setVisibleLayers, I am not aware of any. Hopefully this helps.

Regards,
Doug Carroll, ESRI Support Services SDK Team, Technical Lead
http://support.esri.com/

Doug, I respect what you said, but that is not what i got when i test on http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Census_USA/MapServer/. It cleared show that layer.visibleLayers =[0,1,2,3,4,5]. among them 2 is a group layer. Do i missed something?

HemingZhu

Interesting concept, except I don't want to try to manage multiple MXD/MSD files or lump things together, the organization we have makes sense within the facilities we manage.

I totally understand. What David Peters said is from the performance point of view in term of system design and network.

HeathClark

Interesting concept, except I don't want to try to manage multiple MXD/MSD files or lump things together, the organization we have makes sense within the facilities we manage.

Anonymous User

I had some time today and just wanted to comment. Hopefully the following will help resolve any unsettled issues regarding visible layers and how to control them.

I did some fact checking and as expected visibleLayers returns an array of visible layer index values and does not return group layer index values. See my screen shots.

The key way to dynamically manipulate what's visible is by adding or subtracting layer index values in an array which gets passed into setVisibleLayers(). This can be done by using native splice and push JavaScript methods. See this Esri sample, specifically the toggle function.

http://help.arcgis.com/en/webapi/javascript/arcgis/help/jssamples_start.htm#jssamples/widget_legendvisiblelayers.html

As for a limit to the number of layers which can be passed into setVisibleLayers, I am not aware of any. Hopefully this helps.

Regards,
Doug Carroll, ESRI Support Services SDK Team, Technical Lead
http://support.esri.com/

forum1.jpg

forum2.jpg

HemingZhu

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.

One thing i remembered from reading the document (David Peter's "Building a GIS: System Architecture Design Strategies for Managers") is that avoid to put too many layers in a one map services and tried to split layers into several map services.

HeathClark

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.

HemingZhu

From my testing I have found different results than what your post would suggest, for example:

Sample MapService

Facility Layer(0)    - Group Layer
Building(1)    - Feature Class
Pipeline(2)    - Feature Class
Encasement(3)    - Feature Class
Another Facility Layer(4) - Group Layer
Vaults(5)    - Feature Class
Fittings(6)    - Feature Class
Easements(7)    - Feature Class

All within one dynamic map service.

Scenario One:
var vL = [0,1,2,3,4,5,6,7];    -Visible Layer Array
var layer_id_index = dojo.indexOf(vL, 2);                
if (layer_id_index != -1)
vL.splice(layer_id_index, 1);
               
dynamic_layer_data.setVisibleLayers(vL);
Results:
No change in visible layers.

Modification to Code
var viz_layer = [1,2,3,5,6,7];  - Remove the GroupLayer ID
Results:
Pipeline Layer is �??Hidden�?�.

I have found that including the GroupLayer ID�??s in the visible layer array causes the setVisibleLayers method to fail (ie. [0,1,2] is a not-valid/illegal and [1,2] is a valid/legal array)

Scenario Two:
If the dynamic_layer_data contains a large list of layers (I have tested against 633 with divided across 75 group layers), the same code above under the modified scenario does not work. I could painstaking try to find the �??cut-off�?� point but would like to know if there is a definitive (ESRI) answer on if the setVisibleLayers method works on an infinite number of layers or if it can only handle 50, 100, etc.

I went back looking at my code and my notes. i have done it in silverlight/wpf api which is almost identical to js api in terms of visibility properties and methods. What i said here is exactly what my notes said. So I tested this issue using JS api and an esri map services: http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Census_USA/MapServer. You are largely right on this expect I found out that whehter putting group layer id in visible id array or not doesn't make any different (visible = [0, 1, 3, 4, 5] vs visible = [0, 1, 2, 3, 4, 5] -2 is the group layer). I am very interested in ESRI or someone's input on this.

HeathClark

From my testing I have found different results than what your post would suggest, for example:

Sample MapService

Facility Layer(0)    - Group Layer
Building(1)    - Feature Class
Pipeline(2)    - Feature Class
Encasement(3)    - Feature Class
Another Facility Layer(4) - Group Layer
Vaults(5)    - Feature Class
Fittings(6)    - Feature Class
Easements(7)    - Feature Class

All within one dynamic map service.

Scenario One:

var vL = [0,1,2,3,4,5,6,7];    -Visible Layer Array
var layer_id_index = dojo.indexOf(vL, 2);                
if (layer_id_index != -1)
vL.splice(layer_id_index, 1);
               
dynamic_layer_data.setVisibleLayers(vL);

Results:
No change in visible layers.

Modification to Code

var viz_layer = [1,2,3,5,6,7];  - Remove the GroupLayer ID

Results:
Pipeline Layer is �??Hidden�?�.

I have found that including the GroupLayer ID�??s in the visible layer array causes the setVisibleLayers method to fail (ie. [0,1,2] is a not-valid/illegal and [1,2] is a valid/legal array)

Scenario Two:
If the dynamic_layer_data contains a large list of layers (I have tested against 633 with divided across 75 group layers), the same code above under the modified scenario does not work. I could painstaking try to find the �??cut-off�?� point but would like to know if there is a definitive (ESRI) answer on if the setVisibleLayers method works on an infinite number of layers or if it can only handle 50, 100, etc.

HemingZhu

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

You are on the right track. Just be aware of a couple of things. Suppose you have a parent layer 0, and a couple of sublayer 1 and 2. If you set the parent layer 0 visible, you still have to set the visibility of layer 1 and 2 for them to show or not show - these visible layer array [0,1] or [0,2] or [0,1,2] are legal, while those - [1] or [2] or [1,2] are illegal. If you set parent layer 0 not visible, then neither 1 nor 2 should in visible layer array. You can use LayerInfo's parentLayerId and subLayerIds properties to manipulate the situation.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.