A layer displays geographic data in a map; it allows your users to visualize, explore, analyze, query, and edit geographic data. In general, a layer's data comes from a single source, such as a map service URL or a geodatabase file.
One layer type, a feature layer, may use an associated renderer to symbolize data and might also define properties for the display of things like labels and pop-ups. This decoupling of the layer's data and how it's rendered gives you the flexibility to present the same data in a variety of ways. As the name indicates, layers are stacked or "layered" in a map and drawn from bottom to top. As a developer, you can control the order of layers in a map as well as layer visibility. Many apps also provide this functionality in the UI, allowing the user to turn layers on and off, move them up and down in the display order, or even change how they are rendered.
Layers vary in their breadth of supported features and their implementation style. For example, feature layers are conceptually tied to an underlying data model that is symbolized by a renderer. WMS services take an alternative approach, providing map images with pre-rendered feature symbology.
In ArcGIS Runtime, a table is a data source for ArcGIS data and may or may not contain geometry information. A table can contain related features. Some areas of the ArcGIS Platform use the term "table" to refer only to a data source with no geometry information. Such tables in ArcGIS Runtime are referred to as non-spatial tables.
The functionality and performance of each type of layer depend on the characteristics of the data and how it's accessed and displayed in an app. This page describes the major layer types, outlines their characteristics, and indicates how you would typically expect to use them. It also describes non-spatial tables. You can get references to layers and tables from an existing map, or you can build a new map by creating and adding layers and tables to it.
Choosing layer types
Layers allow access to a range of geographic data sources. These data sources may be static in nature or may contain data that changes over time. Your choice of layer type will be driven by factors such as the source of the data, how you want to access and display the data, and your specific performance criteria.
There are lots of sources of geographic data.
Online data sources are provided by online GIS web services that include map services and feature services.
ArcGIS map services fall into two broad categories: tiled and dynamic. Tiled services provide pre-generated (cached) tiles based on the tiling scheme of the layer. Tiles may be provided as raster image tiles or as vector data tiles. The layer then assembles these tiles in the client app. You can access a tiled map service using a tiled layer. Dynamic map services, however, provide map images created on the fly as requested by the client. You can access dynamic map services using a map image layer.
Feature services allow you to access individual features in a map. Feature services such as those from ArcGIS Enterprise and ArcGIS Online return sets of features from a single layer in response to the map's visible extent, or to an attribute or spatial query. You can access this type of service using a feature layer.
An ArcGIS image service provides access to raster data through a web service. An image service can be cached like a map service to improve performance. When an image service has been cached, it supports dynamic access and tiled access. Dynamic access provides access to data, for queries and for downloading, plus access to individual items. It also provides access to data for use in processing and analysis while tiled access provides faster and more scalable access to pre-cooked tiles as a tiled service. To access an image service as a dynamic image service, use a raster layer which allows you to retrieve the metadata of the image service and use the data with raster functions to do analysis. To access a cached image service as a tiled service, use a tiled layer which only allows you to retrieve metadata of a tiled service and display the tiled image.
You can also access data sources—such as mobile map packages, tile packages, or OGC GeoPackages—located locally or on a network. These local data sources also have specific types of layers to access the data.
Geographic data that is generated temporarily (for example, the results of a query or the location of a GPS) is often displayed on a short-term basis in a graphics overlay. See Add graphics overlays to your app for more information.
Layers allow you access to the data sources described above. The diagram below shows the major layer classes in the API and inheritance relationships. Class names in italics are abstract.
For iOS and macOS the class names are prefixed with the ArcGIS API specific characters AGS.
Common layer properties
All layer classes inherit common properties from the AGSLayer class. This class implements the AGSLoadable protocol, that provides the asynchronous pattern for loading the layer's resources. The class also implements the AGSLayerContent protocol. Some of the common properties of this class and its protocols are listed below:
- Display the layer's name using the name property.
- See the layer's description using the layerDescription property.
- Get the layer's full extent using the fullExtent property.
- Determine what spatial reference is used by the layer using the spatialReference method.
- Hide and show the layer by setting the isVisible property.
- Control how transparent or opaque a layer is by setting the opacity properties.
- Change the visible layer's scale range thresholds by setting the minScale and maxScale properties.
Layers with image-based data sources may be image adjustment layers (inherit from AGSImageAdjustmentLayer) which allows the brightness, contrast, and gamma of the layer to be adjusted at run time. The underlying data source is not changed.
Layers that are aware of time information adopt the AGSTimeAware protocol. This defines the following properties that you can use to work with time:
- fullTimeExtent is the window of time that includes all of the data from the layer
- timeFilteringEnabled allows you to exclude the layer from time filtering. Time filtering is enabled by default if the layer type and data source supports it.
- supportsTimeFiltering allows you to determine if an instance of a layer is capable of filtering its data based on the time extent set on the containing map/scene view
- timeInterval allows you to understand the layer's preferred unit of time for manipulation. For example, some data only varies over years, so stepping through days wouldn't make sense.
- timeOffset can be used to compare data over different periods of time. For more information, see Visualize and compare data over time.
Each layer class is used as either a basemap or an operational layer. The following sections discuss the typical classes to use for your basemap or operational layers. However, these are not absolute rules, and the choice of class should be based on an understanding of the functional and performance characteristics of each type as outlined below.
A basemap provides your map with a rich contextual background to help users orient the map. It provides a visual framework on which you can overlay operational layers, perform analysis, and visualize geographic information.
Basemap data is typically provisioned from:
- ArcGIS Online which provides a number of ready-to-use basemaps such as Streets, Topographic, Imagery with Labels, and so on
- Your organization's own business-focused basemaps
- Mashing up your own layers together
If you are creating your own basemap it is important to consider:
- It may be appropriate to publish your data as a dynamic (non-cached) map service if the data changes frequently or if the data is to be used in maps with different projections. You access this data using an ArcGIS map image layer.
- If the basemap data is relatively static then it may be more appropriate to publish it as a tiled (cached) map service. In this case you can display this data using an ArcGIS tiled layer.
- If your users will not have reliable connectivity, consider providing offline basemaps—for example as a tile package, local tile cache, or mobile map package.
- Data storage space can be decreased and drawing performance increased with the use of vector tiled layers.
The following describes the types of online and offline tiled layers that are used as basemap layers.
Online tiled layers
API classes: AGSArcGISTiledLayer, AGSArcGISVectorTiledLayer—Tiled map service layers are connected to cached map services that provide map tiles at predefined scales in a tiling scheme. The tiling scheme is set by the server. The tiles may be either image (raster images), or vector (tiled vector information) tiles. They are drawn on the map view and arranged into their tiling scheme by the client API. Map image tiled services can contain multiple sublayers. The same classes can also be used offline, to display tiles from local tile packages (.tpk, .vtpk files).
Each tile is cached on the server and must be considered as a static map service. It cannot change over time unless the cache is refreshed. You cannot reproject the tile into a different spatial reference, you cannot change the visibility of the individual sub-layers, and the layer cannot be queried or edited. Additionally, vector tiles adapt seamlessly to the resolution of the display, can have a specific style (for example for nighttime schemes), and can be rotated while labels remain un-rotated.
The tiles are generated only once when the cache is originally created on the server. If a map extent requires multiple tiles each tile request can be made on multiple threads. The responses are then handled asynchronously so that 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 tile increases as the resolution or complexity of the image or vectors in the tile increases. For example, high-resolution imagery tiles can be larger in file size than topographic mapping for the same area and map extent. Vector tiles are generally significantly smaller than image tiles for the same area and extent, and are tailored for rapid display.
Offline tiled layers
API classes: AGSArcGISTiledLayer, AGSArcGISVectorTiledLayer—A cache of tiles can be created, provisioned to the client device, and displayed as a layer in an app, without the need to remain connected to the service. For a raster tiled map service, you can use AGSExportTileCacheTask to generate and download a cache directly from the service to the device. The cache may be a single raster Tile Package (.tpk) file, or an ArcGIS Compact Cache. Alternatively you can use ArcGIS Pro to create a map tile package or vector tile package and provision it to the device.
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.
Mobile basemap layers
API classes: AGSMobileBasemapLayer—A mobile map package can be created in ArcGIS Pro and provisioned for display in your app. The package may contain one or more mobile maps, each of which contains a basemap with mobile basemap layers. They contain vector features in a compressed format.
A mobile basemap layer represents multiple feature layers from a geodatabase, rendered together in a group to form a vector basemap. This layer abstracts the complexity of many layers into a single, simple-to-use basemap layer.
Functional and performance characteristics
Like offline tiled layers, mobile basemap layers display quickly because no network calls are required to retrieve the data. However, data must be prepared in advance in ArcGIS Pro and downloaded to the device over the network, or by provisioning the generated files directly to the device file storage. You cannot select, query, or edit features in a mobile basemap layer.
Web Map Service (WMS) layers
API classes: AGSWMSLayer, AGSWMSSubLayer—A layer that displays data from a web service that provides maps in the form of pre-rendered images. Web Map Service (WMS) is an Open Geospatial Consortium (OGC) specification for delivering map images from an online service. Versions of this specification supported at 100.2.1 include 1.1.0, 1.1.1, and 1.3.0. A WMS service can contain multiple layers in a hierarchy. An AGSWMSLayer can be constructed directly with a URL to a service and the uniquely-identifying name of the desired layer. Alternatively, an AGSWMSService can be used to programmatically explore the available layers and allow the user to choose layers at run time. Some layers can be marked as opaque, which means that they cover most of the map area and are good candidates for use as a basemap.
Functional and performance characteristics
The maps provided by a WMS service use predefined symbology defined by the server. As a result, it is not possible to apply custom renderers or to visualize feature selection.
Operational layers focus primarily on data that changes more frequently than that of a basemap. Online operational data can come from a feature service accessible using a feature layer, a dynamic (non-cached) map service accessed using a map image layer, or a file. The choice of service type depends on what functionality and performance characteristics are required. If editing is required then a feature service is appropriate; however, if complex rendering is required, a dynamic map service may be more appropriate. ArcGIS Runtime support for OGC standards, including WMS and WMTS, can be used to consume many public services where an underlying ArcGIS service may not be accessible. More differences are highlighted below.
Feature layers display data from feature services or from supported local data sources such as shapefiles, GeoPackages, and geodatabases. Feature layers can be used to display, select, and query features in a layer. If the underlying feature service or table supports editing, you can use it with a feature layer as a basis for editing geometry, attributes, and attachments. Features also form the basis for spatial analysis, comparing features' spatial relationships and attributes. No matter what your field of work is, spatial analysis helps to derive additional information from your data for better decision making.
Features in a feature layer are retrieved from a feature service as the app is used, or alternatively, are read from a feature data source stored locally on the machine. Features can also be downloaded from a sync-enabled feature service when the device is connected and cached locally for use when the device is offline. Choose from the options below (online, offline, or offline with sync) according to the workflows you want to support in your app.
API classes: AGSFeatureLayer (based on a AGSServiceFeatureTable)—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. The local table cache is discarded when the layer is disposed. This layer supports time-based filtering.
Create and initialize a AGSServiceFeatureTable, then create a AGSFeatureLayer by passing in the AGSServiceFeatureTable to the constructor, and finally add the AGSFeatureLayer to the map. The AGSServiceFeatureTable class is a subtype of AGSFeatureTable, which is used for offline feature layers.
Feature request modes— The feature request mode controls how often features are retrieved from the service and how it is cached on the client. AGSServiceFeatureTable supports three different modes, which significantly affect the functionality and performance of the layer. You can set the mode you require by using the featureRequestMode method of the AGSServiceFeatureTable before the table is initialized.
- On interaction cache—The default mode for spatial and non-spatial tables. This mode is best for editing data that does not change frequently on the server, or if there is a large amount of data on the service. 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 and are cached locally. Features continue to be requested and cached as you navigate the map to other extents. For extents that have already been visited, features are not requested again unless the cache has been cleared or refreshed. Features can also be requested by querying or populating the table directly. The API 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 in 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 populateFromServiceWithParameters method of AGSServiceFeatureTable. Features are never requested, 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. It is expected that this mode will have a higher network usage. 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.
API classes: AGSFeatureLayer (based on a AGSGeodatabaseFeatureTable) —A local cache of a feature service can be downloaded 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 AGSGeodatabaseSyncTask. This layer supports time-based filtering.
Create and initialize a AGSGeodatabaseFeatureTable, and create a AGSFeatureLayer by passing in the AGSGeodatabaseFeatureTable to the constructor, then add the AGSFeatureLayer to the map. Learn more about creating offline maps.
API classes: AGSFeatureLayer (based on a AGSGeodatabaseFeatureTable from a local geodatabase, AGSShapefileFeatureTable, or AGSGeopackageFeatureTable from a local GeoPackage) —Use a feature layer to display data from a cache of features in a geodatabase (.geodatabase), shapefile (.shp), or a GeoPackage (.gpkg), stored locally on the device. A GeoPackage is a data source that conforms to the OGC GeoPackage specification. At 100.2.1, supported GeoPackage versions are 1.0, 1.1, and 1.2.
Create and initialize a AGSGeodatabaseFeatureTable using the local path to the geodatabase file, and create a AGSFeatureLayer by passing in the AGSGeodatabaseFeatureTable to the constructor, then add the AGSFeatureLayer to the map. Learn more about creating offline maps.
Create a AGSGeoPackageFeatureTable or AGSShapefileFeatureTable from the path to the GeoPackage or shapefile, respectively. For a GeoPackage, retrieve a AGSGeoPackageFeatureTable from the collection of tables contained by the package. To display the features in your local data source, pass the AGSGeoPackageFeatureTable or the AGSShapefileFeatureTable to the constructor of a AGSFeatureLayer, then add the AGSFeatureLayer to the map.
For all feature layers, individual features can be queried and filtered based on spatial queries or text-based SQL WHERE clauses. If the layer is created from an editable feature service and the service is configured to support editing, the feature layer can be edited, and edits can be pushed to the service when required. If the layer is created from a GeoPackage data source, you can edit the features locally, but as there is no associated feature service, you cannot sync the edits with a service. Layers based on GeoPackage data cannot be saved with the map. Shapefile data sources are not editable.
If the feature layer was created from a sync-enabled feature service, 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.
Local caches cannot be reprojected automatically, so they should be used in a map that has the same spatial reference as the local cache.
Find out more about editing feature layers.
As full feature information is cached locally in a geodatabase, shapefile, or GeoPackage, and features are drawn natively, this layer type offers excellent display performance 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.
The local cache must be initially created, which requires server-side processing time, and any initial download to the device may require extensive network usage and subsequent local device storage. Additionally, app memory increases with the number and complexity of the features cached. Network usage can be eliminated by provisioning the cache directly to the device in advance (the offline case), 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). This workflow may be suitable if the data do not change too frequently
Feature collection layers
API classes: AGSFeatureCollectionLayer—A layer that manages the display of all tables in a feature collection. A feature collection may contain one or more feature collection tables, which contain a set of features. Tables in the collection can have different schema, geometry types, and rendering but are managed as a group, so things like visibility and draw order in the map are determined by the feature collection layer. This layer supports time-based filtering.
A feature collection layer is used to display the features in a feature collection. A feature collection provides a way of grouping logically-related feature collection tables. Redlining information (called "Map Notes" in ArcGIS Online), for example, may contain points, lines, polygons, and associated text to describe things in the map. Because they have different schema and geometry types, these features are stored in several distinct tables. As a feature collection, however, their visibility and draw order can be managed with a single feature collection layer. Individual feature tables in the collection are rendered as feature layers (described previously). This layer supports time-based filtering.
A feature collection can be saved in the map or as a stand-alone portal item. In either case, the raw format of the data is JSON that describes the schema and features contained in each table. If you need to share the feature collection between several maps, it's best to store it as a separate portal item. Each map that uses the collection can add the collection from the portal item. If you need to make frequent (near real-time) edits to features in the collection, consider storing these in a feature service instead, because the collection is not refreshed until the map or portal item is reloaded. If features are used by a single map and/or are not subject to frequent updates, it might be best to store them directly in the map. Edits made to features stored in a map will be saved when the map is saved. Edits made to features stored in a portal item (and loaded into a map, for example) must be explicitly saved to the original portal item to persist those changes.
Feature collection layers are designed to display a moderate amount of feature data (hundreds or thousands of features). They are ideal for sharing static data (not subject to frequent updates, in other words) amongst several clients.
As full feature information is cached locally in a geodatabase and features are drawn natively, this layer type offers excellent display performance when zooming and panning the map, within the extent of cached features.
The local geodatabase cache must be initially created by deserializing the JSON representation of features. Downloading features to the device may require extensive network usage and local device storage space, but once the features are present in the client, the app no longer needs to make requests for the data and will run faster. Additionally, app memory increases with the number and complexity of the features in the collection.
Map Image layers
API classes: AGSArcGISMapImageLayer—A dynamic (non-cached) 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. This layer supports time-based filtering.
Map images are created and returned by the server on every request. Therefore, if your data has been changed those changes will appear when a new map image is requested and returned. You can also control the visibility of sub-layers in this map image layer and you can filter data by adding layer definition expressions. The spatial reference of this layer type can also be changed from the service's default, and the service re-projects each image on-the-fly to the requested output spatial reference (that of the map).
To query a map service sublayer (represented by the AGSArcGISMapImageSublayer class) you can create a service feature table using a URL composed of the MapServer endpoint and the layer index, for example: http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer/3.
For every map request, the map service creates a map image on-the-fly. Consequently, the server rendering time depends on the amount and complexity of the data in the map. If the map service is well optimized, this should result in a 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.
ArcGIS map image 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.
API classes: AGSArcGISSceneLayer—A layer to display 3D features from a scene service or locally available scene package. Scene layers can be used to represent and visualize 3D objects, such as textured or untextured buildings, or 3D mesh data, such as imagery captured by drones.
All of the layer types that are supported for 2D display can also be displayed in 3D. Using ArcGIS Pro, 3D content can also be delivered as scene packages (stored on the client) or as online scene services. These data sources support consuming large volumes of multipatch features, such as buildings for entire cityscapes. See the Display a scene topic for more information about working with scenes and displaying data in 3D.
A scene service is used to provide one of the following types of 3D data:
- 3D Objects: 3D object scene layers are used to represent objects such as buildings, trees, and street furniture that are explicitly modeled in three dimensions.
- Integrated Mesh: 3D mesh data is typically captured by an automated process for constructing 3D objects out of large sets of overlapping imagery. The result integrates the original input image information as a textured mesh including 3D objects, such as buildings and trees, and elevation information. Integrated mesh scene layers are generally created for citywide 3D mapping; they are often captured by drone and cannot be restyled.
- Point Scene: To ensure fast visualization, cached scene layers are used to display large amounts of 3D point data, such as all the trees in a city. Point scene layers are automatically thinned to improve performance and visibility at smaller scales. Automatic thinning means that not all features are displayed at small scales; as you zoom in, additional features are displayed. Point scene services are not supported for ArcGIS Runtime SDK at this release.
In a 3D map (scene), scale is not consistent across the display, as it is in a 2D map. In other words, the same number of pixels near the horizon, represents a much larger area than the same number of pixels in the foreground. For a scene layer, therefore, the rendering of 3D data is based on the current level of detail (LOD), determined by the distance from the camera.
Each object in a 3D object service is represented differently at various LOD determined by the camera distance. As the camera distance changes in the scene, objects will be displayed appropriately for the current LOD. This ensures that performance in the client is good and memory usage is low, although objects will frequently be loaded and unloaded according to the current LOD.
API classes: AGSRasterLayer—A layer to display image data from a raster data source, such as a raster file, mosaic dataset, image service, or the result of a raster function. You can change how a raster layer is visualized by creating a raster renderer and applying it to the layer. For more information about working with rasters, see Add raster data.
A raster consists of a matrix of cells (or pixels) organized into rows and columns (or a grid) where each cell contains a numeric value. The values in a raster can represent discrete features, such as land use codes, or continuous phenomenon such as elevation. Rasters are digital aerial photographs, imagery from satellites, digital pictures, or even scanned maps.
Raster data is often used to provide context for other information in the map (as a basemap, in other words). Aerial photography, for example, can often give a more realistic or timely view of what's on the ground or illustrate changes in the terrain over time. Many sources of analytical data are available in a raster format, such as those derived from satellite imagery. These data may be used for feature identification, classification, change analysis, and so on.
Rasters are composed of one or more bands. A band is represented by a single matrix of cell values (like a layer of data within the raster), and a raster with multiple bands contains spatially coincident matrices of cell values representing the same area on the ground. An example of a single-band raster dataset is a digital elevation model (DEM), where each cell contains one value representing the elevation at that location. A satellite image, on the other hand, commonly has multiple bands representing different wavelengths of the electromagnetic spectrum. Landsat imagery, for example, contains seven bands that represent data from the visible and infrared parts of the spectrum. Another example of a multiband image is a true color orthophoto in which there are bands to represent red, green, and blue light.
Raster datasets can be quite large. The size of the dataset depends on: the geographic extent of the data, the size of the cells used, the number of bands, and so on. As with any data consumed locally, file size can be an issue for storage as well as for transferring datasets onto a device.
Web Map Service (WMS) layers
API classes: , - A layer that displays data from a web service that provides maps in the form of pre-rendered images. Web Map Service (WMS) is an Open Geospatial Consortium (OGC) specification for delivering map images from an online service. Versions of this specification supported at 100.2.1 include 1.1.0, 1.1.1, and 1.3.0. An AGSWMSLayer can be constructed directly from a URL to a service and the uniquely-identifying names of the desired layers. Alternatively, an AGSWMSService object can be used to programmatically explore the available layers and allow the user to choose layers at run time. Some layers can be marked as opaque, which means that they cover most of the map and are likely intended for use as a basemap.
Functional and performance characteristics
WMS services require an online connection and provide comparatively little control over the display of information. All rendering is done on the server and only pre-rendered images are consumed by the app. Because images are rendered at the server and no feature geometry is sent, it is impossible to graphically select WMS features.
Electronic Navigational Chart (ENC) layers
Electronic navigational charts (ENCs) are georeferenced vector datasets for the visualization and analysis of hydrographic and maritime information. ArcGIS Runtime supports ENCs that conform to the International Hydrographic Organization (IHO) S-57 standard. For more information, see Display electronic navigational charts.
Functional and performance characteristics
ENC layers differ from other layer types in that ENC content is cached in an internal collection of SENC files. When an ENC layer is displayed, only the content in the SENC files is referenced. SENC files are produced when an ENC cell is read for the first time, and updated as update sets are applied.
Some layer types support filtering their data based on time values. For example, you could choose to restrict an earthquake map to include only earthquakes that happened in the last week. Time-based filtering is enabled by defining a time extent on the geo view (map view or scene view) that is displaying the layer.
You can also use a time offset to compare changes over time within a single dataset. For example, by adding two layers to the map that display the same dataset, and applying a year offset to one layer, you can visually compare the data year-over-year. For more information, see the Visualize and compare data over time topic.
Although a particular layer type may support time, it is possible that the data source for the layer does not have temporal data. It is also possible that the layer was published without enabling or configuring time support. You can use the supportsTimeFiltering property to determine if a layer supports time filtering as configured.
Layers that support time filtering will participate in filtering by default. If a layer is opted out of filtering or does not support time filtering, all of its data will be displayed regardless of the time extent set on the geo view. In other words, non-time-aware layers and excluded time-aware layers will not participate in any time filtering.
Non-spatial tables can store descriptive information and can contain data from feature services or local geodatabases. A non-spatial table can share the same data source as a layer, but it doesn't include geometry. In ArcGIS Runtime, it's represented by either AGSServiceFeatureTable (for online) or AGSGeodatabaseFeatureTable (for offline) instances.
The main difference between a spatial table and a non-spatial one is that a feature layer can be created from a spatial table and its features can be displayed on a map. A non-spatial table does not have associated geometry, symbology or rendering information, and therefore, its features cannot be drawn on a map. You can, however, still add a non-spatial table to a map, and it can be part of a map’s tables. You can iterate over a map's tables, add or remove them from the map, query or edit them.
Feature request modes—The default feature request modes for online non-spatial tables are the same as their spatial counterparts. For details, see Feature request modes on this page.
Loading—Non-spatial tables, like their spatial counterparts, adopt the loadable protocol and are not loaded by default. Tables are loaded internally when other asynchronous operations such as query are performed. Alternatively, they can be loaded explicitly. Note: Loading a table wouldn't fetch its data. Data is fetched as needed when querying or populating it. For more information on loadable resources, see Loadable pattern for asynchronous resources.
- Get non-spatial tables from an existing map—A map authored in ArcGIS Online or ArcGIS Enterprise portal can contain tables in addition to a basemap and
operational layers. Tables can also be in maps authored using ArcGIS Desktop and they can be packaged as mobile map packages for ArcGIS Runtime apps. When a map is opened in an ArcGIS Runtime app, the
map's table property contains an array of non-spatial tables.
- Initialize a table—You can create tables in code and add them to the list of map's tables. Instantiating a table would return an unloaded table. You can set options like featureRequestMode before loading the table. A table created and loaded this way can be used in its own right—queried, edited, and so on, but it can also be added to a map.
Graphics are used to display temporary information that is not covered by the other types of layer above. They can be created based on user actions, or results from an operation, or converted from the information in an external information feed. Each AGSGraphic is defined in memory in your app and is stored in the AGSGraphicsOverlay of a AGSMapView. Learn how to add graphics overlays to your app.
- Add a layer to a map using the ArcGIS Online Map Viewer—See Add layers in the ArcGIS Online help (you may know this type of map as a web map or a portal map)
- Add a web map to your app—See Create the map object from a web map in Display a map
- Add a basemap layer to a map you build with ArcGIS Runtime—See Create a basemap in Build a new map
- Add an operational layer to a map you build with ArcGIS Runtime—See Add operational layers in Build a new map.