A feature renderer is an object that is used to draw feature layers. There are several standard feature renderers, for example, the SimpleRenderer, the ClassBreaksRenderer and the DotDensityRenderer. If none of the standard renderers satisfy your requirements, and you want complete control over the way features are drawn, you may find it useful to implement your own custom feature renderer.

Custom feature renderers give you complete control over the way features are drawn. Note that this section covers custom feature renderers, but not raster renderers.

There are several samples of custom feature renderers in the ArcGIS Developer Help; try looking under Renderers in the index. As an indication of what custom renderers can do, some of the samples are shown below:

Produce bivariate representations of a feature layer that go beyond the functionality of the standard biunique value renderer. In the picture, state capitals are symbolized by population and elevation above sea level (Bivariate Renderers).

Show measures or z-values at vertices of a line layer (MZRenderer).

Show slivers between polygons with a special symbol (Sliver Polygon Renderer).

Symbolize network junctions with a count of how many network edges meet at the junction (Valence Renderer).

There are often alternatives to implementing a custom feature renderer. First, the existing standard renderers support a wide variety of ways to draw data. Many difficult drawing or symbology requirements can be achieved by manipulating the properties of a standard renderer with ArcObjects or the ArcGIS UI. Second, it pays to have a strong working knowledge of the ArcMap symbol model. Many problems can be addressed by using a symbol with its properties set in a specific way. In particular, multilayer symbols can produce many advanced effects.

Make sure the existing renderers and symbol properties cannot solve your problem before implementing a custom renderer.

When the data you need to symbolize does not have an attribute that specifically meets your symbolization needs, you should consider adding a new attribute and calculating or programmatically deriving values. For example, consider the four-color map problem (see the ArcGIS Developer Help for a sample). It would be too slow if the renderer was responsible for figuring out which color to draw each feature each time the map gets drawn.

Adding a symbology attribute to the data can be a lot more efficient than a custom renderer if complex symbology requirements only need to be calculated once.

By creating a new field, and calculating its values once and for all, the need for a custom renderer is eliminated because the standard unique values renderer can now be used on this new field. In fact, this allows ArcMap to render the data in the fastest way it possibly can. Incidentally, a useful tip is that ArcMap renders data based on an integer field faster than it would if the field were of a text data type. This is particularly true for ArcSDE geodatabases, since less data has to be interpreted and transferred over the network.

A custom layer may be an alternative to a custom feature renderer. In particular, a custom layer provides more complete control over the ArcMap user interface. A custom renderer may be incompatible with some of the standard user interface facilities for a layer. For example, if the renderer displays the features away from their true locations, the selection tools will not work correctly. In this case it may be more appropriate to implement a custom layer. Note that the ILayer::Draw method provides control over how the layer is displayed. Custom layers are generally a bigger undertaking to implement than custom renderers. For more about custom layers, see the section 'Creating Cartography'.

Custom layers provide more control over the ArcMap user interface than custom renderers.

A custom feature is another alternative to a custom renderer, though the renderer is nearly always a more efficient solution and also one that is easier to implement. Moreover, data based on custom features can be difficult to share as the implementation DLL becomes an integral part of the data. The IFeatureDraw interface on a custom feature provides control over how the feature is displayed. IFeatureDraw::Draw is called by the standard renderers for each feature. A disadvantage of implementing a custom feature like this is that you have less control over the drawing loop, and this may force you into redundant calculations. For more discussion, see the information on custom features in the section, 'Extending the Geodatabase'.

Custom features provide control over how features are drawn; however, they are normally less efficient and harder to implement than custom feature renderers.

With custom features, unlike custom renderers, the link between the feature and the behavior is stored in the geodatabase, not in map documents. A renderer can be forcibly linked in the geodatabase to a particular feature class by implementing a feature class extension. See the section 'Managing custom feature renderers' later in this section for more details.

You may want to create derived feature classes to symbolize your data. These feature classes may be the results of geoprocessing the data to deconstruct shapes or generalize shapes to the extent that they can be easily handled and drawn with the standard renderers. Effectively, you would be creating a cartographic database, where each base feature class can have one or more derived feature classes. For datasets that are regularly edited, you could maintain the derived features by implementing an editor extension, or feature class extension, which responds to edit events on the base feature class by editing the derived features.

 

---

Back to top

See Also Point Dispersal Renderer Example and Managing custom feature renderers.