A quick tour of authoring feature services for ArcGIS Spatial Data Server

The feature service authoring process involves setting up a map document to define the data and symbology that will be exposed by the service.

Defining the data

The layers and tables that you add to the map document will be exposed by the service. The following describes the data requirements for authoring a map to publish to ArcGIS Spatial Data Server:

• All data must be from a single database.
• Feature classes that use binary storage (such as SDEBINARY or OGCWKB) cannot be used.
• The data to be published must have a valid spatial reference defined for it. If it does not, you must specify one in ArcMap before the data can be published. If no spatial reference is defined, you cannot publish the data.
• If you want to edit the data through a feature service, connecting users must be granted the required privileges—insert, update, and/or delete.
• If you want to edit the data through a feature service, 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 for Desktop, a database-maintained unique integer ObjectID is added automatically. If you create data outside of ArcGIS, be sure to include a database-maintained unique integer column in the table. If such a column does not exist, you cannot publish an editable feature service.
• For read-only feature services, the tables that participate in the feature service must contain a unique integer column to be used as an object identifier.
• Data with z- or m-values cannot be accessed through a feature service published to ArcGIS Spatial Data Server. If the data is using Oracle Spatial storage, none of the data in the table will be accessible through the service. For all other supported geometry types, the two-dimensional data in the table will be accessible through the service, but the data with z- or m-values will not.
• Query layers published to a feature service can contain data from only one table; the query cannot join data from other tables.
• You cannot publish data from a previous release geodatabase. For example, if you have data from a 10 or 9.3 enterprise geodatabase in your map, that data cannot be published to the spatial data server.

If you plan to use the feature service for editing, Esri recommends that you only add data to the map document that you want to edit (the operational layers). Data that you do not want to edit, such as basemap layers, should be published in a different service. Alternatively, you can use an ArcGIS Online service as the basemap.

Be aware that, though you can publish data with z- or m-values through a feature service published to ArcGIS Spatial Data Server, you cannot edit these features through the feature service. If you do, the z- and m-values on the feature will be dropped. New features created through the feature service will not contain z- or m-values.

Also note that if you use Windows authentication for your data source connection (ArcGIS Spatial Data Server for IIS only), you cannot publish from ArcMap. To publish a feature service manually, see the CreateFeatureService topic in the ArcGIS Spatial Data Server REST API documentation, which can be opened from the REST API administrative endpoint.

Setting up the map document

The next step after adding the data to the map document that you want to publish is to set properties on the layers and tables. These properties define how the data will appear and what the client will be able to do with the data.

Defining symbology

A feature service allows you to query features and also get the features' symbology. Clients can use this information to draw the 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.

Feature services used with a spatial data server support simple and class break renderers. If an unsupported renderer is used (such as a dot density or chart renderer), you will not be able to publish; the analyzers in ArcGIS for Desktop will determine if layers in the map have renderers that are not supported.

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.

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.

When a map service with feature access is started, 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.

Note:

It is recommended that you use RGB colors in the symbols; otherwise, minor changes may occur when the colors are converted to the RGB color format.

Feature templates

Inserting new features through a feature service is accomplished using feature templates from the map document. A template allows you to digitize a new feature and have the attributes set appropriately by default. Default feature templates are used when you publish a feature service for a spatial data server or start an edit session on the service.

Field properties

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, 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.

The fewer attribute fields that are included in your published feature service, the better the performance. If some fields do not need to be exposed through the feature service, you can mark them as not visible.

To set fields as not visible or to change a field's alias or read-only property, right-click the layer in the ArcMap table of contents and click Properties. On the Fields tab, you can change the field properties for that layer.

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.

Coordinate systems

Feature services support cases where layers in the map document have different coordinate systems. Coordinate system translations are performed if needed when using the feature service. 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, it is converted to the layer's coordinate system before being stored. Spatial queries involving geometries are also converted to the layer's coordinate system before being applied in order to return the correct results.

Geographic (datum) transformations are also used 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.