In ArcGIS Runtime, features and graphics represent real-world objects on a map or scene. Every feature and graphic has a geometry representing its shape and location, as well as other attributes that further describe the represented object. For example, polygon features could represent land parcels and include attributes about each one such as parcel ID or owner. Point graphics could represent event locations, including the event's time and type.
Features and graphics are similar to one another in that they both have a geometry and attributes, this is represented by the geoelement base class which they both implement. However, features are designed for different uses than graphics. Your choice between using a graphic or a feature depends on various factors, such as whether they are persisted in a data store or a map, whether they all share a single geometry type and set of attributes, or how your app displays them. This topic describes and compares features and graphics and helps you choose which is best to use in various cases.
The following table compares important characteristics of features and graphics:
Comparison of features and graphics
In a feature layer in a map in a map view or scene in a scene view.
In a graphics overlay in a map view or scene view.
In a feature table in a data store (such as a database or service) or in a map or scene.
In app memory only.
Geometry type (point, line, and so on)
Features of different geometry types cannot exist in the same layer.
Graphics of different geometry types can exist in the same graphic overlay.
Features in the same data store or feature layer have a common attribute schema.
Each graphic may have a set of attributes unlike other graphics in the same graphic overlay.
Symbolized according to the renderer defined for the feature service or the feature layer.
If persisted in a feature collection table in a map or scene, the renderer can be overridden with feature-specific symbols.
Symbolized individually or according to the graphics overlay’s renderer.
Via the map view or scene view.
Via the map view or scene view.
Created, updated and deleted using feature table operations
Created through a graphic constructor and added to the graphics overlay graphics collection. Attributes and geometry updated by reference on a graphic instance
Symbolizing features and graphics
In order to display on a map or scene, features and graphics must be assigned a symbol. There are a variety of symbol types you can create for displaying geoelements, with properties such as color, size, and style that you can modify. While all geoelements need a symbol in order to display, the symbol is applied differently for features and graphics.
- Features must be displayed using a renderer, which is basically a collection of symbols. The renderer is applied to the layer that contains the features. A renderer can also contain logic that determines which symbol to apply to each feature based on an attribute value.
- A graphic is more flexible. It can have a symbol applied directly, or can get its symbol from a renderer applied to the graphics overlay that contains it.
How features and graphics relate to a map or scene
A map or scene contains layers, among other things. Feature layers in a map or scene are used to display features, feature layers are bound to a feature table. Features are not displayed using a graphics overlay.
A map view or scene view contains a map or scene, and graphic overlays, among other things. Graphic overlays in a map view or scene view always display graphics on top of the map and any layers the map contains. Graphics are not displayed using layers.
Where do features come from?
Features can be hosted in an online service, stored locally in a database, saved in a map or scene, or saved as a portal item. How you access features in your app affects how you make and manage edits to them.
A feature service provides online access to features and can be hosted by ArcGIS Enterprise or ArcGIS Online. A feature service contains one or several collections of features. If you visit the REST Services Directory page for a feature service, you'll see the collections of features it contains listed under the Layers: heading, as shown in the following image. Features of different geometry types (point, line, and polygon, in other words) cannot exist in the same collection, so it's common to see features organized according to geometry type in addition to theme.
The feature service in the example contains several datasets, including three that describe C2 Military Operations using points, lines, and areas (polygons). The number in parenthesis indicates the index position inside the feature service. To access a specific set of features, append the index position to the URL for the service. Hostile Units, for example, can be accessed at https://sampleserver6.arcgisonline.com/arcgis/rest/services/Military/FeatureServer/6.
Features in your ArcGIS Runtime app are stored in feature tables of which there are many types. Features that come directly from an ArcGIS feature service are stored in a service feature table, which is created using the URL for the service and index position (see the URL above). Features read from a local geodatabase are stored in a geodatabase feature table; for more information on how to create a geodatabase see Take a layer offline. Static features stored in a map, scene, or portal item are stored in a feature collection table as part of a feature collection. Features from a web feature service are stored in a WFS feature table.
Since a feature service or local geodatabase can contain several sets of features (tables, in other words), you may need to create many feature tables in your ArcGIS Runtime app to represent all the datasets you need.
Types of features
Different feature table types return different feature objects. Feature tables that inherit directly from the AGSFeatureTable base class return the AGSFeature object type. Feature tables which inherit from AGSArcGISFeatureTable have additional capabilities such as attachments, these return AGSArcGISFeature objects.
For increased efficiency, the AGSArcGISFeature object implements the loadable pattern. When fetching features for rendering and query purposes, a minimum set of required fields are returned, such as identifiers, geometry, fields used for symbolizing, and so on. When you need all of the available fields you can simply load the feature.
When querying features, you have the option to return your results as loaded features so all fields are immediately available.
It's not necessary to display the features you work with in your app. If you want your user to view (and interact with) features on a map or scene, however, add the feature table that contains them as a feature layer. A feature layer can display features from any type of feature table. See the Layers and tables topic for more information about creating and working with feature layers.
Features in a feature layer can use different request modes, including caching of features, for efficient display on the client. You should be aware of the various feature request modes, as the caching behavior of feature layers may affect the editing experience. Feature request modes are described in detail in the Layers and tables topic.
A feature layer can also display data from a map service or a geodatabase in a mobile map package, in which case the data in the underlying feature table will be read-only.
Where do graphics come from?
Graphics are created by the developer and added to the application. They can be created from results from various operations such as querying, identifying, geoprocessing, geocoding or routing. They can also be created from external data sources, but if you want to persist the data in a map or scene then you must use features. Graphics can also be created by the developer as a result of a map click or touch.
When to use features
Persistence is a built-in characteristic of features. Features are persisted in a data store such as a database, a service, a map or a portal item. When this data store is available to multiple apps and users, a common set of data is available to all. Sharing data among users is a common use case for features.
Compare this to graphics, which reside in the memory of a single running app session. Graphics are created by the app during the session and are available only during that session.
You can publish features as part of a feature service. Layers in a feature service can be displayed in a map or scene, symbolized in various ways, and queried using attribute, spatial, or temporal criteria. The editing workflows and tools available in ArcGIS Runtime SDK also make it possible to expose editing functionality in your app. You can even add code to control the type of edits made and who gets to make them.
When to use graphics
Apps create graphics as needed, and graphics do not need to be persisted. Therefore, graphics are ideal for displaying things that are specific to the session, or anything that is displayed only temporarily. For example, the results of some tasks are returned as graphics, which your app may display on a graphics overlay.
The following are some common uses for graphics:
- Display text on top of a map or scene
- Highlight a section of the map or scene by overlaying a polygon graphic
- Display results from spatial analysis, such as buffer polygons created around features
- Display a route between two locations
- Display geometry drawn interactively by the app user
- Animate data items that change quickly, such as moving objects