Edit

When you edit in ArcGIS Runtime, you add, delete, and update features. Updating features includes:

• Modifying attributes
• Modifying geometry (moving or reshaping, for example)
• Adding, updating, and deleting feature attachments (related files such as pictures, documents or videos)

Feature layers inside your map's operational layers collection provide the basis for editing. Feature layers store and edit their data using database tables called feature tables.

Editing features is supported in a number of workflows:

• Online feature service editing, where a table is created from the service, edits are made, and the changes are applied back to the service as soon as the user has finished the edit operation. Suitable for multi-user editing scenarios.
• Offline feature service editing and sync, where a local geodatabase is created from a sync-enabled feature service before going offline, tables are retrieved from the geodatabase while offline, edits are made, then changes are applied back to the service when the device is back online again (and server changes are optionally synchronized back). Suitable for multi-user offline workflows. See Offline maps, scenes, and data for more information on offline workflows.
• Static feature collection editing, where tables are created from the features in the map or a portal item, edits are made and changes are saved back into the map or portal item. This is a suitable workflow for sharing static data to lots of clients, but should not be used to edit data across a number of clients or to share data that changes frequently.
• Offline file-based editing. Edits can be made to features from a GeoPackage file (.gpkg) that supports the OGC GeoPackage specification. Such a file is stand-alone and is not backed by a feature service; it is fully offline. If your workflow includes sharing edits online and managing edits across many users, it is recommended that you use online feature service editing.

See Perform edits on this page for more information.

Creating feature services for your data

Feature services provide the symbology, feature geometry, and set of attribute fields (schema) for your features. Feature services contain service layers (feature data) and tables (nonspatial, tabular data) that you edit via a feature table for both online and offline feature service workflows. Feature services allow for scalable multi-client editing for data which changes over time. For more information about feature services, see What is a feature service? in the ArcGIS Enterprise documentation.

Before you build an app that performs feature service editing, you need a feature service that exposes the layers you want to edit. There are various ways to publish a feature service.

• You can login to your organization's portal and publish features from a variety of data sources such as CSV files, GeoJSON, shapefiles, feature collections, or file geodatabases. All of these options and their steps are outlined in the publish hosted feature services topic in the ArcGIS Online documentation.
• You can publish a feature service using ArcGIS Pro to ArcGIS Online or ArcGIS Enterprise. For offline workflows, you must enable the Feature Access capability and ensure that the service is sync-enabled (discussed in Prepare data for offline use.
• You can create a feature layer using the ArcGIS Developer site. Log in to the site using your ArcGIS Online or free ArcGIS Deveoper account. Access the Layers tab and click the Create New Layer button. For offline workflows, follow the instructions to create the new feature layer ensuring that you have checked the box to enable the layer to be taken offline to allow it to be viewed, edited, and synchronized. After creating a layer you can add data to it in the ArcGIS Online Map Viewer.

However you publish your service, REST URLs (endpoints) are created to both a map service and a feature service. Use these URLs to reference the services in your app. The map service endpoint can be used for read-only access to features (viewing only), so make sure to reference the feature service endpoint for editing. Offline editing workflows require sync-enabled feature services. A sync-enabled feature service allows you to generate a geodatabase for offline use and gives you the ability to sync your local edits back to the service.

Manage edits with the service geodatabase

The geodatabase takes an active role to ensure the integrity of your data, often augmenting edits made directly to the data with automated changes or validation. Such changes are referred to as geodatabase behavior.

Examples of geodatabase behavior:

• Composite relationships: Causes a feature in the destination table to be deleted when a related feature is deleted in the origin table.
• Feature-linked annotation: Text in feature-linked annotation reflects the value of a field or fields from a feature in another feature class to which it is linked.
• Utility network association deletion semantics: Values in the UtilityAssociationDeletionSemantics enum describe how deleting a feature of a specific asset type affects associated features.
• Attribute rules: User-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, and perform quality assurance checks.

These capabilities are leveraged by the ServiceGeodatabase class. The class includes information about (and is able to honor) the defined behaviors of the underlying geodatabase.

The service geodatabase allows you to manage edits for all tables it contains, such as checking if the service geodatabase has local edits, applying all edits, or undoing all local edits. Such operations affect all tables in the service geodatabase's connected tables (the collection of feature tables it manages) and apply to all types of edits. Additionally, when the service geodatabase supports branch versioning, you can read the available versions for the geodatabase, switch the current version, or create a new version. See the Use branch versioned data topic for more information.

Get the service geodatabase

If your application loads an existing Map or Scene (from a web map, web scene, mobile map package, mobile scene package, and so on), a ServiceGeodatabase object is created for every feature service that is referenced. You can use ServiceFeatureTable.ServiceGeodatabase to begin working with the available service geodatabases.

If you need to load individual tables from a feature service, you can create a ServiceGeodatabase object first, and then use ServiceGeodatabase.GetTable() to get the table. This is the recommended approach, rather than creating a new ServiceFeatureTable using its constructor.

Feature collections

Feature collections are static collections of features stored as JSON inside the map or a referenced portal item. Many ArcGIS Online operations create feature collections, such as adding Map Notes to your map, importing shapefiles, importing GPX files or sharing analysis results as items. There are two representations of feature collections which are important to understand when it comes to editing and saving features.

1. Feature collections in a map - this is where the feature JSON is saved in a single map as a feature collection layer.
2. Feature collections as portal items - this is where the feature JSON is saved as a portal item. These feature collections can be referenced in multiple maps.

The workflow for editing the features for both types of feature collections is the same. However, there are differences when persisting the edits so that other users can see them. Feature collections in a map will be persisted when the map is saved. Others who open the map will see the edited features. Feature collections stored as portal items will not be saved when a map is saved, you will have to update or save a portal item to ensure that others will see the edited features.

Feature collections should not be used for multi-user editing scenarios, as clients could easily hold on to older versions of the feature collection and overwrite each others changes. Use feature services for these types of workflows.

Perform edits

Fine grained control over editing operations is available by using the editing API, allowing you to create and edit features, add, edit or remove feature attachments, and edit the geometry of features.

For editing workflows that use a local geodatabase, you can use geodatabase transactions to manage a set of edits (transaction). You can then control when those edits are committed (saved) or rolled back (discarded) as a single unit.

The enterprise geodatabase can use versioning to accommodate multiuser editing scenarios and long transactions. If you require multiple editors concurrently accessing services with the ability to undo and redo their edits, you can take advantage of branch versions in your ArcGIS Enterprise portal. For more information, see Use branch versioned data in this guide or Share branch versioned data in the ArcGIS Pro documentation.

For some feature service editing workflows, it's a good idea to have an analyst using ArcGIS Pro periodically review the edits to verify data integrity. Although components in the API can perform some data validation, other tasks such as validating topologies cannot be performed using ArcGIS Runtime SDK alone.

Add features

For creating new features, it's common for an app to allow the user to click the map to specify a new feature's location. You can provide this capability by listening to a click event on your map view, which in turn will call a function for adding a new feature.

To add features to a feature table, create a new feature from geometry (for example, point, line, or polygon), create attributes for the new feature, and then call add feature. This adds the feature to a table stored locally on your device.

If these edits need to be shared with the parent feature service, apply them to the table's service geodatabase. See Apply edits to the service geodatabase for more information.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
private async Task AddFeature(MapPoint structureLocation, string type, string cause)
{
    // Create attributes for the feature.
    Dictionary<string, object> attributes = new Dictionary<string, object>();
    attributes.Add("typdamage", type);
    attributes.Add("primcause", cause);

    // Create a new feature from the attributes and the point.
    Feature newFeature = _damagePointsTable.CreateFeature(attributes, structureLocation);

    // Add the feature to the local table.
    await _damagePointsTable.AddFeatureAsync(newFeature);

    // If the feature table is a service feature table then
    // apply edits to its service geodatabase.
    //var editResults = await _serviceGdb.ApplyEditsAsync();
}

Add true curves

Your ArcGIS Runtime app can add features with true curves to user-managed ArcGIS Enterprise feature services that support true curves.

You can use ArcGISFeatureServiceInfo to find out what type of curve support a feature service has so that you can adapt your app behavior to it. For example, if the service doesn't support true curves, you can densify any curve geometries before sending them to the service. Or, if the service does support true curves, you could use the ServiceCurveGeometryMode member and ServiceCurveGeometryMode enum to fetch curve geometries, and reactively enable a curve-aware user experience in your app.

For geometry information on true curves, see Segments in the Geometry topic.

You may know true curves as parametric curves.

Update features

Feature updates include moving or reshaping a feature's geometry or making edits to attribute values. All edits are stored in the feature table on the client.

If these edits need to be shared with the parent feature service, apply them to the table's service geodatabase. See Apply edits to the service geodatabase for more information.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
private async Task UpdateFeature(ArcGISFeature arcgisFeature)
{
    // Change the feature's attribute value.
    arcgisFeature.Attributes["typdamage"] = "Inaccessible";

    // Change the feature's geometry.
    MapPoint location = arcgisFeature.Geometry as MapPoint;
    MapPoint newLocation = new MapPoint(location.X, location.Y + 50000);
    arcgisFeature.Geometry = newLocation;

    // Update the feature on the local table.
    await _damagePointsTable.UpdateFeatureAsync(arcgisFeature);

    // If the feature table is a service feature table then
    // apply edits to its service geodatabase.
    // var editResults = await _serviceGdb.ApplyEditsAsync();
}

Update true curves

Feature services can be published with protections that disallow edits to existing true curves from curve-unaware clients. If your app supports preserving curve segments when editing, you can use the new ServiceCurveGeometryMode member and ServiceCurveGeometryMode enum to inform the service your app is a true-curve client. Use properties on ArcGISFeatureServiceInfo to find out what curve support a feature service has.

Delete features

You can delete several features from a feature table using the delete features method that accepts a list of features, or just a single feature with a call to delete feature. All edits are stored in the feature table on the client.

If these edits need to be shared with the parent feature service, apply them to the table's service geodatabase. See Apply edits to the service geodatabase for more information.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
private async Task DeleteSelectedFeatures(FeatureLayer damageLayer)
{
    // Get all selected features in the layer.
    FeatureQueryResult selectedFeatures = await damageLayer.GetSelectedFeaturesAsync();

    // Delete the selected features.
    await _damagePointsTable.DeleteFeaturesAsync(selectedFeatures);

    // If the feature table is a service feature table then
    // apply edits to its service geodatabase.
    // var editResults = await _serviceGdb.ApplyEditsAsync();
}

Apply edits to the geodatabase

After making edits to data within a feature table, the edits need to be packaged and sent to the service. Until ArcGIS Runtime version 100.9.0, this was done exclusively with the ServiceFeatureTable.ApplyEditsAsync() method. While this method is still supported, with the introduction of the ServiceGeodatabase object, the recommended approach is to use the ServiceGeodatabase.ApplyEditsAsync() method instead, which sends all changes in all tables to the service as a single transaction and ensures that geodatabase behavior is appropriately leveraged.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
// If the feature table is a service feature table, send these edits
// to the online service by applying them to its service geodatabase.
var gdb = table.ServiceGeodatabase;
IReadOnlyList<FeatureTableEditResult> editResults = await gdb.ApplyEditsAsync();

Attribute rules

Attribute rules enhance the editing experience and improve data integrity for geodatabase datasets. They are user-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, and perform data validation checks on existing features. Attribute rules are defined using ArcGIS Pro and are written with the Arcade expression language. See the ArcGIS Pro documentation for an Introduction to attribute rules and Attribute rule script expression examples.

When editing a dataset with attribute rules, there is no additional code required in leveraging rule evaluation in your ArcGIS Runtime app. Any add, update, or delete feature operation may trigger rule evaluation depending on how you've configured the rule.

ArcGIS Runtime support for attribute rules

ArcGIS Runtime supports attribute rules for the following types of feature tables and geodatabases:

• A ServiceFeatureTable , when created directly from a ServiceGeodatabase (using ServiceGeodatabase.GetTable() , for example).
• A ServiceFeatureTable , when read from a web map or web scene.
• A stand-alone Geodatabase exported from ArcGIS Pro and side loaded onto the device.

Attribute rules are not supported for these types of feature tables and geodatabases:

• A stand-alone service feature table, created as a new instance of ServiceFeatureTable rather than using a web map or web scene or the ServiceGeodatabase.GetTable() method. Stand-alone service feature tables lack the context of their parent geodatabase, which is required to evaluate attribute rules.
• An offline replica Geodatabase (created using GenerateGeodatabaseJob , in other words). Currently, attribute rules are not exported from the feature service when creating these geodatabases.

Attribute rule evaluation on the client

Using ArcGIS Pro, you can define whether your attribute rule runs immediately or at a specified time. Rules that run immediately are evaluated after a feature is added, updated, or deleted. Rules that run at a specified time are useful for performing data validation on existing features. Attribute rules are always evaluated by the data source, but for rules that run immediately, you can also control whether or not they are evaluated by a client. For more information see Evaluate attribute rules in the ArcGIS Pro documentation.

In a connected workflow, your ArcGIS Runtime app is a client for the backing feature service. The feature server or database the app works with is considered the data source. If client evaluation is disabled for a rule, it will not be executed in your ArcGIS Runtime app (only in the backend data source).

If client evaluation is disabled for a rule, it will not be executed in your ArcGIS Runtime app but will be evaluated on the server when ServiceGeodatabase.ApplyEditsAsync() is called. Edits made by the server due to rule execution are automatically reflected in ArcGIS Runtime.

If working with a stand-alone geodatabase, however, your ArcGIS Runtime app is considered both a client for the backing feature service and the data source . Since there is no other data source that the app communicates with, all changes are written directly to the stand-alone geodatabase. If client evaluation is disabled for a rule, it will still be executed in your ArcGIS Runtime app, not as the client but because the local geodatabase acts as the backend data source.

Editor tracking

The editing framework supports the tracking of specific edits to features. This happens by tracking the following feature properties:

• Which user created the feature
• Date and time the feature was created
• Which user last edited the feature
• Date and time the feature was last edited

Samples

Edit and sync features

Add features (feature service)

Sketch on map

Create and save KML file

Update geometries (feature service)

Update attributes (feature service)

Edit feature attachments