Labels & Arcade Expression- is this a bug or by design?

[SteveCole]

I've spent some quality time with Pro identifying its deficiencies in the context of my personal workflows and ran across this. I took a layer of cities and tried to label the polygons using the name field which has the city name but stored as all caps ("LOS ANGELES", "SAN DIEGO", etc).

No matter- I'll just add an Arcade expression and convert the labels to proper case on the fly:

Proper($feature.NAME)

Hmm. My labels are still all caps. This goes on for awhile. I tried different permutations of label expressions, VBScript vs Arcade, etc and I still could not get anything but upper case labels. I finally noticed that the Text Symbol Style I had selected was the Landform/Physical Region style, which shows an example of two letter As, both upper case. I changed my text symbol style to Landmark/POI and I finally get proper case labels.

So- was this by design or a bug? I didn't see anything in the help documentation that Arcade (or any label expression) will not override properties of the selected Text Symbol Style. I'm using Pro v2.1.0

Thoughts?

Steve

[MarkBockenhauer · Accepted solution]

The textcase in the symbol properties is not over-ridden by Arcade expressions.

Your expression works when Textcase is set to Normal, as part of the text symbol properties.

When text case is not Normal, Arcade expression does not apply.

For both pictures above the expression was defined:

Mark

[SteveCole]

Thanks, Mark. As you point it out, that makes sense. I know that I did not see that myself but there are multiple dimensions of options in Pro. Perhaps the help documentation can be updated to reflect this restriction that Arcade (and other expression languages) respects.

Thanks again-

Steve

[XanderBakker]

As I understand this is not a restriction of Arcade. It is a matter of the order that is applied in the process. The Arcade expression will transform the text correctly. The last step is to apply a style to the text. If the style implies that all text is displayed in upper case, it does not matter what happened before (upper case translated to proper case), since it will display all characters in upper case. In this case the importance is to understand the effect a style has on your labels. 

[deleted-user-sYHsW3p_gN5o]

Agreed, Xander, but I think Steve still has a point in that the help documentation ought to have a warning about this somewhere. Or maybe a link to a troubleshooting guide.

[SteveCole]

Exactly. I went back and re-read the help subject about this before replying. It just says:

Specify text for labels—ArcGIS Pro | ArcGIS Desktop    

Using an advanced label expression, you can add any Arcade, Python, VBScript, or JScript logic to your label expressions, including conditional logic and looping. For example, you could produce labels that have only the first letter of each word capitalized, regardless of how the text strings are stored in the attribute fields. You can also use label expressions to adjust the formatting of your labels using ArcGIS Pro formatting tags. These are special characters for changing the appearance of all or part of your labels. For example, you might use the bold formatting tag to make the first line bold in a stacked, multiline label.

I mean, adding the context that label expressions don't work on applied text cases seems like an important caveat to me, and one that would have saved me a lot of time wasted and frustration. ESRI has promoted Arcade as this miracle option to make all sorts of on-the-fly adjustments so why would I think otherwise that simply converting to proper case wouldn't work?

Gone are the days of ArcGIS 9.x level of documentation and I miss that.

[XanderBakker]

I understand the confusion and it would be very helpful if ArcGIS Pro would detect that there are conflicts between the Arcade expression and the Text Case applied in the Text Symbol (perhaps post this as an idea). It is however not the case that the Arcade expression does not work. IMHO it works correctly and the text is formatted properly and passed through the text symbol which formats it again to upper case. It is important to understand how both parts work together, this however, could be explained better in the help.