Skip To Content

Layer Types

In this topic

Different layer types are used to draw different data types. Generally, the layers in a map can be categorized as either basemap, operational, or graphics layers. The functionality and performance may differ, depending on the characteristics of the data and how it is accessed and displayed in an app.

See Maps and layers to learn more about choosing how to build maps from layers.

Choosing layer types

Most layers display content from GIS server web services, such as ArcGIS for Server services, Bing Maps, Open Street Map, or WMS services.

One kind of service is known as a map service. Map services fall into two broad categories: dynamic or tiled. Dynamic map services return map images created on-the-fly when requested by a client. Tiled map services provide pre-generated images based on some tiling scheme, and the layer assembles these tiles in the client app. Another kind of service is known as a feature service. ArcGIS for Server feature services return sets of features from a single layer as a response.

Other layers display different types of content. A graphics layer does not rely on a web service for its content. Specialized layers are also available for working with data sources such as Web Map Services (WMS) information, and KML.

The sections below suggest the typical classes to use for your basemap, operational, and graphics layers. However, these are not absolute rules, and the choice of class should be based on an understanding of the characteristics of each type. Some examples of exceptions are discussed in the sections below.

A wide variety of layer classes are provided by the API. Each can be used to display a specific data type, and each has its own functionality and performance characteristics. Generally, each layer class is used for a particular layer type—basemap, operational, or graphics.

Layer types

Common layer properties

All layer types inherit from a common Layer class, which allows certain properties to be queried or changed for any layer type.

  • Get the layer's full extent, using the FullExtent property.
  • Determine what spatial reference is used by the layer, using the DefaultSpatialReference property.
  • Hide and show the layer, using the IsVisible property.
  • Control how transparent or opaque a layer is, using the Opacity property.
  • Change the visible layer's scale range thresholds, using the MinScale and MaxScale properties.

Basemap layers

Basemap data is typically provisioned as a tiled map layer. Different classes are used to create basemap layers, depending on the displayed data.

If your basemap must be used in maps with a wide variety of different spatial references, or changes frequently, or is used infrequently, it may be more appropriate to publish data as a dynamic map service. Additionally, if your operational data changes infrequently and is used by a large amount of users, it may be more appropriate to publish it as a tiled map service.

Tiled service layers

API classes: ArcGISTiledMapServiceLayer, BingLayer, WebTiledLayer, WmtsLayer—Tiled map service layers are connected to cached map services (from ArcGIS for Server, an OpenGIS Web Map Tile Service implementation, OpenStreetMap, or Bing), which provide map images at predefined scales in a tiling scheme. The tiling scheme is set by the server. The map image tiles are raster (also called bitmap) images drawn on the map view and arranged into their tiling scheme by the client API. These services can contain multiple sublayers.

Functional characteristics

Because each tile image already exists on the server, it is not possible to change the visibility of the individual layers or the service's default spatial reference of the map (they can be considered as static map services). In addition, the data cannot change over time unless the cache is refreshed. Tiled service layers cannot be queried.

Performance characteristics

Tiled map services are some of the fastest map services available in the runtime. Map images are pre-created and cached by the server, and returned from the server very quickly. Multiple images are usually returned for a single map extent. Requests are made on multiple threads and the responses are handled asynchronously (tiles are requested and drawn individually from one another). This approach results in many small requests to the server and little client-side processing to draw the returned images. The size of each returned image increases as the resolution or complexity of the images increase. For example, high-resolution imagery tiles are larger in file size than topographic mapping for the same area and map extent.

Offline tiled layers

API classes ArcGISLocalTiledLayer — A cache of tiles can be downloaded from the server to the client device and displayed as a layer in an app, without the need to remain connected to the service. The cache can be downloaded as a single Tile Package (TPK ) file, or as an ArcGIS Compact Cache, or can be created using ArcGIS for Desktop and directly provisioned to the device. Learn more about creating offline maps.

Functional and performance characteristics

Local tiled layers display even faster than tiled service layers, as no network calls are required to retrieve the image tiles. However, data must be prepared in advance by being generated and downloaded to the device over the network, or by provisioning the generated files directly to the device file storage. Other functional and performance characteristics are similar to that of tiled service layers.

Operational layers

Operational data is typically provisioned as a feature service, or as a dynamic map service. The choice of service type depends on what functionality and performance characteristics are required for the layers. If editing is required, use feature services; however, if complex rendering is required, dynamic map services may be more appropriate. More differences are highlighted below.

If your operational data does not require editing, changes infrequently, and is used by a very large amount of users, it may be more appropriate to publish it as a tiled map service. Conversely, if you have a basemap that must be used in maps with a wide variety of different spatial references, or changes frequently, or is used infrequently, it may be more appropriate to publish data as a dynamic map service.

Feature layers

Feature layers display data from feature services. Feature layers can be used to display, select, and query features in a layer. Use feature layers to edit geometry, attributes, and attachments, if the underlying feature service supports editing.

Features can be retrieved from the server as the app is used, or alternatively downloaded when the device is connected, and cached locally for use when the device is offline. Choosing the most appropriate API option enables your app to provide the workflows required, and allows it to adapt to the requirements of the situation. See the sections below for more information on the different options available.


API classes: ServiceFeatureTable, FeatureLayer—The geometry, attributes, and attachments of features from a feature service are temporarily cached in a table on the client. The feature layer uses this table to draw the features natively in the map, based on the map extent. New features are retrieved automatically when you navigate the map. Changes to features already cached in the app are not retrieved from the server table unless the layer is specifically refreshed. The local table cache is discarded when the layer is disposed.

Create and initialize a ServiceFeatureTable, then create a FeatureLayer by passing in the ServiceFeatureTable to the constructor, and add the FeatureLayer to the map. The ServiceFeatureTable class is a subtype of ArcGISFeatureTable, which is an abstract base class for online and offline feature tables.


API classes: GeodatabaseFeatureTable, FeatureLayer—A local cache of a feature service can be downloaded from ArcGIS for Server and displayed as a layer in your app, without the need to remain connected to the service. Features are downloaded to a local geodatabase file, using the GeodatabaseSyncTask.

Create and initialize a GeodatabaseFeatureTable, and create a FeatureLayer by passing in the GeodatabaseFeatureTable to the constructor, then add the FeatureLayer to the map. Learn more about creating offline maps.

Functional characteristics

As the feature attribute, geometry, and attachment information is cached locally, individual features in these layers can be queried and filtered based on spatial queries or text-based WHERE clauses. If the layer is created from an editable ArcGIS for Server feature service, the feature layer can be edited, and edits pushed to the service when required.

If the feature service the layer was originally created from supports syncing, edits made to the features in an offline layer can be uploaded to the service, and updates from the service can be synced to the client app.

Performance characteristics

As full feature information is cached locally, and features are drawn natively, this layer type offers excellent performance of display when zooming and panning the map, within the extent of cached features. Querying such features is also efficient, enabling app functions such as providing real-time updates of query results in a map. This performance comes at a slight cost of initial display speed when the layer is first created from the service, as the local feature cache must be built. Additionally, app memory increases with the number and complexity of the features cached.

Offline feature layers may display faster than online feature service layers, as no network calls are required to retrieve the feature information. Additionally, querying and filtering is equally efficient. The cache must be initially created, which requires server-side processing time, and the download to the device may require extensive network usage and subsequent local device storage. Network usage can be eliminated by provisioning the cache directly to the device in advance, by creating the cache using a desktop computer and copying it to the device internal memory (or expandable memory cards if your device supports this).

Dynamic map service layers

API classes: ArcGISDynamicMapServiceLayer, ArcGISImageServiceLayer, WmsLayer, GpResultImageLayer—A dynamic map service can contain multiple layers, rendered by the server each time a request is made, and returned to the client as a single raster image. The image does not contain any additional information about the features in the map. Dynamic map layers are connected to ArcGIS for Server dynamic map services.

Functional characteristics

Since map images are drawn by the server on every request, if your data changes, those changes are seen as soon as a new map image is requested. In addition, the visibility of individual map layers can be changed, and the data shown can be filtered by adding individual layer definition expressions. The spatial reference of this layer type can be changed from the service's default, and ArcGIS for Server re-projects each image on-the-fly to the requested output spatial reference (that of the map).

The API does not include specific methods to query individual dynamic map service layers. However, the layer's end point URL can be used by a find task, identify task, query task, or used to create a separate queryable feature layer.

Performance characteristics

For every map request, ArcGIS for Server creates a map image on-the-fly. Consequently, the server rendering time depends on the amount and complexity of the data in the map. However, if the map service is well optimized, this should result in a relatively quick response to the client, but will typically be longer than responses for an equivalent tiled map service layer. The file size of the returned map image also depends on the data in the map. As the server response is an image, this can be drawn quickly as it requires little client-side processing.

Dynamic map service layers are good candidates for showing features that change periodically over time, or that require some sort of filtering by the user, as long as the feature information (attributes, geometry, or symbol) is not required in the client. They are often used in conjunction with a feature layer in selection mode to show the latest map data without having to pull all of the feature information from the server (as with feature layers) on every map request.

Graphics layers

API classes: GraphicsLayer—Graphics layers can be used to display information that is not covered by the other types of layer above. Graphics are defined in memory in your app, based on user actions, resulting from an operation, or converted from the information in an external information feed. Graphics in a graphics layer can contain geometry and attribute information, and can draw graphics using individual symbols or a layer-based renderer. Like features in a feature layer, each graphic draws natively in the map.

Feature layers share a little functionality with graphics layers. For more information about when to use feature layers versus graphics layers, see Features and graphics.

Functional characteristics

As a graphic contains geometry and attribute information, you can display information about the graphics. For example, you can show pop-ups for graphics in a graphics layer. You can also find graphics using screen coordinates HitTestAsync method, in repsonse to user action events on the map. The graphics layer is responsible for drawing graphics on the map in spatial coordinates. It is not designed for drawing non-geographical marginalia such as north arrows or copyright text.

Performance characteristics

It is not recommended to add too many graphics to the graphics layer, as they are held in the device memory. If you're working with a lot of features (thousands), it may be more appropriate to put these into a feature layer, by creating a feature service.

Graphics layers are designed to best perform when graphics change location regularly, with optimal animation of the features upon zooming in and out on the map. It is possible to change the default rendering mode of a graphics layer to instead be optimized to draw greater numbers of features added to the layer in batches. Layers with the same rendering mode should be grouped together.

3D layers

In general, you work with layers in 3D (added to a Scene control, in other words) the same way you work with them in 2D (added to a Map). All of the layer types that are supported for display in a Map can also be used in a Scene. Just like those included in a Map, layers can be added to a Scene at design time using XAML or at runtime using code, and are drawn in the order in which they are added. Elevation values for 3D visualization are applied to layers using an elevation source defined on the Scene control.

With the 10.3 release of ArcGIS for Server, scene services are now available for delivering 3D content. They support publishing and consuming large volumes of multipatch features, such as buildings for entire cityscapes. Scene services are created by publishing a scene using ArcGIS Pro. These services can be consumed in your ArcGIS Runtime app using a SceneLayer.

The GraphicsLayer and GraphicsOverlay classes provide a SceneProperties property to define behavior when rendering graphics in a scene. The property is set with a LayerSceneProperties object that defines the SurfacePlacement setting to control how graphics display relative to the scene's elevation source. When displaying in a map, SceneProperties for graphics are ignored.

Feature services may provide z-coordinate values for feature geometry, but these values are not used when displaying a feature layer in a scene. As a workaround, query the feature service (with ReturnZ = true) and add the results to a graphics layer with the appropriate surface placement. The following example queries a z-enabled feature service then displays the graphics in a scene.

// query for all graphics in the feature service, include z-coordinate values
var queryTask = new QueryTask(new Uri(""));
var query = new Query("1=1");
query.ReturnZ = true;
var result = await queryTask.ExecuteAsync(query);

// create a graphics layer to show the graphics using absolute placement using the z values
var graphicsLayer = new GraphicsLayer();
graphicsLayer.SceneProperties.SurfacePlacement = SurfacePlacement.Absolute;

// build graphics from the results, symbolize with a red line
var lineSym = new SimpleLineSymbol { Color = Colors.Red, Style = SimpleLineStyle.Solid, Width = 5 };
graphicsLayer.GraphicsSource = from f in result.FeatureSet.Features select new Graphic(f.Geometry, lineSym);

// add the layer to the scene

See the Add layers to your Scene topic for more information about working with layers in 3D.

Kml layers

Keyhole Markup Language (KML) is an XML format for describing geographic features for visualization in two dimensions (in a Map) or three dimensions (in a Scene). A KML document defines a set of geographic features using coordinates of latitude, longitude, and elevation. Rendering information describes how features are symbolized, and may reference local resources, such as image files. Additional information can define a time component for the data or three dimensional visualization properties such as pitch, heading, and elevation to describe a camera position.

A KML file can contain one or more network links, which simply point to another KML file. The referenced file can be updated and maintained seperately, ensuring that the user sees the most current version of the data. Network links can be set to refresh their data based on a time interval or when the user interacts with the display, making them especially useful for displaying dynamic data.

The following network link is included in the KML file at and is used to display earthquakes from the USGS website. The data in the layer will be refreshed every 300 seconds (five minutes).

  <name>USGS Magnitude 1.0+ Earthquakes, Past Week</name>
  <Snippet maxLines="1">Updates every 5 minutes</Snippet>

KML files use a .kml extension for plain KML text files or .kmz for compressed files, which contain a KML file (called "doc.kml" by convention) and optionally includes subfolders containing resources referenced by the file, such as images, icons, or 3D models used to display the features. In your ArcGIS Runtime apps, you can use KmlLayer to read and display geographic information from a .kml or .kmz file, either stored locally or accessed from an online source.

The following example adds a layer from a KML file hosted by the USGS showing recent earthquakes. This KML file contains the network link shown in the previous example, and will cause the layer to update every five minutes.

// create a KML layer from an online file
var sourceUri = new Uri("");
var kmlLayer = new KmlLayer(sourceUri);

// Add the kml layer to the map

KML layer showing recent earthquakes

Loading large KML datasets can be memory intensive and may cause crashes on low memory devices. If your app requires working with KML datasets that contain large amounts of data, consider disabling support for low-memory phones.

In 2008, KML became an international standard of the Open Geospatial Consortium (OGC). The specification for the current version, which is 2.2, can be found on the OGC Website. The standard also provides a mechanism for extensions, which allows the addition of elements beyond the scope of the standard. Google, for example, provides several extensions to the KML standard that are described in the Google Developers KML Reference. If an extension is not supported by a client, it is silently ignored and the rest of the document is loaded. This allows a new client to support additional functionality from an extension without breaking support for existing clients.

ArcGIS Runtime SDK for .NET is targeting support for KML version 2.2 and some extensions. The following lists some of the functionality, either from the KML 2.2 specification or Google extensions, that you won't yet find in the ArcGIS Runtime KML implementation.

Specialized layers

Several specialized layer types are available to provide geographic information from a variety of formats, including Bing, Open Street Map, and Web Map Service (WMS). The following layer classes are available to support the use of specialized types of data in a map.

  • WMS—Web Map Service layers allow you to add Open Geospatial Consortium (OGC) WMS services to a map. These services are a type of dynamic map service, and may function as basemap or operational layers. The WmsLayer is used to add WMS services to a map.
  • Bing maps—Bing maps services can be added as layers in a map by using the specialist BingLayer class. These services are tiled map services that usually provide basemap layers for a map.
  • OpenStreetMap—Open StreetMap services can be added as layers in a map by using the specialist OpenStreetMapLayer class. These services are tiled map services that usually provide basemap layers for a map
  • Message groups—Message group layers display graphics with military symbols from one of the supported symbol dictionary types.
  • Group layers—Group layers are composed of a collection of other layers, and are used to represent datasets that are composed of many different layers.
Related topics