ArcGIS Runtime SDK for .NET

Layers and tables

A layer displays geographic data in a map or scene. Maps and scenes are containers for layers and tables. A table is a source of data; geographic data in tables can be consumed by some types of layers. Runtime supports many types of layers.

Layers vary in their implementation styles and capabilities. For example, feature layers are conceptually tied to an underlying table; data from the table is symbolized by a renderer. ArcGIS map image layers and WMS layers show map images rendered by a server on demand. ArcGIS tiled layers and web tiled layers show tiles that were rendered ahead of time by the server. ENC layers show data from files in device storage.

Layers can have one of two roles in your map:

  • Basemap layers provide context for the information in your map. For example, the imagery or street map backgrounds on consumer mapping services are basemaps.
  • Operational layers contain the primary content of the map. For example, a layer with all of the gas stations nearby would be an operational layer.

Runtime layers can be used as operational or basemap layers; you have the flexibility to use layers in the way that makes sense for your app & cartography.

Layers define how information is displayed. They can consume data from tables, local files, or remote services. If you just need to put points on a map, or work with temporary data without an underlying model, consider using graphics.

Many layers can be shown in a map. You can control the draw order of layers as well as their visibility and opacity.

There are many layer types available. See Layer types described to learn about Runtime layers and how to choose the right layer types for your map.

Common layer properties

All layers support the following common properties:

  • Name — a human-readable name
  • Description — a human-readable description of the layer's content
  • Extent — the geographic area that contains the layer's content
  • Spatial reference — defines how coordinates should be interpreted. See Spatial references for more information.
  • Visibility — lets you hide or show the layer without removing it from the map.
  • Scale range — controls layer visibility based on how far the user has zoomed into the map using the MinScale and MaxScale properties.
  • Opacity

Note that layers vary significantly in their implementation styles and capabilities. Most layers have many more properties than are shown in the list above. See Layer types described for details

Choosing layers for your map

When it comes time to choose layer types for your app, ask yourself the following questions:

  • Do users need to compare data with a time component?
  • Do users have an always-on internet connection?
  • Do users need to be able to query, analyze, or select data?
  • Do users need to be able to edit layer content
  • Do you or your users need control over the style (colors, fill patterns, icons, etc.) of the layer?
  • Does your app need to interoperate with other systems or ArcGIS Portal?

Once you understand your requirements, consult the table in Layer types described to see which layers meet your needs.

Understanding your data is the first step in the 'Data, Design, Develop' pattern for creating ArcGIS apps. ArcGIS DevLabs will walk you through the process of bringing data for your apps into ArcGIS.

If you want to quickly visualize data that's available to your app, but don't want to store it in an ArcGIS portal or layer, consider using graphics.

Choosing basemap layers

The basemap is the foundation of your map; it provides context for your data and defines how your map looks. Choosing the right basemap can:

  • Align your map with your brand
  • Help tell your story
  • Make your map layers and graphics easier to see and understand
  • Make your app feel like a part of your user's Geographic Information System (GIS) when your app connects to portal

There are many attractive basemaps available on ArcGIS Online. If you're creating an editing or browsing exprience, your users may be accustomed to having certain basemaps available through their portal. You can get a list of featured basemaps in the user's ArcGIS portal.

It is also possible to publish your own basemaps or customize the style of the existing vector basemaps.

Time-aware layers

Although all layers support geographic information, time-aware layers support time information as well. When a layer supports time, you can:

  • Filter layer content based on time
  • Compare data over time using time offsets

For more information, see Visualize and compare data over time.

Image adjustment layers

Image adjustment layers allow you to change brightness, contrast, and gamma for imagery. See Layer types described for more information

Layer performance considerations

Vector & raster data

There are two main formats for the display and management of geographic data:

  • Vector — data is described by points, lines, and polygons (vectors). The client renders the vector content into raster images for display on the device.
  • Raster — data is transmitted via pre-rendered images; the client doesn't have information about the underlying features that were rendered into the image.

Because vector layers are rendered on device, they can always be perfectly suited to the size and resolution of the client display. Vector data is also very small, making it ideal for taking offline or use in low-bandwidth environments. Vectors are not suitable for representing data that comes from raster sources, like satellite imagery.

Some basemaps combine both raster and vector data. For example, the world imagery with streets (vector) basemap from ArcGIS Online uses a tiled raster layer for imagery and a vector layer for features and labels. This ensures that features and labels are always crisp while still showing raster imagery.

Dynamic and tiled layers

Services can take one of two approaches to providing their data:

  • Dynamic — Generate a map for each request based on information provided by the client, like desired image size & extent.
  • Tiled — Generate tiles ahead of time, then serve them as needed by the client.

Because dynamic maps are generated as needed, they are more appropriate for maps with data that changes often. The downside to dynamic maps is that they require more server resources – rendering map images is an expensive operation. For things that don’t change often, tiled services are more appropriate.


Tables provide a source of data that can be worked with directly, or perhaps displayed in a feature layer. Tables in ArcGIS define a schema for features – a consistent set of fields that features are expected to have. Tables can have many features. Entries in spatial tables can have geometries. Tables can come from several sources:

  • Shapefiles
  • Geopackages
  • Maps
  • Feature services
  • Geodatabases

Tables can be:

  • Queried
  • Edited (depending on the source)
  • Shown in a feature layer
  • Taken offline

Non-spatial tables

Non-spatial tables are just like other tables, except they don't have a geometry column. Because they don't have geometry, they can't be rendered in a layer. Although non-spatial tables can't be rendered, they can still be added to maps as data sources for querying. Features (entries) in spatial tables can be related to the features in non-spatial tables. Non-spatial tables are represented by the same Runtime types as spatial tables.

Table performance concepts

A table might have hundreds of thousands of features. How your app requests features from the table is a performance-critical decision.

When working with tables that come from a service (rather than a local file), feature request modes control how often features are retrieved and how they are cached. There are three feature request modes:

  • On interaction cache (default) — This mode is best for scenarios involving services with large amounts of infrequently edited data. This mode is recommended if you have an occasional or unreliable connection to the service. When the table is used in a layer in a map, features are requested for the visible extent (map area) and are cached locally. Features continue to be requested and cached as you navigate the map to other areas. Cached features are not requested again. Features can also be requested by querying or populating the table directly. Runtime chooses the optimal way to execute a query, either querying the local cache, or querying the service and importing the results into the local cache. For example, if a spatial query is executed for the current map extent, results are obtained from the local cache—this avoids re-fetching features from the service.
  • Manual cache — This mode is recommended when the data from the service is not expected to change frequently and when it is not critical for the client app to always have the most recent changes. The amount of data populated to the local cache from the service is expected to be small. The table's local cache can only be populated by calling the PopulateFromServiceAsync method of ServiceFeatureTable . Features are never requested automatically, and the cache is never populated based on map interaction.
  • On interaction, no cache — This mode is recommended if it is critical for your app to always be working with the latest data. This mode is not recommended if you have an occasional or unreliable connection to the service. When the table is used in a layer in a map, features are requested for the visible extent and are not cached locally. Features are requested from the server each time you navigate the map, regardless of whether the extent has been visited before. Queries are always executed against the server. Navigating the layer or querying the table both cause the local cache to be cleared and repopulated. Because all operations involve querying the server, an always-on service connection is required. Anticipate higher data usage than the other interaction modes.