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 ArcGISMap or ArcGISScene (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.getServiceGeodatabase() 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 the branch versioning topic in this guide or the publish branch versioned data topic 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.

Use dark colors for code blocksCopy
                                                                                                                                                                                                                                                                                                                                                          
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
private fun addFeature(point: Point) {

  // Create attributes for the feature.
  val attributes = hashMapOf(
    "typdamage" to "Minor",
    "primcause" to "Earthquake"
  )

  // Create a new feature from the attributes and the point.
  val feature = damageTable.createFeature(attributes, point)
  // Check if it is an AGSArcGISFeature.
  val arcgisFeature = feature as? ArcGISFeature ?: return

  try {
    // add the feature to the local table
    val addFeatureFuture: ListenableFuture<Void>  = damageTable.addFeatureAsync(arcgisFeature)
    addFeatureFuture.addDoneListener {
      // If the feature table is a service feature table, then
      // apply edits to its service geodatabase
      ...
    }
  } catch (e: Exception) {
      e.printStackTrace()
  }
}

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 setServiceCurveGeometryMode() 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.

Use dark colors for code blocksCopy
                                                                                                                                                                                                                                                                                                                                                          
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
private fun updateFeature(arcgisFeature: ArcGISFeature) {
  // Change the feature's attribute value.
  arcgisFeature.attributes["typdamage"] = "Inaccessible"
  // Change the feature's geometry
  val currentLoc = arcgisFeature.geometry as? Point ?: return
  val updatedLoc = Point(currentLoc.x, currentLoc.y + 5000, map.spatialReference)
  arcgisFeature.geometry = updatedLoc

  try {
    // Update the feature on the local table.
    damageTable.updateFeatureAsync(arcgisFeature)
  } catch (e: Exception) {
      e.printStackTrace()
  }
}

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 setServiceCurveGeometryMode() 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.

Use dark colors for code blocksCopy
                                                                                                                                                                                                                                                                                                                                                          
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
private fun deleteSelectedFeatures(damageLayer: FeatureLayer) {
  try {
    // Get all selected feature in the layer.
    val selectedFeaturesFuture = damageLayer.getSelectedFeaturesAsync()
    selectedFeaturesFuture.addDoneListener {
      val featureQueryResult = selectedFeaturesFuture.get()
      // Delete the selected features.
      damageTable.deleteFeaturesAsync(featureQueryResult)
    }
  } catch (e: Exception) {
      e.printStackTrace()
  }
}

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.

Use dark colors for code blocksCopy
                                                                                                                                                                                                                                                                                                                                                          
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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
private fun applyEdits(featureTable: FeatureTable) {
  val serviceFeatureTable = featureTable as? ServiceFeatureTable ?: return
  try {
    val featureTableEditResultFuture = serviceFeatureTable.serviceGeodatabase?.applyEditsAsync()
    featureTableEditResultFuture?.addDoneListener {
        val featureEditResult = featureTableEditResultFuture.get()
    }
  } catch (e: Exception) {
      e.printStackTrace()
  }
}

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:

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

Edit with branch versioning

Create and save KML file

Delete features (feature service)

Edit features with feature-linked annotation

Your browser is no longer supported. Please upgrade your browser for the best experience. See our browser deprecation post for more details.