Apply Symbology from REST Endpoint to Portal Item

[ZachBodenner]

Hello,

Recently my organization made the switch into an Enterprise Environment. Rolled out the Portal, updates servers, etc. We have a number of web maps and apps for end users, presymboloized and configured. This is accomplished by publishing services from ArcMap or web layers from Pro, then consuming the resulting REST endpoint (and its published symbology - important to the issue) in Portal. The web maps are then shared with groups based on the end users' departments.

However, we want the end users to be able to create their own maps to share within their departments by adding hosted feature layers (so they don't have to go to the REST endpoint itself to add data). We hope to accomplish this through department specific Data Stores. Today we added one department's data to a Data Store, resulting in Map Image Layers and Feature Layers for all the data contained within the .sde geodatabase. 

Here's the issue: I'd like to be able to apply pre-existing symbology from a previously published REST endpoint to a Map Image Layer or Feature Layer (or both). For example: I have a dataset of dozens of layers of engineering infrastructure (water main lines, valvues, etc). It would be tedious to open each map image layer (containing only one of said dozens of layers), apply the symbology appropriate, save the layer, and move on. Is there a way to capture the symbology that is already present in a published REST enpoint and apply it to an item in Portal?

[Anonymous User]

Hi Zach,

You can modify the symbology of a service through the Visualization tab on the Item Details page of the service. Then, when you bring the service into a new web map or app, you should see the new symbology reflected. For existing web maps and apps that already have the layer configured, you may need to remove and add back the layer to force a refresh for the symbology.

Alternatively, you can use ArcGIS Online Assistant with your Portal organization to go into the Web Map JSON and copy/paste symbology from the REST endpoint, though this method may involve significantly more risk and is technically not a supported workflow.

Good luck!

-Calvin

[ZachBodenner]

Unfortunately I don't think that will accomplish what I'm hoping for. The problem is that much of the symbology I want to copy into Portal items was created in ArcMap or Pro, which means it isn't necessarily something I can apply in the Visualization tab.

[Anonymous User]

Hi Zach,

If there are already map image and feature layers in your Portal organization's content that have the desired symbology, then perhaps you could grant your users access to those layers to add to their own web maps and apps? 

If you really want to go the route of publishing entirely new map image and feature layers through a registered data store item, then you may want to look further into copying the drawingInfo from the REST endpoint of the symbolized service and copy it into the JSON of the new service. Again, this can be done with ArcGIS Online Assistant.

-Calvin

[JYI]

Unfortunately I am facing the same issue as Zach, and ArcGIS Online Assistant does not provide the symbology settings for the hosted feature services. 

I am with Portal 10.7.1.

I need a way to make the newly published feature services have the same symbology, popup etc. settings as the existing feature services. The new feature services are pointing to the data in enterprise gdb now, while the old ones data come from filegdbs on Portal. 

[ZachBodenner]

Yes unfortunately I was not able to figure out a fancy solution to the problem. I removed the automatically published services that come through the Data Store Batch Publisher, and manually republished each with the user-expected symbology. I know one possibility would be to save the feature layer with new symbology in Portal itself, but some of the layers required symbology that was authored in a desktop app and was not available in the Portal web environment (custom point markers, etc), so the long way 'round is what worked best.