A layer displays geographic data in a map or scene. See 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. ArcGIS Runtime supports many layer types. See Layer types described.
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 web map service (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 or scene:
- Basemap layers provide context for the information in your map or scene. For example, the imagery or street map backgrounds on consumer mapping services are basemaps.
- Operational layers contain the primary content of the map or scene. 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 and cartography.
Layers define how information is displayed. They can consume data from tables, local files, or remote services. If you only need to put points on a map, or work with temporary data without an underlying model, consider using graphics instead. See Features and graphics.
Many layers can be shown in a map or scene. You can control the draw-order of layers as well as their visibility and opacity. Operational layers may be added to a group layer to control their visibility as a group. See Group layer.
There are many layer types available. See Layer types described to learn about ArcGIS Runtime layers and how to choose the right layer types for your map or scene.
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 or scene.
- Scale range — controls layer visibility based on how far the user has zoomed into the map or scene using the MinScale and MaxScale properties.
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 or scene
When it comes time to choose layer types for your app, consider the requirements you established for how your app will work. Ask yourself the following questions:
- What information is your app designed to display or analyze? Does your app process or visualize two-dimensional (2D) or three-dimensional (3D) data or both? Some layer types are designed specifically to be sourced from with 3D data sources like elevation surfaces and point clouds, others are sourced with 2D data like rasters. Nevertheless, in many cases 2D or 3D data may be used in either a map or a scene.
- Do users need to compare data with a time component? Some layers are time-enabled, meaning that the content can be filtered using a time extent that depends on a date/time attribute in the layer.
- Do users have an always-on network connection? Without an always-on connection, some data is usually cached by the app or in the local file system.
- Do users need to be able to query, analyze or select data? This determines what attributes each features in the layer should have.
- Do users need to be able to edit layer content? This has an impact on the source of the layer's data, and the editing workflow.
- Do you or your users need control over the style (colors, fill patterns, icons, etc.) of the layer? Some layers allow changes to styling, others use only the styling provided by the layer's source.
- Does your app need to interoperate with other systems or ArcGIS Portal? This impacts your choice when layer data could come from different source types (such as ArcGIS Portal, services or local data) or will be shared out from your app to other systems or ArcGIS Portal.
After 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. See Features and graphics.
Choosing basemap layers
The basemap is the foundation of your map or scene; it provides context for your data and defines how your map or scene looks. Choosing the right basemap can:
- Align your map or scene 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 a portal
There are many attractive basemaps available on ArcGIS Online. If you're creating an editing or browsing experience, your users may be accustomed to having certain basemaps available through their portal. You can display a list of featured basemaps; see Get a list of featured basemaps.
It is also possible to publish your own basemaps and customize the style of the existing vector basemaps. See How to Customize Esri Vector Basemaps.
Although all layers support geographic information, time-aware layers display 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 let you 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 — Regenerate a map or scene for each request based on information provided by the client, like desired image size and extent.
- Tiled — Generate tiles ahead of time, then serve them as needed by the client.
Because dynamic maps and scenes are generated as needed, they are more appropriate for maps or scenes with data that changes often. The downside to dynamic maps or scenes 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:
- Maps or scene
- ArcGIS feature services
- WFS feature services
Tables can be:
- Edited (depending on the source)
- Shown in a feature layer
- Taken offline
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 or scenes as data sources for querying. Features (entries) in spatial tables can be related to the features in non-spatial tables. (See Relate features for information about associating features from different 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 an ArcGIS feature service or WFS (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 or scene, 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 or scene 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 populateFromServiceAsync. 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 or scene, 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.
WFS feature tables only support manual cache feature request mode. On interaction cache is the default so WFS feature tables must be set to use manual cache before attempting to load features.