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!
Solved! Go to 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.
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.
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.
Thanks for useful information and discussion @RobertKrisher and @SamDeLore
I have also found few issues working with Subtype Group Layer.
1. When UNM Editing map has reference scale set, user cannot click anywhere on the graphics of the symbol in a map to bring a pop-up if the layer is sublayer of subtype group layer. e.g. a "Pole" layer within "Structure Junction". But same symbology and reference scale works if the layer is not added as subtype group layer and user can click anywhere on the graphics and bring a pop-up.
2. We have a need to develop some tools in ArcGIS Pro using add-ins or python toolbox and STGL poses few challenges. e.g. arcpy.ListLayers() lists both "Structure Junction" and "Pole" as a Feature Layer (isFeatureLayer as True and isGroupLayer is False). There is no apparent layer property for "Structure Junction" that denotes it is a Subtype Group Layer. Documentation talks heavily about Composite layer but I cannot find a property to tell when a layer is a composite layer / STGL. Similarly, for "Pole" layer, supports('dataSource') returns false despite being a feature layer.
import arcpy
aprx = arcpy.mp.ArcGISProject("CURRENT")
mapx = aprx.activeMap
for lyr in mapx.listLayers():
if (lyr.isFeatureLayer):
if (lyr.supports("dataSource")):
print(f"Feature Layer: '{lyr.longName}' has source '{lyr.dataSource}'.")
else:
print(f"Feature Layer: '{lyr.longName}' without data source")
if (lyr.isGroupLayer):
print(f"Group Layer: '{lyr.longName}'")
if (lyr.isRasterLayer):
print(f"Raster Layer: '{lyr.longName}'")
if (lyr.isBasemapLayer):
print(f"Basemap Layer: '{lyr.longName}'")
...
Feature Layer: 'Structure Junction' has source 'xyzxyzxyzx\UtilityNetwork\StructureJunction'.
Feature Layer: 'Structure Junction\Unknown' without data source
Feature Layer: 'Structure Junction\Electric High Voltage Pole' without data source
Feature Layer: 'Structure Junction\Electric Medium Voltage Pole' without data source
Feature Layer: 'Structure Junction\Electric Low Voltage Pole' without data source
Feature Layer: 'Structure Junction\Marker' without data source
Feature Layer: 'Structure Junction\Wire Cabinet' without data source
Feature Layer: 'Structure Junction\Wire Handhole' without data source
Feature Layer: 'Structure Junction\Wire Junction Box' without data source
Feature Layer: 'Structure Junction\Wire Vault' without data source
Feature Layer: 'Structure Junction\Wire Pedestal' without data source
Feature Layer: 'Structure Junction\Wire Structure Guy' without data source
Feature Layer: 'Structure Junction\Wire Support Pole' without data source
Feature Layer: 'Service Territory' has source 'xyzxyzxyzx\UtilityNetwork\ServiceTerritory'.
Basemap Layer: 'World Street Map'
3. The biggest disadvantage of STGL is limiting child subtype layers to max three attributes based symbology. We have had requirements to symbolize based on more than three attributes. e.g. for a Switch group, it needs to be based on Asset Type e.g. Disconnect Switch vs Load Break Switch, whether it is inside a substation/assembly (content) or a pole-mount, weather it is normally open/close and weather it is in-service or not. One way to achieve this is by creating layers for asset type(s) and may be other attributes using a definition query and then using thematic symbology. With STGL, we lose ability to apply definition queries.
Schneider Electric's ArcFM Editor XI requires the editing map to be configured as STGL, otherwise some ArcFM tools do not work. So, it seems we have to live with above limitations for now to deploy ArcFM XI.
Thanks,
Vish
@EstherSmith_Dev I feel your pain on the STGL support, it has been a massive headache for us.
I haven't seen issue 1 before, what are you using to open the map? Pro/EB/Map viewer? the map viewer only support STGL's in recent releases, I'm not sure if EB does yet, which version of enterprise are you on?
Issue 3 you might be able to solve with a custom expression, but that's a real pain and I'd be warry about the hit on performance, especially on feature layers. This limitation is one of the reasons we excluded proposed / abandoned features from our UN, removed the need to account for them everywhere!
The other trick I've used that might work, is leaving symbology to a referenced vector tile layer drawing on top of transparent UN feature layers. It works pretty well and makes the app feel much faster, just need to setup the tile cache rebuild in portal and it will keep itself up to date.
@SamDeLore Issue #1 happens in ArcGIS Pro 3.3.1 map.
Good suggestion with Vector Tile Layer. Will try to play with it.