Editing means that you can add, update, and delete 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 for more information.
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 for Developers site. Log in to the site using your organization account or your free developers subscription. 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.
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.
- Feature collections in a map - this is where the feature JSON is saved in a single map as a feature collection layer.
- 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.
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. More information is available in 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.
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. Even if you're editing a service feature table, your edits are initially stored in a table on the client. You must explicitly apply service feature table edits to commit them to the parent feature service.
Feature updates include moving or reshaping a feature's geometry or making edits to attribute values. As with all editing operations the changes are not automatically committed to the features source, it is the developer's responsibility to do this.
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. As with all editing operations the changes are not automatically committed to the features source, it is the developer's responsibility to do this.
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