Sub Layers - Question to ESRI

[ZahidChaudhry]

I want to move most of my apps to HTML -5  and the only reason i dont is that there is no widget for displaying layer list with sublayers. I know there is third party widget but i want to stay away from them and also i dont have time to write one for myself. But my question to ESRI is that rather than providing me samples how to add flickr, please give me a sample thats is more aligned with normal app needs....

Question to ESRI:  Is there a plan to provide a layer list widget that support sublayers? or I should start developing my own?

Thanks

[derekswingley1]

We do not have plans to add a "layer list" or "table of contents" widget to manage map layers and sublayers. We've resisted adding this to the API because we don't want to encourage building generic, kitchen sink style viewers. I realize that we (Esri) do not have a consistent story on this as we still provide generic viewers for other platforms/technologies. We're open to discussing it further, but I personally agree with anti-viewer, anti-portal sentiments that some have expressed online for the past couple of years (most recent example).

[ZahidChaudhry]

We do not have plans to add a "layer list" or "table of contents" widget to manage map layers and sublayers. We've resisted adding this to the API because we don't want to encourage building generic, kitchen sink style viewers. I realize that we (Esri) do not have a consistent story on this as we still provide generic viewers for other platforms/technologies. We're open to discussing it further, but I personally agree with anti-viewer, anti-portal sentiments that some have expressed online for the past couple of years (most recent example).

Totally agree...That said, its a big problem when you access services from other agencies and most of the time every possible layer is published as sublayer and most of them are off by default. having access to sublayers, will not only solve that issue but useful in some cases...

[derekswingley1]

Is there a public example of a service that fits your description?

Is ArcGISDynamicMapServiceLayer.setVisibleLayers not an option?

[ZahidChaudhry]

Is there a public example of a service that fits your description?

Is ArcGISDynamicMapServiceLayer.setVisibleLayers not an option?

I am more interested in letting users have this ability to turn on/off sublayers...here are some URLs from USGS server

http://services.nationalmap.gov/ArcGIS/rest/services/NHD_Large/MapServer
http://services.nationalmap.gov/ArcGIS/rest/services/geonames/MapServer

[derekswingley1]

Thanks. If your app requires that users toggle layers in a service, it's up to you to build the UI for that.

[LefterisKoumis]

We do not have plans to add a "layer list" or "table of contents" widget to manage map layers and sublayers. We've resisted adding this to the API because we don't want to encourage building generic, kitchen sink style viewers. I realize that we (Esri) do not have a consistent story on this as we still provide generic viewers for other platforms/technologies. We're open to discussing it further, but I personally agree with anti-viewer, anti-portal sentiments that some have expressed online for the past couple of years (most recent example).

Totally disagree with this assessment. For GIS professionals who come from different areas of expertise but they use the same map, TOC would assist to provide an organizational structure. The layers for the specific are will turned on and the rest off. Checkboxes will provide the option to turn other layers on as needed.

[AdrianMarsden]

We do not have plans to add a "layer list" or "table of contents" widget to manage map layers and sublayers. We've resisted adding this to the API because we don't want to encourage building generic, kitchen sink style viewers. I realize that we (Esri) do not have a consistent story on this as we still provide generic viewers for other platforms/technologies. We're open to discussing it further, but I personally agree with anti-viewer, anti-portal sentiments that some have expressed online for the past couple of years (most recent example).

Derek -  the thing about that link you post, the main thing that jumps out at me, right in the title is the word "ONLINE"

My main app is to replace and ArcIMS app, which in turn replaced a non-ESRI GIS desktop app (with per seat cost) for our INTERNAL users.

As it is internal I have control over browser choice, training documentation, I can talk to all the users.  The users have a finite set of requirements and use my application daily.  They don't "discover" it.  They are not looking for " a single layer".  They don't then leave.  They know what layers they need and know the broad category these layers may live in.

I have, at last count, over 100 layers.

I have a user base ranging from 16 to over 70 in age, probably still skewed towards the older end - in other words Digital Immigrants, not Digital Natives.  For some the use of any IT doesn't come easy.  Having all my layers in nice groups that match their expectations is a must.

For ArcIMS this was achieved using David Bollingers TOC in my new one it is using Nianwei Liu's.  Both do an excellent job.  Esri should re-examine exactly what people are using their products for.

ACM

[JeffPace]

I am in the TOC camp.  Primarily for the reason:

As a developer, i only want to maintain one application. 
As a user, I want to be presented with the same interface everytime.

The one off/one layer apps are annoying.  Every one is different.  Maintenance is a nightmare.  User experience is terrible. 

The whole point of GIS is bringing desperate data together.  That means choices.

Oh, and most of all

The user should decide what layers to display, not the developer.

/my (not so humble) opinion

[KevinMacLeod1]

Derek I encourage you and the dev team to poll users on this functionaly.  Many developers are already using a hierarchical TOC, the AGS JS TOC, which is exactly what we want.  Ultimately it is the the request of users as Jeff stated.  They want a consistent map interface.  Users widely understand the purpose of a TOC.  At this point it is an expected map interface. 

From my experience users want a TOC, and an Identify that works (identifies visible layers from multiple services using the TOC, and including scale dependency).  

The API is really shaping as a robust web mapping platform.  These are the two biggest remaining components to tackle that I can think of.  Thank you for sharing your thoughts behind the design decisions with us here.