UPDATE: I figured out what the problem is and it seems like a bug. Collector for ArcGIS will not take a map area offline if there is a copy of a feature service in the webmap. So if I make a copy of a functional/sync enabled layer in the webmap and save the webmap, I can no longer make an offline area in the new Collector where I could do so just fine before I made the copy of the layer. The same webmap with a copy of a layer works as expected and downloads in Collector Classic. Is this a bug?
Original Post: I've been testing the new Collector to prep for transitioning our organization and have noticed that some web maps will download in Collector Classic (and have always worked fine in Collector Classic), but throw errors when trying to save a map area in new Collector. The error is a generic, "Download Failed" with no other information. My workaround has been to create new maps and that has worked fine for me, but I have users with existing webmaps that are experiencing the same problem and would like to tell them if there's another fix other than make a new map or use Collector Classic.
Are there any reasons why this could be, or things I can troubleshoot? All map layers are sync enabled, webmap has offline mode enabled, there's at least one editable layer in the map, I'm not trying to download an egregiously large or detailed area, etc.
Why would a map download work in Collector Classic and not Collector for ArcGIS? I'm wondering if anyone else out there is experiencing this too.
I'm noticing a similar issue. One of many bugs with the new Collector app, and it's almost impossible to find any documentation on this new app because all you get is results for Collector Classic. C'mon ESRI!
There have been issues noted in the past with the workflow of utilizing copied layers offline. The short answer is that this is not recommended practice for offline maps. There is certainly great use for copying a layer in other situations. The way to accomplish this same workflow successfully would be to utilize Feature Layer Views, summarized in this blog.
In response to Brant, admittedly the doc page page is sometimes hard to locate as Google will favor results for Classic over the current version as its so new. This should change in the future but for now I suggest bookmarking the following link:
Collector for ArcGIS Resources | Downloads, Training & Documentation
Thanks for your response. I use layer views a lot, they are extremely helpful. Some of our staff members have the 'user' privilege level and thus can't make feature layer views as far as I know, which is why some of them are making copies of layers in the webmap.
I can make views for them if they communicate the need but would be nice if there were another workaround that still allowed them to manage things independently. Any suggestions?
I'd like to build on Danielle's reply...
The inability to take copied layers offline sounds more like a bug than a "limitation" in the Collector app Don't get me wrong, I love feature layer views and use them a ton, but I don’t see them as a reasonable solution when a user just wants to add a second, filtered, version of a layer to a map quickly and efficiently, and may not need that layer in any other maps. Especially since they would be relying on the owner of the layer to create and maintain these view layers for them. This would become a huge time sync for the GIS Professionals or content creators of an organization where many users at the Creator license level are accessing other users' data to build maps.
If taking layer copies offline isn't achievable, maybe ESRI could add a functionality to ArcGIS Online that would allow users to create view layers of their own from layers that are shared with them, but not owned by them. Just a thought.
Also want to point to this blog discussion, which is related: Blog discussion: Take the same layer offline twice in Collector using feature layer views
The new Collector app is looking great. Good work ESRI, and please keep the updates and improvements coming!
I totally understand but as a 'user' or 'viewer' type they are not supposed to be able to create content, which is what creating a hosted layer view is doing. Copying the layer is about as close to creating new content as they can get, but they still cannot save the layer and it will exist only within this map.
The problem with copy layers and working offline is that when the offline database is created it sees the two layers as the same (because they have the same source) and this can lead to undesirable behavior with feature creation and display, meaning definition queries will be ignored. The fact that the download worked in Classic was coincidental. We are certainly following this issue and do plan on adding a note in the documentation to help explain this, but for now the recommendation is to utilize Hosted Feature views. Thank you for your feedback!
Thanks for the response. Just to be clear, I am talking about other users at the 'Creator' license level. I work at the State Government level and often have county users (outside of my AGOL organization) accessing my content and applying filters and symbology that suit their needs. A given county might create numerous copies of one of my layers within their own maps, and as you mentioned, this wasn't an issue for offline workflows in Collector Classic (or at least kind of). So many previously created maps are now rendered useless with the new Collector App.
Would it be possible to allow copies of a feature layer in a map to be downloaded as long as editing is disabled on those copies? Most of the time I think the users (creators) making copies of my layers are doing so for reference and to help quickly identify certain features of interest via symbology. So in this scenario, only the main layer would have editing enabled, and any copies would have editing disabled and used as reference only.
I'd really like to see this on the improvement list for Collector. I think adding documentation to explain this as a limitation is an indicator that ESRI doesn't see it as an important feature, but I would be surprised to hear that this is not interrupting the workflow of many users.
Again, thanks for the hard work regardless!
These are good points and they did get me thinking of another potential alternative. Would it be beneficial to you if the owner of a Hosted Feature Layer could configure in the layer settings to allow Views to be created by others (maybe by certain users or user types they define)? I say this because i'm not confident the stance will change regarding Copy layers and offline use, regardless of if they are editable or not.
The best way to get either of these ideas in front of the team would be to submit an enhancement to Support. This also helps gauge how many people it may be affecting. If you create an Idea on the the Geonet Ideas page you can also have Support link the Idea to the enhancement.
Yes that would definitely be beneficial. As long as creator level users from inside and outside of my organization could use my feature layers and view layers to create "View" layers of their own that could be taken offline in Collector alongside other layers created from the same original/parent layer.
I'll go ahead and submit an enhancement, as you suggested.
Here are some ideas, for those that might want to vote on them:
Allow users at the Creator level to create "View" layers of their own, from shared content (layers a...
I agree with Brant, the ability for others to create their own views would be very helpful, especially if the owner of the layer is able to further configure who is able to make views. It does add a level of extra work for the end user (and an extra level of instruction/troubleshooting for the administrator), which is why I was hoping layer copies could still be pursued. Still, I think creating views from shared layers would be a beneficial feature that would positively impact other aspects of our AGOL Org, not just Collector users.
That said, our department's need for layer copies in a webmap is for ease and efficiency, most of the time for filtering and symbology purposes and not necessarily editing (although I know of at least one person who does edit his layer copies). If a different workflow were implemented as Brant suggests so the copies are read-only, I think users would gladly adapt if I convey to them that editing layer copies is not best practice.
Thank you for submitting those ideas Brant! Wish I could vote more than once