Direction Label Class Arcade VS Python

DeanAnderson2

I am starting to develop our label/annotation standards and want to follow a best practice. We will be converting our labels to annotation as part of this process (don't want to go into all the reasons for that here - but it is part of the business process). 

In the sample from the Parcel Fabric Class the Label Class for Direction uses Arcade.  There is a lengthy set of code to convert the direction to a standard looking DMS Bearing (ie. Convert  60.6055555555556 to N60°36'20"E) .  However if you use Python you can do the same thing with the expression [Direction].  So why not use Python instead of Arcade for this labeling process.   Given all the other rules I need to add it seems that starting simpler is better.  

jcarlson

On the desktop side, it could make sense to go that route. However, if the service is pulled into a web map, Python is not an option for defining label classes. Arcade remains compatible moving between Pro and web maps, which is likely why that comes in as the default.

The Arcade code in quesiton also includes quite a bit of other processes to check the COGO attributes of the line, not simply convert DD → DMS. Some of it certainly seems geared towards QC for the editor, being able to quickly see invalid COGO lines by their labels. I've re-written the Arcade code block myself, and can simplify it quite a bit if all you want is the labels themselves and none of the QC.

But then, if you're just getting your labels set up to convert to annos, cross-compatibility and validating your attribution isn't really an issue. I'm not familiar with the python expression, but as long as it's getting you legitimate quadrant bearings, that's probably what you want.