In this topic
- About feature renderers
- Custom feature renderer examples
- Alternatives to implementing custom feature renderers
About feature renderers
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 meet your requirements and you want complete control over the way features are drawn, you can implement your own custom feature renderer.
Custom feature renderer examples
The first example shows how custom feature renderers produce bivariate representations of a feature layer that go beyond the functionality of the standard biunique value renderer. In the following illustration, state capitals are symbolized by population and elevation above sea level (bivariate renderers):
The following illustration shows measures or z-values at vertices of a line layer (MZ renderer):
The following illustration shows slivers between polygons with a special symbol (sliver polygon renderer):
The following illustrates symbolized network junctions with the number of network edges that meet at the junction (valence renderer):
Alternatives to implementing custom feature renderers
This section describes some of the alternatives to implementing a custom feature renderer.
- 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 user interface (UI).
It's important to have a strong working knowledge of the ArcGIS 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.
Confirm that your project cannot be completed using existing renderers and symbol properties before implementing a custom renderer.
- When the data you need to symbolize does not have an attribute that specifically meets your symbolization needs, consider adding a new attribute and calculating or programmatically deriving values. For example, consider the four-color map problem. It would be too slow if the renderer had to determine the color to use to draw each feature every time the map was drawn.
If complex symbology requirements only need to be calculated once, adding a symbology attribute to the data can be much more efficient than a custom renderer.
- By creating a new field and calculating its values, the need for a custom renderer is eliminated because the standard unique values renderer can now be used on the new field. This allows the map to render the data as quickly as possible.
A map 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 can be an alternative to a custom feature renderer. In particular, a custom layer provides more complete control over the map UI. A custom renderer can 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 do not work. In this case, it may be more appropriate to implement a custom layer.
The ILayer.Draw method provides control over how the layer displays. Custom layers are generally more complex to implement than custom renderers. For more information about custom layers, see Creating custom layers.
Custom layers provide more control over the map UI than custom renderers.
- You may want to create derived feature classes to symbolize your data. These feature classes can be the result of geoprocessing the data to deconstruct shapes or generalize them 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 can maintain the derived features by implementing an editor extension or feature class extension that responds to edit events on the base feature class by editing the derived features.
See Also:
Sample: Multivariate rendererManaging custom feature renderers
| Development licensing | Deployment licensing |
|---|---|
| ArcView | ArcView |
| ArcEditor | ArcEditor |
| ArcInfo | ArcInfo |
| Engine Developer Kit | Engine Runtime |