Ask A Cartographer

Symbol collections in anntotation feature classes and text symbols in a style

February 05 2008 | 0 comments
Categories: Data Modeling, Map Data, Symbology

In an old ArcInfo Workstation coverage-based set-up we have a lot of annotations, whose appearance are controlled by a symbol-id pointing to a textset file. We are now converting these into geodatabase annotations, and would like to have the same centralized control.

Styles must be the tool for this(?) What we are looking for, is a functionality like "Match to symbols in a style" when assigning colors to polygons. Does it exist?

Annotations have their own "symbol collection", that does some of the job, but it is only for a single feature class.

We could write a VBA-script, that loaded the old textset into text symbols in a style, and another script to transfer the relevant text symbols into the symbol collection of an annotation feature class, and update the symbol_id in accordance with this. But there may be an easier way?

Am I right, when I accuse ESRI for poor co-ordination of styles and annotation?

Mapping Center Answer:

Well, let’s start with giving you the help topics that will give you the details, though what I explain next will give you something of a conceptual framework, relative to how you asked this question:

Importing coverage or CAD annotation into geodatabase annotation

Managing annotation feature class properties

The workhorse for this task is the Import coverage annotation tool.

The geodatabase annotation feature class has an attribute called AnnotationClass ID. When there is more than on annotation class defined for the annotation feature class, this field automatically becomes the subtype for the annotation feature class. The values in AnnotationClassID field correspond to the annotation classes defined in your annotation feature class. Each annotation class contains not only the symbol definition, but also the label placement rule (which gets applied when you add new features). Thus all the symbology rules are stored in the geodatabase annotation feature class.

If you don’t already have a populated geodatabase annotation feature class, I would suggest making one, just to get a good look at its properties. Create a couple of label classes and convert that layer's labels to annotation in order to also have this example show the subtypes. In ArcCatalog, double-click the annotation feature class to open its properties and look at the fields tab to find the AnnotationClassID field, then look at the Annotation Classes tab to see the classes.

To address one of your concerns, there is a sort of de-facto style in each annotation feature class. This starts with the Annotation class list, which is roughly equivalent to the labels folder in a style. It also inlcudes the symbol collection.

The intention of the symbol collection is to support efficient handling of exceptions when working with large annotation collections that are edited frequently. Symbols can be pre-defined here and used to make those edits efficient from a data management perspective. The idea is based on the fact that when you edit annotation in ArcMap and make a small change to the symbol, that entire symbol is being stored, as an exception, in the geodatabase (in your annotation feature class) — to the tune of one symbol for each edit. To put it succinctly, these edits can add up fast. These show in the symbol collection which you can manage in ArcCatalog and you can use the SymbolID field in the annotation feature class to reference a symbol in this symbol collection to efficient handle exceptions to your annotation class label rules.

You can set use label rules and symbols from existing styles when editing an annotation feature class’s properties in ArcCatalog, so there is no lesser coordination with styles for annotation as you were worried about.

You shouldn’t need to write any VBA or VB code to do this work. The help topics above give some advice about when to manage your coverage annotation’s pseudo items in support of the conversion process. If you’ve got lots of coverage annotation, I would recommend using the geoprocessing scripting or modeling environment to handle the automation.

You can Field Calculator while editing (in fact you must be editing) to update the SymbolID or AnnotationClassID fields. You must be editing because when the Editor commits these features to your database, update events are triggered to synchronize the values of the other fields in your annotation features. I mention this because in preparing to import your coverage data, you may, as suggested in the above help topics 'front load' the work and set attributes in your coverage annotation that will be used to drive attributes in the geodatabase annotation features. However, getting this large scenario right the first time is challenging, and sometimes its easier to fix the last few things after the fact.

Good luck.

If you would like to post a comment, please login.

Contact Us | Legal | Privacy |