Drop Support for Multi-class Annotation

[JustinSmith9]

Currently, Annotation may be single-class or it may have many annotation classes contained within a single annotation feature class. The former is fine but the latter is not when you consider the following:

1. Annotation with multiple subclasses is not supported for feature services.
2. If you publish them despite the incompatibility warnings, the performance will be poor
3. If you publish to Enterprise, the ArcGIS Server will log thousands of errors about the incompatible layers every day.
4. There is no real advantage to having all that anno jammed into one feature class versus having individual single-class annotation features within a feature dataset.
5. They are harder to deal with in many ETL and/or sharing situations than single-class features are.
6. Holistically, the ESRI data formats should work well, throughout the ecosystem, not just in Pro.

So the Idea is to to deprecate multi-class annotation feature classes entirely and perpetuate only single-class annotation, ensuring the anno feature classes are supported throughout the whole ecosystem. (A rare idea to simplify something, rather than add something more)

[CraigWilliams]

We have no plans to deprecate / drop annotation subclasses. They are the foundation of many workflows where different feature types need different annotation handling. There are also several misconceptions in the post. Multiple annotation classes are supported in feature services, have no effect on drawing performance vs. a single annotation subclass, and are significantly faster than multiple feature classes from a rendering perspective due to a reduction in cursor creation.

ETL experiences are going to be highly dependent on how varied the data you're merging and don't significantly change with respect to multiple classes when dealing with symbol differences.

The log issue is due to the sublayer not being supported as an individual layer end point. Reducing the log impact is something we will look at.

[RTPL_AU]

Here to support keeping multi-class annotation. 

[SStopyak_BruceHarris]

Just going to drop this here...see image. Multi-class and/or anno FCs make the ArcGIS Server angry. It is a vector tile world and anno has no place in that either. I'm in favor of dropping anno altogether. Formats that only work in desktop apps is are kind of useless in my opinion. Anyway, ESRI should not claim anno in branch versioned feature services is supported when the ArcGIS Server clearly does not agree. The developer who made that warning had a reason(s).  I can tell you that some single-class anno will not produce this error below but some will, though I'm not sure why. Maybe the complexity of the symbol. Multi-class always produces the error. Here is an idea. ESRI, can you enlighten us as to what is supported and what isn't? Maybe put together a LGIM-ish schema that is known to work with branch versioning, error-free?

#ScottOppmann

[RTPL_AU]

Mmm.

There are many things that don't work in all the tools across the entire Esri stack.
If we start removing all those features we may end up with MapInfo......... 

I'm a bit confused - Why allow Server & Annotations to interact?  Is it a case of not having users doing things correctly (training?)  or inheriting other company or department data / workflows (better contract specs)?

In Pro, where the Annotation creation processes is a bit convoluted, you have to do some very deliberate things to have annotations appear in your database. Would the easy option not be to avoid clicking the buttons? Pretend it is the Metadata editing button...  🤣

I use Annotations a lot for static map publications (not everything is web-based) so it is a very core feature in my world.