View by status   

User Assignable Layer Ids for REST Map Services


  • 1260

  • I am constantly adding and removing layers from map services.  Each time I do, the layerid shifts.  This is a pain.  If I add a new layer, I have modify the source of my apps to reflect the updated layerid for querytasks, etc etc.  This would be a huge plus.

    Note from Esri (Dec 16, 2014): Implemented in ArcGIS 10.3 for Server. Please this help topic for details.
    Tags :
     LayerID REST
    Posted by   Buddhatown  to ArcGIS ServerWeb Apps and APIs Aug 19, 2011

Share this idea Report Abuse

Comments (16)

Please log in to post a comment.

Jul 17, 2014
I am working with a large organisation and have this issue now.  They have a 2000 user Portal for ArcGIS and a GIS team that manages the map services (probably 20-30 map services with 10-20 layers each) for their department/organisation.
Items added to Portal are added at the layer level so that users can find and add layers to their web maps.
So, the same issues about changing a map service - add/remove/re-order layers exist, in that any of those operations will break every web map that references the layers below the change in the MXD/service as the layer IDs will have been changed.

So, we are faced with either:
1) having 1 layer in a map service, and lots of map services, or
2) only adding layers to services at the bottom of the list, and never removing/re-ordering any

Neither is very appealing.

Incidently the new web app builder will have the same issues as all the config where layers are concerned is done via REST URLs to feature layers (at least in the beta version) and baked into the app/template.

Dec 5, 2013
We used to have this problem in ArcIMS too, where the layer IDs were numeric and constantly changing.  Finally, in ArcIMS, we were able to use user-defined names in the AXL files.  Allowing the user-defined names was a huge, positive advancement.  I would really like to see ArcGIS Server catch up to ArcIMS in this area as it would be a major time savings for us, preventing us from breaking and fixing apps every time we add/delete layers.  Thanks.

Dec 11, 2012
Why not make it that the server assigns a unique static ID at the time the layer is created?  If you can only access a layer by it's ID and that ID is changed every time a layer is added or removed, that complicates the situation for developers enormously.

Dec 5, 2012
Please do this as it is probably one of the key issues I have with ArcGIS Server particular with complex services and web mapping clients.

Sep 7, 2012
I do agree with Buddhatown. for this we as developer has to write our own business logic to avoid this burdon.

May 8, 2012
Same issue cited here

Ability to set static layer ID would be nice, but I can guess why it is difficult.  ArcIMS did a lot of heavy lefting for the coder, and with a ArcXML config file, setting user assigned unqiue layer ID is not only built-in but almost required.  ArcMap workflow never did that, and to do that for MXD would require a brand new component Desktop never had before, and somewhere along you need to guarantee the uniqueness of each layer ID within the same map service or you don't have REST, and the Server needs to read and route the unique layer end point by this new field that entails a new server engineering feat, thus adding bloat all around even as Esri is trying hard to make everything run faster. 

The simple answer to this is to publish ONE data layer per 1 map service.  Having to arbitrarily group datasets in certain order under separate map services was never going to work for long as more and more data are online.  What we are really asking for is a user defined unqiue URL pointing to evey data layer published online, like the way WordPress posts are.  I am guessing that is the way ArcGIS Online may be headed.  

May 7, 2012

   Thanks for the comment.  While what you suggest could work, that would mean that every application that is build from a standard service would need to use the same technology, and be updated at the same time. For enterprise services, we don't necessarily even know who is using the service, and so we could be breaking applications that we don't even know about, and who we have no control over.

   The web service model is really powerful because of its open platform, but without fixed IDs it becomes very hard to realize that benefit.

May 6, 2012
Power to the user!

May 3, 2012
It's a good suggestion, but I have to ask a question.  Why are some developers writing applications that reference specific layer indexes anyway?  Obviously you need to know the index to perform certain layer specific operations.  There are a number of ways to address this.

One way would be to create a list of key/value pairs that associate an ID that you assign with the layer index.  Or you could create a function that looks up the index from the service info.  Wouldn't that minimize the changes you would have to make to other parts of your application?

May 3, 2012
While we do as much relative layer referencing as possible, we sometimes want to save information about the current layer. If the layerid changes or, as happens more frequently, the layername changes, we no longer have a way to tie back to a layer in a service.  Broken.

May 3, 2012
Definitely one of our biggest issues with ArcGIS Server.  Please fix this as soon as you can!

May 3, 2012
I agree.  That happened to us in the middle of responding to a fire.  We changed the draw order of some layers and, suddenly, another department that was using the map service, too, had problems.  We had to go back to the original draw order, which did not seem optimal for what we needed to display.

May 3, 2012
It would be helpful to have have it fixed, and I agree that the userid tie-in would be fine.

May 3, 2012
Hello.  Please do this - this is by far the biggest issue that we have running Enterprise systems with data that needs to be added on the fly if necessary, or even for production data.  We have entities that build applications off our web services that will have their applications break if we add a single layer (and some of our REST endpoints have over 300 feature classes in them).

In ArcIMS we could set the LayerID within the .axl file.  For ArcGIS Server you should be able to do the same thing, and the .msd or publication process can check and make sure that there aren't any duplicates.

this is by far the most important enhancement that we need at the County of Los Angeles.

Yes, this is becoming an enormous maintenance headache for us as well. Everytime a layer is added or deleted from a map service, the layer ids change, and the REST URI for the layer no longer works or points to a different layer.

REST URI's should be immutable - once published, they should continue to work.

ArcIMS .axl files had a nice simple solution to this - the layerid could be user assigned.

Sep 26, 2011
I think its more important that the layerids not change if you add, delete or reposition layers in a mapproject instead of having the opportunity to set assignable layerIds.

Important advantages:
It would be possible to save layer settings for a map service. For example it could be very helpful for the customer if you leave a map client to save settings. Opening the next time you see the same layervisibility.

Widgets which use query task with layer ids will work stable.

Much less work for the Administrators

Much less error possibilities in widgets and configurations, if you editing your map service



Terms and Conditions   |    Feedback   |   FAQs
Previous MonthNext Month