Select to view content in your preferred language

Are custom field aliases for subtypes only configurable within a map?

373
1
Jump to solution
04-05-2024 12:53 PM
Andy_Morgan
Occasional Contributor

As I'm researching all the steps for UN configuration, I'm finding it very unfortunate that there appears to be no way to define a custom field alias for an individual subtype on the published service level. Do I have it correct? The only way you can specify a distinct alias for each subtype (or group of subtypes) is within the Pro map under Data Design -> Fields? 

For example, the part in the Load Data tutorial where it indicates the "additionaldevice" feature class field will be referred to as "Has Bypass" for the System Valve subtype. Here's how it shows in the feature class level for this field's "Alias" property:

additionaldevice: Additional Device, Has Bypass, Internal Meter, Metered 

System Valve's attribute table shows "Has Bypass" as the field alias, but only because someone manually changed it within the map. Fire Hydrant's attribute table hides "additionaldevice" field altogether.

So we are supposed to do this sort of manual changing of aliases for every instance where a feature service is consumed? This means every map our GIS technicians create, and every web map, and every Javascript SDK app and Experience Builder app...etc? I was really hoping there was going to be a way to configure this from the published service and consume subtypes with the aliases pre-defined. 

Please let me know if I misunderstood or if there is any other method for handling aliases. I ask because our Water Device feature class will likely have 80+ extra fields and ESRI staff have indicated in various threads and communication that performance may be impacted with having too many fields. (Yet we're forced to combine all point feature classes into one: valves, hydrants, pumps, interconnections, stations, meters, etc.) It's not realistic to say "just don't add so many fields". I cannot tell our engineers and field operations staff we'll get rid of some attributes to help for performance. We have many custom attributes in our GN to pull over.

Therefore, I get the impression it's highly recommended to aggregate fields for different subtypes into the same field wherever the data type is the same - i.e. Text (20) for valve type or hydrant type or pump type depending on the subtype...and maybe a Decimal field for sizes/diameters depending on the subtype...etc. But it seems like ArcGIS Pro was the only thing considered for conveniently defining custom aliases, and that assumes re-using the same map over and over with field aliases already pre-configured. 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
RobertKrisher
Esri Regular Contributor

In cases where you need a different field alias depending on the subtype, subtype group layers are currently the only means of achieving this. However, the process can be made significantly less tedious and manual by using something like the utility network properties extractor to export your field configurations to a spreadsheet (once) and then applying those properties to any derived map products you have.

Once you get used to setting field properties in this manner it isn't too different from how we've historically had to think about maintaining the dozens of different web maps used by a utility, where every field map has a different set of field order, visibility, and alias.

View solution in original post

0 Kudos
1 Reply
RobertKrisher
Esri Regular Contributor

In cases where you need a different field alias depending on the subtype, subtype group layers are currently the only means of achieving this. However, the process can be made significantly less tedious and manual by using something like the utility network properties extractor to export your field configurations to a spreadsheet (once) and then applying those properties to any derived map products you have.

Once you get used to setting field properties in this manner it isn't too different from how we've historically had to think about maintaining the dozens of different web maps used by a utility, where every field map has a different set of field order, visibility, and alias.

0 Kudos