keep webmap service item id static

1688
3
05-16-2019 10:28 AM
Status: Open
by Anonymous User
Not applicable

When you add a layer to a service, the webmap does not see it.  Until you re-add the layer. We have to redo all popups, labels, symbology, other webmap settings etc.  Stressful for production viewers. 

First, ideally the issue of webmap staying in sync with services will be resolved in an AGOL update. 

So re-adding it will become unnecessary.  (in other words we shouldn't need to constantly re-add a service to a webmap just because we add or remove layers in the MXD)

But the connected issue to this, is it changes the 'id' of the service 'layer' in the webmap JSON, if you re-add a service.  This needs to remain static or at least have some way of us being able to arbitrarily set it, so I can change it back to what it was.  Or perhaps (and in addition to, as an optional alternative) reference the layer by 'name' as I proposed last year.

The reason the 'id' is so, so important is it is vital to how the Share widget in webApp Builder works, and how we can programmatically do things like expand layers in the layer list or do other actions. Because this 'id' gets carried into the DOM node IDs.

From my earlier thread....

The Share widget in the WebApp Builder is an amazing, amazing feature.  Truly an amazing functionality.  For example this URL zooms to an address https://www.sagis.org/map/?query=SAGIS2018allLayers_9233_124%2CPROP_ADDRESS%2C10%20WESTGATE%20BLVD%2...  Or I could do it by PIN or Name etc etc. But... if I add a layer to my viewer service, which is inevitable... it will change the "id" (9233) of the layer/service in the webmap.  

 

This prevents integration of Esri viewers with other systems.  Because let's say another agency wants to tie into my viewer. If the ID didn't change, it'd be easy, just give them the URL and tell them to append the PIN or Address or whatever, to the end of the URL. Presto, it zooms the map to a feature based on a query. But.... the second I re-add the service, this will break because the ID 9233 changes to another number. Now all they would have to do is update their URL. But... asking a government agency to repeatedly change something is definitely not feasible.  It just won't get implemented unfortunately, no matter how quick the change, it requires a change which means not feasible.

 

I suggest this ID remain static and unique not change. Even if we re-add the service, it should know it is the same service and have the same ID or even allow us to update the ID.  I'm sure I could change this in the JSON but I don't want to change something so drastic in webmap raw JSON unless I know it won't have any other ramifications.  The Share widget allows for amazing integration of Esri viewers with other systems - however, this is a roadblock until we can get the ID to remain static.   

Somewhat secondarily, it affects customizing the layer list because the ID gets baked into the DOM as I noted above. Not too bad for me to just update the DOM ID references. But asking other agencies to update production systems like the tax assessor each time I add a layer will not be feasible.

.....

I understand updating a vast platform like AGOL will be a long-term process and we want to get it right, for a new milestone update.   However, I would recommend this ability to have services stay in sync with the webmap be a feature that is added to the next-gen AGOL.

https://community.esri.com/ideas/15068-webmaps-that-actually-work

https://community.esri.com/ideas/15734-option-to-use-layer-name-instead-of-layer-id-number-for-servi...

https://community.esri.com/ideas/15372-enh-000108149-enhancement-allow-the-option-to-refresh-or-rese...

3 Comments
JoeBryant1

What he said!

The current workflow is a massive waste of time. And it makes the GIS publisher look very unprofessional to the end host when you are constantly asking them to change the URL of their embedded links.

KoryKramer

Kevin MacLeod‌ have you looked into Preserve layer and table IDs?  Is that not working?

by Anonymous User

Hi Kory, I'm referring to the service ID in the webmap in the JSON.  (Not the layer ID.) I suggest it  should remain static. Or in addition, we should be able to change that, if we want, so as to change it back to what it was, for example.  I wire up things like Layer List click events to it. That is how I make layer list auto-expand certain layers. (that should be a GUI option also but until then, I wire it to the DOM node ID, which includes this webmap service ID hence why I prefer it to stay static).  The bigger issue, is requiring us to re-add data, because if you add layers to a service, they do not get picked up by the web map.  The web map is "dumb". It does not stay in sync with the service when it gets republished and we add layers or change layers. This necessitates a lot of extra work. Redoing popups, scale dependency, the whole 9 yards for webmap config.  

On a separate sidenote, regarding layer IDs, I emailed you some example MXDs with annotations. Even with the 'unique numberic layer id' checked in the TOC so layer IDs don't change, they do change if annotations are present, and they become a -1 layer ID. With hundreds of layers that is time consuming to fix each time I publish or add an annotation.