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.
Solved! Go to Solution.
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.
If python works then there is no need to use arcade. Python skills can be used outside of arc* products, arcade is limited to esri
I am much more familiar with Python so that is good with me.
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.
Josh summed it well - if you plan to use use it for web viewing or web editing in the next decade I would use Arcade which is compatible outside of Pro. Also be aware that Arcade will have a direction conversion in the near term (I am testing it now) so the label expression we currently have for COGO lines will be simplified a great deal.
Arcade or Python?
Yes 🙂
Both Python and Arcade have their place and purpose and there is no need to choose.
We saw value in investing the time to use Arcade for labeling over Python because 'Pro is just another client' when working in a service-oriented architecture and we are building it for the next 15-20 years.