IdentifyParameters.LAYER_OPTION_VISIBLE still gives identify results on all layers

7923
26
Jump to solution
02-03-2012 09:36 AM
SwenWaschk
New Contributor III
I've used both the create layer list and the identify pop-up samples to create the following code (see first reply)


But if I turn of a layer in the layerlist it still is identified. How do i stop this from happening?
0 Kudos
26 Replies
SwenWaschk
New Contributor III
I think you are experiencing [NIM042441 The layerOption LAYER_OPTION_VISIBLE not working as expected while using Identify Task.]. The LAYER_OPTION_VISIBLE seems only response to the default visible layers in the map service.

To workaround this, as amarsden did, please assign the list of visible layer to the IdentifyParameters.layerIds property, which can force the identify task to only perform the find operation on the  specified layers.


Could you tell how I do this? My code is still the same as in the first post because I don't seem to be able to find out how to integrate the IdentifyParameters.layerIds
0 Kudos
AdrianMarsden
Occasional Contributor III
It looks like you should be able just to add

identifyParams.layerIds = visible


to

   function executeIdentifyTask(evt) { 
        identifyParams.geometry = evt.mapPoint; 
        identifyParams.mapExtent = map.extent; 


to give you

   function executeIdentifyTask(evt) { 
        identifyParams.geometry = evt.mapPoint; 
        identifyParams.mapExtent = map.extent;
identifyParams.layerIds = visible 


Should work
0 Kudos
SwenWaschk
New Contributor III
It looks like you should be able just to add

identifyParams.layerIds = visible


to

   function executeIdentifyTask(evt) { 
        identifyParams.geometry = evt.mapPoint; 
        identifyParams.mapExtent = map.extent; 


to give you

   function executeIdentifyTask(evt) { 
        identifyParams.geometry = evt.mapPoint; 
        identifyParams.mapExtent = map.extent;
identifyParams.layerIds = visible 


Should work


Thanks! It works!
0 Kudos
AdrianMarsden
Occasional Contributor III
An alternative I posted here

http://forums.arcgis.com/threads/68803-BUG-.visibleLayers-returns-group-layeys?p=240650#post240650

B
asically I had moved away from the check boxes I had in my earlier post.  Initially I tried "identifyParams.layerIds = dynamicMapServiceLayer.visibleLayers;"  but that fails when you have group layyers - see post.

So the function I now use is a simple check for layers and groups one

function getVisibleLayers() {    var visibleLayers = [];
    var items = dojo.map(dynamicMapServiceLayer.layerInfos, function (info, index) {
        layerID = info.id;
        if (info.visible && !info.subLayerIds) {
            visibleLayers.push(layerID)
        }
    }); return visibleLayers

}

Call in you id task code with

      v = getVisibleLayers();
        identifyParams.layerIds = v;



BTW, can anyone else (none esri staff) get the link to the bug report from
Shuping Li to work?


ACM
0 Kudos
__Rich_
Occasional Contributor III
BTW, can anyone else (none esri staff) get the link to the bug report from Shuping Li to work?
ACM

FWIW, just search Nimbus using the report number and you'll get to:

http://support.esri.com/en/bugs/nimbus/TklNMDQyNDQx
0 Kudos
AdrianMarsden
Occasional Contributor III
Many thanks - so reported over 3 years ago!!  So, I don't think I'll hold my breath for a fix anytime soon.
0 Kudos
KevinMacLeod1
Occasional Contributor III
Many thanks - so reported over 3 years ago!!  So, I don't think I'll hold my breath for a fix anytime soon.


Anyone know if this is fixed in 3.6?  (I am on lower API for a while longer).  Or if ESRI can comment whether it will be fixed?  NIM is still open.

My suggestion would be for ESRI to include a sample that is an Identify widget that identifies all visible layers and works well with AGS JS TOC with dynamic layers with many cascading groups with hundreds of layers, as well as consider including AGS JS TOC in the API itself.
0 Kudos
NianweiLiu
Occasional Contributor II
NIM is still open.


In REST API, "visible" means default visibility defined in map service, not in the client map instance. The JS API design separated task from Map/service, as a result, the task has no knowledge of which layer is actually visible -- because it does not hold a reference to the map/service instance.

Given the circumstance, it is much easier for the application code, which holds reference to both service and task, to passing the actual visible ID list into IdentifyParameter and use IDENITIFY_ALL.

To fix the "bug", the identify task class has to accept the map service layer in the constructor, which would be a bit awkward coding neatness wise, and I see no incentive to fix that from Esri perspective, so my advise is that do not count on it, use the alternative and move on.
AdrianMarsden
Occasional Contributor III
🙂 Now why didn't anyone at Esri state the above - so, in Microsoft term, "This behaviour is by design"

The "bug" should remain through, but be changed to say "make the documentation clear"
0 Kudos
NicholasGross
Occasional Contributor II
I've just run into this bug/design feature/whatever it is. I can't seem to figure a way around it. I have a popup window displaying the results of multiple identify tasks on multiple dynamic map service layers, each with sublayers. The layerId property of the IdentifyParameters seems to only acknowledge the ids of the sublayers, not the parent dynamic service.

So, if I have two services, one of which is currently visible and the other not, and I want this reflected in the identify results by only displaying attributes of the visible service, there doesn't seem to be any way to tell the identify parameters to ignore the hidden parent service because the layerId property is only paying attention to the sublayers. If I assign the layerId property "0", it's seeing it as sublayer 0 (not parent layer 0), and of course, every dynamic service has a sublayer 0, so sublayer 0 will be displayed from both services.

Does anyone know a good way around this?
0 Kudos