Layers

 

Layers display geographic information on a map. A layer doesn't store the actual geographic data; rather it references the data contained in geodatabases, coverages, shapefiles, raster datasets, grids, and so on, then defines how to display this geographic data. Some layers do not refer to geographic data. For example, a GroupLayer refers to other layers and a CompositeGraphicsLayer stores graphics.

 

Each different type of layer object represents different types of data. Examples of layer objects include FeatureLayer, GraphicsLayer, RasterLayer, TinLayer, CoverageAnnotationLayer, and GroupLayer. The Layers page of the Carto Object Model Diagram is a good place to start for an understanding of the different layer classes and the properties and methods that they support.

The following is a brief description of each layer component in the Carto library:

 

Layer	Description
CadAnnotationLayer	Displays CAD annotation
CadFeatureLayer	Displays CAD data as features
CadLayer	Displays CAD data as a CAD drawing
CompositeGraphicsLayer	A collection of graphics layers that behaves like a single layer
CoverageAnnotationLayer	Displays ArcInfo Workstation coverage annotation, PCArcInfo coverage annotation, or SDE3 annotation
DimensionLayer	Displays geodatabase dimension features
DummyGraduatedMarkerLayer	Displays graduated marker legend items in the style gallery
DummyLayer	Displays legend items in the style gallery
FDOGraphicsLayer	Displays geodatabase annotation features
FDOGraphicsSublayer	Displays annotation features in a subset of a geodatabase annotation feature class
FeatureLayer	Displays vector features, for example stored in geodatabase feature classes, shapefiles, and coverages
GdbRasterCatalogLayer	Displays raster catalog data stored in a geodatabase
GraphicsSubLayer	Graphic sublayer handed back by a CompositeGraphicsLayer
GroupLayer	A collection of layers that behaves like a single layer
IMSMapLayer	Displays IMS data
IMSSubFeatureLayer	A feature sublayer of an IMSMapLayer
IMSSubLayer	A sublayer of an IMSMapLayer
MapServerBasicSublayer	A basic MapServerLayer sublayer
MapServerFindSublayer	A MapServerLayer sublayer with Find capability
MapServerIdentifySublayer	A MapServerLayer sublayer with Identify capability
MapServerLayer	Displays ArcGIS Map Server data
MapServerQuerySublayer	A MapServerLayer sublayer with Find and Identify capability
NetworkLayer	Displays Network datasets
RasterCatalogLayer	Displays raster catalog data
RasterLayer	Displays raster data
TerrainLayer	Displays Terrain data
TinLayer	Displays TIN data
TopologyLayer	Displays a geodatabase topology as a layer
WMSGroupLayer	A group sublayer of a WMSMapLayer
WMSLayer	A sublayer of a WMSMapLayer
WMSMapLayer	Displays WMS services as layers

 

See How to add different types of layers to a map for an example of how to create and add layers for different data types.

The Map object manages a collection of layers. You can use the Layer or the Layers property on the IMap interface to get a reference to a layer. To determine the type of layer to which you have a reference, cast to specific interfaces. For example, if the layer object supports the ITinLayer interface, then you know it is a TinLayer object or a custom objecc that implements the interface. Layers can be persisted separately from maps in layer files (.lyr).  The LayerFile class provides capabilities for reading and writing .lyr files

Accessing a layer's underlying data

 

Depending on the type of layer you are working with, you use a different interface to access the layer's underlying data source. In some cases this interface is different for each type of layer, for example for a RasterLayer use IRasterLayer::Raster to access the underlying data for the layer. For layers the refer to feature data, you can use IGeoFeatureLayer::FeatureClass to access the underlying feature class for the layer. A GroupLayer has no direct data source, and instead it refers to other layers. Access these layers via ICompositeLayer.

 

See How to access a layer's underlying data for more information.

 

Conceptually, all layers inherit from an abstract class called Layer. The Layer class implements several interfaces: ILayer, IGeoDataset, ILayerGeneralProperties, IPublishLayer, IPersist, and IPersistStream.  You can see this abstract class on the Layers page of the Carto Object Model Diagram

 

The ILayer interface has a method to draw the layer and properties to define the extent of the layer, the minimum and maximum display scale, the spatial reference, the name, the supported draw phases, and the map tip text. There are also properties that indicate whether the layer is visible, valid, or cached, and whether or not the layer shows map tips. The Cached property indicates whether the layer requires its own display cache or not. If Cached is set to True, the Map will give a separate display cache to the layer so it can be refreshed independently of all other layers. A tracking layer is a good example of a custom layer that would set the Cached property to True because it may require refreshes more frequently than the rest of the map. Note that the SpatialReference property is used only for the map display; it does not change the spatial reference of the underlying data. It carries the Map object’s knowledge of the current on-the-fly projection back to the feature layer.

 

The IGeoDataset interface specifies the extent and spatial reference of the underlying data. The SpatialReference property on IGeoDataset is read-only. The property is used to set the spatial reference of the Map; the Map’s spatial reference is automatically set to the spatial reference of the first layer loaded.

 

ILayerGeneralProperties provides access to a text description for the layer and also properties for the previous maximum and minimum visibility scales for the layer. IPublishLayer provides access to properties and methods for publishing the layer using the ArcGIS Publisher extension. The persistence interfaces allow a layer to be saved and loaded from disk as part of a .lyr or .mxd file.

You can write a custom layer to support an unsupported data type in ArcGIS, or to change how a supported data type draws and behaves in ArcGIS Engine applications. 

The ArcGIS renderer classes and interfaces are found mainly in the Carto library. Renderers are objects that store symbolization for ArcGIS data layers and draw these data based on the stored symbolization rules. Layer classes and interfaces are also mainly in the Carto library. The renderer objects are divided into three main groups: Feature renderers--objects that render feature data, raster renderers--objects that render raster data, and TIN renderers--objects that render 3D TIN data.

 

Renderers are assigned to layers using different interfaces depending on whether you are working with feature, raster, or TIN data. See the sections covering the different renderer groups below for details. After changing a layer's renderer properties, or after assigning a new renderer to a layer, be sure to update the display by performing a partial refresh of the display.

Most renderers store symbol objects and use these to draw layers. Symbol classes and interfaces are mainly in the Display library. To assign or retrieve a renderer's symbols, use the specific interface for your particular renderer. For example, if you are working with a ClassBreaksRenderer, then use IClassBreaksRenderer::Symbol, for a RasterUniqueValueRenderer use IRasterUniqueValueRenderer::Symbol, or for a TinElevationRenderer use ITinColorRampRenderer::Symbol. See the sections covering the different renderer groups below for details.

Feature Renderers

 

Feature renderers are used to symbolize feature layers. A number of different feature renderer classes are available.  The following table lists the different feature renderer types and what they are used for along with a simple picture showing the renderer in use.

 

SimpleRenderer	Each feature in the layer is symbolized with the same symbol
UniqueValueRenderer	Features are drawn with different symbols depending on the unique values of one or more attribute fields
ClassBreaksRenderer	Features are drawn with graduated color (choropleth) or graduated size symbolization based on values in an attribute field. The data value range is divided into classes, each feature having membership in only one of these classes based on its attribute value. Features are drawn with the symbol corresponding to their class
ProportionalSymbolRenderer	Features are drawn with proportionally sized symbols based on values in an attribute field
DotDensityRenderer	Polygon features are drawn with randomly placed dots where the dot count for each feature represents the value of an attribute field
ChartRenderer	Features are drawn with pie, bar, and stacked bar charts. Chart content is based on values stored in one or more attribute fields
BiUniqueValueRenderer	Features are drawn with a symbolization that is a combination of a UniqueValueRenderer and a ClassBreaksRenderer. Values from separate, orthogonal attribute fields generate a single symbolization based on these two components
RepresentationRenderer	A renderer that draws features using representation information stored in the layer’s data source.
ScaleDependentRenderer	This is a renderer that is composed of multiple renderers, each operates only within a particular scale range

 

Accessing feature renderers

Each feature layer is assigned only one feature renderer. To get a feature renderer object from a layer, use IGeoFeatureLayer::Renderer. To set a renderer to a layer use the same property. For more information on how modify and set FeatureRenderers, see How to define a renderer for your layer.

Conceptually, all feature renderer classes inherit from an abstract class FeatureRenderer. Developers can implement their own feature renderer by implementing all of the interfaces implemented by this class.  You can see this abstract class on the Layers page of the Carto Object Model Diagram

 

FeatureRenderer implements IFeatureRenderer which provides access to properties and methods common to all feature renderers. This base class also implements persistence interfaces that allow feature renderers to be saved and loaded from disk as part of .lyr and .mxd files. All feature renderers should also implement ILegendInfo which provides access to a renderer's legend information and symbols. All ESRI feature renderers have at least one LegendGroup which in turn has at least one LegendClass.

 

Though feature renderers typically store all of the symbols they use to draw features in their LegendClass objects, it is best to access these symbols via the specific renderer interface for the renderer object you are using. For example, for a ClassBreaksRenderer use IClassBreaksRenderer::Symbol, or for a ProportionalSymbolRenderer use IProportionalSymbolRenderer::MinSymbol and IProportionalSymbolRenderer::BackgroundSymbol. Also note that though ILegendInfo is also implemented by most layer classes, layers typically defer all methods and properties to the renderer's implementation.

Raster renderers are used to symbolize raster layers. A number of different raster renderer classes are available.  The following table displays a list of the raster renderer types along with an explanation of their usage.

 

RasterClassifyColorRampRenderer	Pixels are drawn with graduated color symbolization based on their value. The data value range is divided into classes, each pixel having membership in only one of these classes based on its value. Pixels are drawn with the color corresponding to their class
RasterColormapRenderer	The raster layer is drawn based on a color map
RasterRGBRenderer	This renderer is for drawing raster layers in true-color RGB. The renderer draws three bands of a raster dataset, one for each of the red, green, and blue channels
RasterStretchColorRampRenderer	This renderer is for rasters with continuous values. The raster layer is drawn using a color ramp stretched across these values
RasterUniqueValueRenderer	Pixels are drawn with a different color for each unique value in the raster layer

 

For more information on how to setup raster renderering, see these topics:

How to create a raster classify renderer

How to create a raster stretch renderer

How to create a raster unique value renderer

All raster renderer classes conceptually inherit from an abstract class RasterRenderer. Developers can implement their own raster renderer by implementing all of the interfaces implemented by this class.

 

RasterRenderer implements IRasterRenderer which provides access to properties and methods common to all raster renderers. This base class also implements persistence interfaces that allow raster renderers to be saved and loaded from disk as part of .lyr and .mxd files. Raster renderers implement ILegendInfo which provides access to a renderer's legend information and symbols. ESRI raster renderers typically store the symbols they use to draw raster data in LegendClass objects which can be accessed via ILegendInfo. However, when writing client code that works with a raster renderer, it is best practice to access and change a renderer's symbols using the interface specific to the renderer you are using. For example, if working with a RasterUniqueValueRenderer use IRasterUniqueValueRenderer::Symbol, or if you are using a RasterStretchColorRampRenderer, use IRasterStretchColorRampRenderer::ColorRamp. Also note that though ILegendInfo is also implemented by most layer classes, layers typically defer all methods and properties to the renderer's implementation. All raster renderers also expose display properties and methods through IDisplayAdmin and IRasterDisplayProps.

 

TIN renderers are used to symbolize TIN and Terrain layers. A number of different TIN renderer classes are available. Unlike raster and feature layers and renderers, each TIN or Terrain layer can be symbolized by more than one of these objects at the same time. The ESRI TIN renderer objects are divided into renderers that symbolize nodes, edges, and faces.

 

TerrainDirtyAreaRenderer	Draws Terrain Dirty Areas (specific to Terrain layers)
TinNodeValueRenderer	Draws TIN nodes to show node values
TinNodeRenderer	Draws TIN nodes
TinNodeElevationRenderer	Draws TIN nodes to show elevation
TinEdgeRenderer	Draws TIN edges
TinBreaklineRenderer	Draws TIN edges to show breaklines
TinFaceRenderer	Draws TIN faces
TinFaceValueRenderer	Draws TINs with their face value
TinElevationRenderer	Draws TIN faces to show elevation
TinSlopeRenderer	Draws TIN faces to show slope
TinAspectRenderer	Draws TIN faces to show aspect

 

Accessing TIN renderers

A TinLayer keeps a collection of TIN renderers, and you can access these using ITinLayer.  For TerrainLayers, use the ITerrainLayer interface.  You can add multiple renderers, even of the same general type -- node, edge, and face -- to a TIN or Terrain layer's renderer collection. However, when two ore more renderers of the same type are added, there can be a conflict, and it is the order in which you add your renderers that resolves this conflict.

 

TinRenderer abstract class

All TIN renderer classes conceptually inherit from an abstract class TinRenderer.  You can see this abstract class on the Renderers page of the Carto Object Model Library. Developers can implement their own TIN renderer by implementing all of the interfaces implemented by this class.

 

TinRenderer implements ITinRenderer which provides access to properties and methods common to all TIN renderers. This base class also implements persistence interfaces that allow TIN renderers to be saved and loaded from disk as part of .lyr and .mxd files. TIN renderers also implement ILegendInfo which provides access to a renderer's legend information and symbols. ESRI TIN renderers typically store the symbols they use to draw TIN data in LegendClass objects which can be accessed via ILegendInfo. However, when writing client code that works with a TIN renderer, it is best practice to access and change a renderer's symbols using the interface specific to the renderer you are using. For example, if working with a TinNodeValueRenderer use ITinUniqueValueRenderer, or if you are working with a TinSlopeRenderer, then use ITinColorRampRenderer::Symbol. Also note that though ILegendInfo is also implemented by most layer classes and layers typically defer all methods and properties to the renderer's implementation.