Beyond frustrated: Ordering of layers in TOC not being saved

Question

This has been occurring since our subscription to AGOL, and it is driving me and a colleague absolutely insane.

Most of the time, when we move layers in the table of contents and save the map, the next time we open the map, those moves are not saved! We've tried with several different computers, many browsers, different internet connections and over months of time. Obviously we'll be calling soon, but I can't find anything in the forums about this. In fact, I've even saved 2 versions of the same map with different names, and both of those maps were DIFFERENT once opened back up! How is that possible?! There were no changes between those maps!

We are wasting ungodly amounts of time as our changes are not being saved 4 out of 5 times for no apparent reason (no our internet isn't dropping).

Any suggestions for us? This is not a trivial problem and it's not an inexpensive service.

AlanHammersmith · Answer

I am experiencing something similar, and perhaps it is related, but does not sound like the exact same thing.  For my web map, I have 4 CSV layers from the web added on top of the default Topographic basemap.  Pretty straight-forward.  I order them the way I want them to be, set drawing and popup info, and save my map.  All looks great.  If I close out of the web map (click My Content), and re-open the same web map, the layer order has been reversed.  If I change NOTHING in the map, and just save it again and re-open it, the layers are reversed again.  This opening and saving has become my (increasingly annoying) work-around for this bug (can we agree that it's a bug??).  I have built a JavaScript application that consumes this web map and depends on the order of layers for some of the data presentation, but since the configuration order keeps changing unexpectedly, my application keeps behaving unexpectedly.  Please help!

Thanks,
Alan
Stone Environmental
Montpelier, VT

Mike Minami · Answer

This is a drawing limitation. Here's why.

Shapefiles and CSVs that are stored in a web map are drawn by the client, like a web browser. Feature services are also drawn by the web browser, although the data is not stored in the web map. In your case, you are actually drawing some map services as features because you are specifying an individual layer in the map service (with a URL like http://xyz/MapServer/1).

When the map viewer opens a map, it reads the layers in the TOC and starts drawing the fastest to respond. In this case, the CSV layers stored in the web map return drawing information back to the browser faster than your map service. The alternative is to wait to draw the map until all layers have responded. Essentially you'd be staring at a blank map. Plus, services on the web sometimes aren't available, so the wait would be even longer, until a service timeout happens. Thus, the current decision is to start drawing layers for performance at the expense of order. I'm not sure if we can do much about this. If we go the other way and wait, people may not like the slow map displays.

Thanks,

Mike

Mike Minami · Answer

Can you share a URL to your map and describe what you're seeing, i.e., how the layers should be ordered and what you're seeing.

Thanks,

Mike