When you author a map to publish as a feature service, you need to consider the purpose of the feature service and where the data for the feature service is stored, as that affects how you create, manage, and use the feature service.
This topic covers authoring a feature service to be published to a stand-alone or federated ArcGIS GIS Server site and having the feature service reference the data in a geodatabase or database you have registered with the GIS Server site. This authoring process involves preparing the data to meet feature service requirements, creating a map that contains the data you want to publish, defining symbology and other data properties within the map, and defining a feature template for the editing environment (if you want the feature service to be editable).
Prepare the data
The layers and tables you add to the map document are included in the feature service when you publish. Some data definition requirements are common whether your data source is a geodatabase or a database. Common requirements are described in the next section. In other cases, how you define the data depends on whether it is in a geodatabase or database. The sections Enterprise or workgroup geodatabase-specific requirements and Database-specific requirements describe those differences.
Virtual layers, such as route events, x,y events, and parcel fabrics, are read-only through the feature service.
Requirements common to geodatabases and databases
The following requirements are true whether your source data is stored in a database, workgroup geodatabase, or enterprise geodatabase:
- Add data you publish to the same feature service must come from a single source geodatabase or database. You cannot add data to your map from two or more different database connection and publish.
- The data must have a valid spatial reference defined for it. If it does not, specify one in ArcMap or ArcGIS Pro before you publish. If no spatial reference is defined, you cannot publish the data.
- Layers based on views are not supported in feature services. You cannot edit views using ArcGIS clients; therefore, publishing feature services containing views is not supported, as feature services can be enabled for editing. If you want to use data from a view for reference in a map or app, publish the view in a map service.
- The database account you stored with the database connection file you register with the GIS Server site must have the privileges necessary to access the data. If the feature service will remain read-only, the account only needs select access to the data. If you plan to use the feature service for editing, you must grant editing permissions on the data. If the database connection you register with the site uses operating system authentication, these permissions must be granted to the ArcGIS Server account.
- Esri recommends that the map you publish as an editable feature service only contain data you want to edit. Publish data that you don't want to edit, such as basemap layers, in a different service. For more information about planning your operational and basemap services, see Map service planning. Another alternative is to use an ArcGIS Online basemap. For more information on designing a map to overlay online maps and services, see Designing a map to overlay ArcGIS Online, Google Maps, or Bing Maps.
- Do not define multiple layers for the same feature class in the map you publish as a feature service if people will be adding the feature service to ArcMap or ArcGIS Pro and editing it. For example, if you want to serve the same feature class with different symbology or different definition queries applied, create separate feature services; do not include these differently configured representations of the same feature class in the same feature service.
- If your data contains z-values and editors need to edit the feature service in clients that do not support adding z-values when editing feature geometry (such as Map Viewer in ArcGIS Online and ArcGIS Enterprise portals), configure the feature service to insert default z-values.
- If your data contains m-values and editors need to edit the feature service in clients that do not support adding m-values when editing feature geometry (such as Map Viewer in ArcGIS Online and ArcGIS Enterprise portals), configure the feature service to insert NaNs for the m-values.
ArcGIS Desktop clients support all editing operations (insert, delete, and update, including geometry updates) on features with m- and z-values even when you make a local copy of the feature service data to edit in ArcMap. Therefore, you do not need to configure default z and NaN m-values if editors will only edit the feature service in these clients.
Enterprise or workgroup geodatabase-specific requirements
The following feature service requirements are specific to data stored in an enterprise or workgroup geodatabase. Your data needs to meet the requirements described in the previous section, as well as those described in this section.
- You can publish tables or feature classes that are not registered with the geodatabase; however, publishing views is not supported.
- If you allow edits on the feature service and the feature service contains feature classes that participate in a geometric network, the feature class data must be in the same projection and coordinate reference system used by the editing client application. For example, if you plan to add the feature service to Map Viewer to edit, the data must be stored in WGS 1984 Web Mercator (Auxiliary Sphere). Note that you cannot just change the projection in ArcMap or an ArcGIS Pro map before you publish; the data must use the same projection and coordinate reference system as the editing client.
- Versioned (traditional and branch) and nonversioned geodatabase data is supported in feature services. Esri recommends that you use nonversioned data in feature services because it scales better for editing. There are some nonsimple data types (for example, network edges), however, that must be versioned for you to edit them through a feature service.
- To edit branch version data, you must publish a feature layer from ArcGIS Pro that references your registered data. See Share branch versioned data in the ArcGIS Pro help for more information.
- You cannot publish a map service with feature access enabled from an ArcMap document or publish a feature layer that references registered data from ArcGIS Pro if any of the following layers are present in your map:
- Group layers
- Layers and tables based on views
- Query layers that contain virtual columns, where clauses, or joins
- You can include annotation layers in your map when you publish a feature layer that references registered data from ArcGIS Pro. You cannot include annotation layers if you publish a map service with feature access enabled from an ArcMap map document.
- Parcel fabrics are always read-only when accessed through a feature service.
- You can publish layers that are part of nonsimple types, such as geometric networks, topologies, and network datasets, but the types themselves are not returned by the feature service. For example, you can query the layers that are part of a topology, but you cannot query the topology itself.
- Feature services allow queries on related data, but only if the relationship is defined through a geodatabase relationship class. If a published map document has a layer and table related through a geodatabase relationship class, the feature service allows queries on the layer to return objects from the related table. Note that to support queries that return related objects, you must include the table and layer involved in the relationship class in the published map document. If either the origin or destination layer or table is not included in the map document, the feature service ignores the relationship.
For attributed relationship classes, also include the relationship class table in the map document.
- To maintain a utility network, you must publish it as a feature layer from ArcGIS Pro. See Publishing and consuming services with the utility network in the ArcGIS Pro help for more information.
Prepare geodatabase data for use while offline
To work with maps when you're offline, enable a sync capability on the feature services you use in your map. For more information, see Prepare data for offline use.
ArcGIS clients and developer SDKs will progressively add support for the sync capability in feature services, which was introduced in ArcGIS 10.2.1. The first clients to support working with maps while offline are Collector for ArcGIS and ArcGIS Runtime SDKs. You cannot enable the sync capability on feature services published prior to ArcGIS 10.2.1.
Other clients can access the sync capability through the ArcGIS REST API.
The following describes feature service data requirements specific to data stored in a database. Your data must meet these requirements in addition to the requirements common to geodatabases and databases.
- When you add database data to a map in ArcMap or ArcGIS Pro, a query layer is created. If you alter the query layer definition, be sure the query contains only one table, does not have duplicate columns, and does not include joins, where clauses, or virtual or merged columns.
- The query layer defined for the table determines what data publishes. For example, tables containing data types that are not supported by ArcGIS can be published, but unsupported data types are not accessible through ArcGIS or the feature service. See View database data in ArcGIS for information on how the query layer is initially defined when you add a database table to the map.
- The table must contain a unique integer column maintained by the database. If you create tables and load the data to the database using ArcGIS, a database-maintained unique integer ObjectID is added automatically. If you create data outside of ArcGIS, be sure to include a database-maintained, unique, not null integer column in the table. If such a column does not exist, you cannot publish a feature service. You can use the Add Incrementing ID Field geoprocessing tool to add a database-maintained integer column to your table if it is in an ALTIBASE, Db2, Microsoft Azure SQL Database, SQL Server, Oracle, or PostgreSQL database. For all other databases, use database management system tools or SQL to create the ID column.
- Supported database platforms from which you can publish data include Microsoft Azure SQL Database, SQL Server, PostgreSQL, Oracle, IBM Informix, IBM Db2 (on Linux, UNIX, or Windows), ALTIBASE, Teradata, SAP HANA, and Dameng.
Configure a map
Once you define the data, add it to a map in ArcGIS Pro or ArcMap you want to publish and set properties on the layers and tables. These properties define how the data appears and what the client can do with the data.
Configure a map in ArcGIS Pro
See Author a web map in the ArcGIS Pro help for information on configuring a map for publishing.
Configure a map document in ArcMap
Once you define the data, add it to an ArcMap map document you want to publish, and set properties on the layers and tables. These properties define how the data appears and what the client can do with the data.
Map document configuration is similar for both database and geodatabase data. However, if your map document contains geodatabase data, you can configure your map to take advantage of extra functionality available only in geodatabases before publishing.
Set a layer name
When you add a feature class or table to a map, the default name is the fully-qualified name of the table within the database. At minimum, you should change the layer name so it does not include the database and user name. Right-click each layer in the table of contents and click Properties. On the General tab, type a useful name that represents the layer's contents and does not include the database and user name.
For example, if you add the feature class, rivers, to the map from an enterprise geodatabase named mygdb, and the feature class is owned by the user gdbdata, the default layer name in the map is mygdb.gdbdata.rivers. Change the layer name to rivers.
You might change the layer name even further if you set a definition query on the layer that changes what features are displayed in the map. For example, if you set a definition query so that only rivers within 5 miles of mine are displayed, it would be useful to change the layer name to reflect that; for example, set the layer name to rivers near mines. If the feature class participates in a relationship class and, therefore, related data will be included in the service you publish, you might change the layer name to reflect that. For example, if the rivers feature class participates in a relationship class that joins it to a table containing watershed information, you could change the layer name to rivers and watersheds.
A feature service allows you to query features and also get the features' symbology. Clients can use this information to draw features with a symbology that is consistent with what is defined on the service.
The symbols returned by the service are based on the symbology of the layers in the ArcMap document. Each symbol in each layer is referred to as a type. For example, a layer symbolized with a simple renderer (one symbol) has one type. If a unique value renderer is used, a type returns for each unique value in the renderer.
Feature services support simple, unique value, class break, and cartographic representation renderers. If you use an unsupported renderer, the service will not start. Use the ArcGIS Server log to determine which layers have unsupported renderers.
Feature services do not support proportional symbols or unique value renderers based on multiple fields.
Most symbol types can be used with a feature service; however, in some cases, the symbols may be downgraded.
For line layers, simple line symbols are supported. If other symbols are used, the feature service converts them to a simple line symbol that best represents the original symbol. For example, a cartographic line symbol in the map document may be drawn as a simple solid line in a feature service client. If a line symbol is complex or has multiple layers, the feature service downgrades the line to best represent the original line symbol.
For polygon layers, simple fill and picture fill symbols are supported. If other symbols are used, the feature service downgrades them to simple fill symbols. For multilayer fill symbols, the feature service only considers the top layer. Also, a fill symbol's outline symbol has the same level of support as described for line layers above.
For point layers, simple marker and picture marker symbols are supported. If other symbols are used, the feature service downgrades them to picture marker symbols. Multilayer marker symbols are also downgraded to picture marker symbols where the layers are merged into a single layer. Mask properties, where a halo can be set for a marker symbol, are not supported.
When a map service with feature access starts, the symbols are checked and downgraded if needed. In cases where a downgrade is required, a warning is added to the server log to describe which symbols were downgraded.
It is also important to note that if you have layers in your map document that use cartographic representation renderers, the renderers are reported as unique value renderers when clients access the service through REST.
Esri recommends that you use RGB colors in the symbols; otherwise, minor changes may occur when the colors convert to the RGB color format.
Define feature templates
Inserting new features through a feature service is accomplished using the feature templates from the map document. A template allows you to digitize a new feature and have the attribute's default values set accordingly. Feature services require that a template exist for each feature type. When you start an edit session or publish the service, a default template is created for each type.
Default templates are always used for database data. You can create customized templates to use with geodatabase data. See the Custom feature templates section for more information.
Set a scale range
Feature services only display 1,000 features by default. Set the scale range for the feature layers in the map you publish so the layer will not display in a scale at which more than the maximum number of features would appear.
To set a scale range for a feature layer, right-click the layer in the ArcMap table of contents and click Properties. Set the Scale Range on the General tab of the Layer Properties dialog box.
Field properties set in ArcMap are exposed through the feature service; this includes field aliases, field visibility, and a field's read-only property. Read-only fields include system-managed fields, such as ObjectID, globalid, and editor tracking fields (geodatabase only), as well as fields set to be read-only in the map document.
When applying an update, if a value is set for a read-only field, the feature service ignores the value. When applying an insert, default values are applied for read-only and invisible fields. If default values have not been defined, nulls are applied. If the field cannot store null values, the insert fails.
Layer description and copyright information
Layer descriptions and credits (copyrights) specified in the map document are exposed for each layer in the feature service as a layer description and copyright information, respectively.
Feature services support HTML pop-ups configured in ArcMap. HTML pop-ups are a powerful and easy way to share HTML-formatted information about features. They work much like the Identify tool, except that the displayed information can be customized HTML. For more information about how to set up HTML pop-ups in ArcMap, see Setting HTML pop-up properties for feature layers.
If you work with your feature service on the web and you want pop-ups to be available, consider defining them in Map Viewer instead. Alternatively, developers can use the client API itself to define pop-up styles.
Feature services support temporal data—data that represents a state in time. Store time information in single or multiple attribute fields, and use this information to visualize data at particular times or in time intervals. To expose temporal data for a layer through the feature service, enable time on the Time tab of the Layer Properties dialog box. For more information about how to enable time on a layer, see Enabling time on your data.
The map document you publish as a feature service can contain layers that have different coordinate systems. When clients access the feature service, the feature service translates the coordinate system if needed. For example, if a client inserts a feature through a feature service using a coordinate system that is different from the coordinate system of the layer, the feature service converts the feature's coordinate system to match the layer's coordinate system before storing the new feature. Spatial queries involving geometries also convert to the layer's coordinate system before being applied to return the correct results.
The feature service also uses geographic (datum) transformations if needed. For example, if the layer is stored in NAD27 and a feature is inserted through the service with a coordinate system of WGS 1984, a WGS 1984 to NAD27 datum transformation is performed before the feature is stored. You can control the transformation method by setting up transformations in the data frame properties of the map document before publishing. A default transformation is performed if one is not defined in the map.
Although you can publish separate layers that have different coordinate systems, all records in an individual table must use the same coordinate system.
You can define attribute joins for layers or tables in the map document. When you publish a map service with feature access capability to a GIS Server site, joined columns are included in the map service but are not included in the feature service. The feature service includes only the columns from the join table (the table or feature class on which you defined the join). If symbology for the layer is based on a joined column, the map service includes the renderer you used to symbolize features, but the feature service reverts to a simple renderer. If the renderer in the layer is based on a column from the left most feature class in the join, the map server and feature server includes the renderer.
You cannot publish joined data to Portal for ArcGIS or ArcGIS Online. Remove joins before publishing a feature service (hosted feature layer) to either of these applications.
Additional geodatabase functionality
If your data is stored in a geodatabase, you can take advantage of some additional functionality. Configure this functionality before publishing a feature service.
Define subtypes and attribute domains
If the data you publish is in a geodatabase, configure your datasets to use subtypes and attribute domains where appropriate to enhance the user experience of the feature service and prevent data entry errors. These provide ways of categorizing your data and ensuring that appropriate values are entered when the data is edited. Feature services can detect and use the subtypes and domains. For example, if you have a domain limiting the color of a fire hydrant to red, yellow, or blue, you see a drop-down list in the web application that allows you to only select one of those three colors.
If you publish a feature service without copying data, subtype information is included in the feature service independent of the renderer you use. If you will publish a feature layer to ArcGIS Online or an ArcGIS Enterprise portal, subtype information is included only when layers are published using a unique value renderer on the subtype column.
Custom feature templates
Within ArcMap, you can create new templates or modify existing templates to customize the editing experience through the feature service. This includes setting a default construction tool, which is used to create that type of feature. If you remove a template for a particular feature type, a default template is created when you publish.
There are different types of construction tools available depending on the type of feature the template creates. For example, if you have a line template, you can only select tools that can be used to create line features. The construction tool saved with the templates is available through the feature service. The only exception is the point tool called Point At End Of Line, which is not supported by feature services. For more information about templates, see Setting feature template properties.
When the map document is saved, the templates are saved with the layers in the map. When the map document is published, these templates are available for feature service clients. Once the layers, types, and templates are defined in your map document, you are ready to publish the service.
Feature services allow you to query and edit attachments. An attachment is a media file associated with a feature or object in a geodatabase. For example, with attachments, photographs and videos can be added to a bird sighting and viewed when the sighting point is clicked. To use this feature, datasets within a geodatabase must first be configured to support attachments. When these datasets are added to a map document and published, clients can query, insert, and delete the attachments through the feature service.
There are limits imposed on the size and file types you can attach to a feature service. To learn more about these limits and how to modify attachment settings, see Uploads in the ArcGIS REST API Help.
For more information about how to configure a dataset to support attachments, see Enabling attachments on a feature class.
Example ArcMap workflow: Bird sighting feature service
The following section walks you through an example of how to set up a map document, define the data, and define the symbology exposed through a bird sighting feature service. The feature service allows the birding community to post their bird sightings directly on the map and attach media files, such as photographs, audio files, and video files, to the specific observation points.
The steps in this example are applicable to geodatabases and databases; however, feature attachments and custom feature templates are not available in databases. You can ignore the content that discusses this functionality if the data you're working with is not stored in a geodatabase.
Define the data
The first step in authoring a feature service is defining the data that will be available through the service. In this example, start with a feature class called Bird_Sightings in a geodatabase. To have attachments associated with this feature class, attachments have to be added in ArcCatalog or the Catalog window in ArcMap. To do this, connect to the database, right-click the feature class, and choose Manage > Create Attachments. This creates a table that stores the attachments and a relationship class that relates the feature class to the attachments table. For more information about how to add attachments to a feature class, see Enabling attachments on a feature class.
Certain types of data require versioning to be edited in an enterprise geodatabase. This same requirement also applies to editing feature services. For more information, see An overview of versioning.
With the data set up, the next step is to add the data to ArcMap and define the symbology. The symbols returned by the feature service are based on the symbology of the layers in the ArcMap document. Each symbol in each layer is referred to as a type. In this example, by default, the Bird_Sightings layer is symbolized with a simple renderer (one symbol).
However, in this case, you want to symbolize the bird sighting layer based on the type of sighting. To do this, a unique renderer can be used. To change the way a layer is rendered, right-click the layer and choose properties. In the properties dialog box, click the Symbology tab and choose Unique values under Categories. You can then select the field you want to use to symbolize the layer. In this case, there are three unique types of sightings (bird sighting, nest sighting, and rare bird sighting); therefore, three types (one for each sighting type) are returned by the service.
Now that the renderer is selected, the next step is to choose the symbols that represent each sighting type. In this case, a bird symbol is selected from the Esri symbol selector. The foreground and background colors are set differently for each type of sighting so they can be easily distinguished in the feature service. When the map document publishes, the symbols convert to PNG graphics, which are returned to the client.
Once the symbology is set up, the next step is to define the editing environment that will be available through the feature service.
Define the editing environment
The goal of this feature service is to allow bird enthusiasts to enter bird sightings and all relevant information onto a map. Editing through a feature service is accomplished using the feature templates from the map document. If you do not create templates, a default template is created per type when you publish the service. However, you can also create new templates or modify existing templates to customize the editing experience.
In this example, you want to create templates for this feature service. To do this, right-click the feature class, choose Edit features, and choose Organize Feature Templates. Under Layers, select the layer and click New Templates. The Template wizard appears, where you can create templates. Choose to create templates for all the different types of bird sightings. Once templates have been created, copy them to create additional templates.
For this feature service, you want to add an additional template for the rare bird sighting type. Rare bird sightings can be birds that are in the area out of season or endangered. To create a copy of a template, select the template you want to copy and click Copy. In this case, a copy of the rare bird sighting template is created so that each can be customized to represent the two types of rare bird sightings. To customize a template, double-click it in the Organize Feature Template window. This brings up the template properties, where you can edit the name of the template as well as the default field values.
The template for endangered rare bird sightings has the sighting type set to Rare Bird Sighting and the description set to Endangered. The template for out-of-season rare bird sightings has the sighting type set to Rare Bird Sighting and the description set to Out of Season.
The rest of the attributes can also be set to appropriate default values within each template. In this case, endangered rare bird sightings require a follow-up survey, so the Follow up attribute can be set to default to Yes. A follow-up is not required for out-of-season rare bird sightings; therefore, the Follow up attribute can be set to No.
Setting some of the attributes to default values in the templates streamlines the editing experience for end users because they have to only select the type of feature and digitize it. Once the layers, types, and templates are defined in your map document, you are ready to publish the service. After it is published, end users can access the service through web clients or ArcGIS Desktop for querying and editing.
For more information, see Publish a feature service from ArcMap.
Other example tutorials
If you need more guidance in how to set up and use a feature service, the following tutorials provide step-by-step examples of how to set up a map document, define the data, and define the symbology exposed through a feature service to perform web editing. The tutorials vary depending on if you've stored your data in an enterprise geodatabase or database.
If your data is stored in an enterprise geodatabase, follow the enterprise geodatabase tutorials:
If your data is stored in a database, follow the database tutorial: