Question about UN Symbology

[TSmith]

Hey all, 

It is to my understanding that publishing a feature service with full UN Capabilities (i.e. tracing, editing, network topology) does not allow for subtype group layers or symbology that is more involved than simply symbolizing by "ASSETGROUP". 

I am curious to see how people have handled various user requests on symbology (I would think symbolizing in pro/a webmap would be the proper path forward) but I also know that it is possible to publish separate services referencing the same dataset (i.e. a Hydrant Feature service pulling from Water Device published as its own item). <-- the problem with this is it seems unnecessary/redundant. How have you all managed the production UN environment as opposed to the "view-only/light user" environment? 

Any suggestions or insights are helpful. Thank you!

[RobertKrisher · Accepted solution]

This topic is discussed in this article: https://community.esri.com/t5/arcgis-utility-network-blog/best-practices-for-working-with-utility-ne...

You have a lot more control over how features appear through using a web map than you do with a map service, and this is the recommended approach. Each service you publish also consumes additional resources on the server. Publishing 100 different services to support 100 different maps is not scalable but publishing 1 service that is used by 100 maps is.

You typically maintain a small number of features services that expose your enterprise data (see above article), then your web maps provide different experiences on top of these services.

[SamDeLore]

Right now, we have 2 core services (UN7, Pro3.3.1, Enterprise 11.3)

Service 1 is a stripped-down UN Feature service for tracing / diagrams and UN functionality. This service is added to a map using subtype-group layers(STGL), so each Asset Group has its own symbology / zoom scale, pop-up & labelling config all done in the map.

This works well but be careful about the zoom scales your feature classes turn on at, even if your subtypes are set to draw at lower scales, I've noticed the map will draw them, then turn them back off.

One annoyance of this approach is managing the layer config, with the service being bare, you'll need to do a fair bit of configuration in the maps you create, and STGLs are a bit hit and miss with tools that support them.

eg. If you export layer files to save your config, the layer file will save the whole feature class in each STGL, if you apply that to a new layer it will add values to your symbology that don't exist in that Asset Group. (Sometimes hitting the add all values button on the symbology pane will clean this up, other times it will undo everything). Copying and pasting the layer is probably a better approach but if you need to re-point the data source that can be hit and miss with STGLs

I've also found (and raised) a few bugs about working with STGLs and found I cannot manage the symbology in the map viewer, only in pro, but given the structure of the UNM I think they're absolutely the best way to serve up data to apps / users.

Service 2 is a map image only service with most config applied to the service itself. Many of our users do not need the UN functionality, so having a service with all the config applied is extremely useful and really makes spinning off new maps / apps a breeze for users who aren't quite as savvy with the nitty gritty details of services / maps & publishing. 

We're not quite in production yet so we'll see how it goes, I'm sure we'll probably need some tweaks.