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; } } }

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

Trouver plus de publications taguées avec

Accepted answers

All comments

BenFousek

Hey Derek,
I read Brian Timoney's article last time you linked it when someone asked this same question a while back. I agree with anti-portal sentiments myself as a web user looking for specific information. However, I'd like to make the argument the jsapi should have a TOC widget.

Not everyone is developing applications for the web. Like ACM, I'm not creating applications for the public. I'm developing full featured portals with lots of layers, tools and tasks designed for the intranet. My users have the app open all day and use it for several aspects of the company's operations. Since editing, some more advanced features of the api, html5, etc have come along, I can't keep up with requests for new layers and functionalities.

The TOC is where layer functionality is initiated. Case in point, the ArcGIS Online Map. Layer transparency, layer order, setting scales, etc. In my case identify, query, geoprocessing, editing and more are all initiated through the TOC for services, sub-layers and feature layers.

The jsapi is, in my opinion, the most complete and versatile web mapping api ESRI offers. Combined with everything dojo does it lends itself to creating complex applications. Google Maps is great for creating a feature specific map someone comes across while using a search engine to search for dog parks (not that the jsapi isn't), but GMaps isn't the api to build a full-featured web based GIS primarily using ArcGIS Server and all it's capabilities. Just today I saw Matt Driscoll's post on the upcoming swipe widget, which only goes to show that the jsapi is the api for high functioning web based GIS.

I just feel a TOC is just too critical a component not to be included with the api in some form at this point in its evolution.

As always, keep up the good work.
Ben

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.

JeffPace1

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

adrian.marsden_DevonCC

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

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.

derekswingley1

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

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

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

Is ArcGISDynamicMapServiceLayer.setVisibleLayers not an option?

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

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

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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