Update Definition (Feature Layer)

URL:: https://<adminRoot>/<serviceName>/FeatureServer/<layerId>/updateDefinition
Methods:: GET

Description

The updateDefinition operation supports updating a definition property in a feature service layer. The result of this operation is a response indicating success or failure with an error code and description.

New at 11.4

This operation now supports performing asynchronous requests for ArcGIS Enterprise hosted feature services.
This operation can update the subtypes of a hosted feature service layer.

New at 11.1

The updates below have been added, in general, for hosted feature services:

A layer's extent property can be updated by an owner or organization administrator using this operation with the layer's spatial index.
A layer's allowGeometryUpdates property can be set on a per-layer basis using this operation.
A service owner or organization administrator can now update a layer's definitionQuery property when running this operation.

Request parameters

Parameter Details

Parameter	Details
`updateDefinition`	The service update to the layer definition property for a feature service layer.
`async`	Support options for asynchronous processing. The default format is `false` . Values: `true` \| `false`
`f`	The response format. The default response format is `html` . Values: `html` \| `json` \| `pjson`

updateDefinition

The service update to the layer definition property for a feature service layer.

async

Support options for asynchronous processing. The default format is false .

Values: true | false

f

The response format. The default response format is html .

Values: html | json | pjson

Example usage

Use dark colors for code blocksCopy
https://services.myserver.com/OrgID/ArcGIS/rest/admin/services/example/FeatureServer/0/updateDefinition

Example one: Enable attachments on a feature service layer

Example two: Rename feature service layer

Example three: Update feature service layer renderer

Example four: Update feature service time info

Example five: Update other feature service layer properties

Example six: Update feature service domain and alias

Example seven: Update definition: Rebuild index

Example eight: Update definition: Multiscale geometry

Example nine: Adding keywords and exifInfo attachment fields

Example 10: Enabling response caching (Enterprise hosted feature services only)

Example 11: Update the feature service's field properties

Example 12: Update the feature service's field properties

Example 13: Update the feature service's propagateVisibleFields property

Example 14: Update subtype code

Example 15: Add subtypes to a layer that does not have subtypes defined

Example one

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to enable attachments on a feature service layer:

Use dark colors for code blocksCopy
{"hasAttachments": true}

Example two

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to rename a feature service layer:

Use dark colors for code blocksCopy
{"name": "newName"}

Example three

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update a feature service layer's renderer. The following request is formatted for readability:

Use dark colors for code blocksCopy
{
  "drawingInfo": {
    "renderer": {
      "type": "uniqueValue",
      "field1": "symbolid",
      "field2": null,
      "field3": null,
      "fieldDelimiter": ", ",
      "defaultSymbol": null,
      "defaultLabel": null,
      "uniqueValueInfos": [
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 2
          },
          "value": "1",
          "label": "Active Burnout",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              169,
              0,
              230,
              255
            ],
            "width": 13
          },
          "value": "0",
          "label": "Aerial Hazard",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 15
          },
          "value": "3",
          "label": "Completed Burnout",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 18
          },
          "value": "4",
          "label": "Completed Dozer Line",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              56,
              168,
              0,
              255
            ],
            "width": 12
          },
          "value": "6",
          "label": "Escape Route",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 18
          },
          "value": "7",
          "label": "Fire Break Planned or Incomplete",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 28
          },
          "value": "9",
          "label": "Foam Drop",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 16.350000381469727
          },
          "value": "13",
          "label": "Management Action Point (MAP)",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 8
          },
          "value": "15",
          "label": "Planned Secondary Line",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 15
          },
          "value": "16",
          "label": "Proposed Burnout",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 18
          },
          "value": "18",
          "label": "Retardant Drop",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              255,
              0,
              0,
              255
            ],
            "width": 4
          },
          "value": "19",
          "label": "Uncontrolled Fire Edge",
          "description": ""
        },
        {
          "symbol": {
            "type": "esriSLS",
            "style": "esriSLSSolid",
            "color": [
              0,
              0,
              0,
              255
            ],
            "width": 33.75000190734863
          },
          "value": "21",
          "label": "Division Break",
          "description": ""
        }
      ]
    },
    "transparency": 0,
    "labelingInfo": null
  }
}

Example four

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the time information for a feature service layer. The following request is formatted for readability:

Use dark colors for code blocksCopy
{
  "timeInfo": {
    "startTimeField": "startTime",
    "endTimeField": "endTime"
  }
}

Example five

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the feature service layer's properties. The following request is formatted for readability:

Use dark colors for code blocksCopy
{
  "xssTrustedFields": "field1, field2",
  "displayField": "field1",
  "description": "",
  "copywriteText": "",
  "minScale": 0,
  "maxScale": 0,
  "maxRecordCount": 1000,
  "standardMaxRecordCount": 4000,
  "tileMaxRecordCount": 4000,
  "maxRecordCountFactor": 1,
  "types": "",
  "templates": "",
  "defaultVisibility": true,
  "typeIdField": ""
}

Example six

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the feature service's domain and alias. The following request is formatted for readability:

Use dark colors for code blocksCopy
{
  "fields" : [
    {
      "name" : "FLD2_DBL_FC2",
      "type" : "esriFieldTypeDouble",
      "alias" : "FLD2_DBL_FC2",
      "sqlType" : "sqlTypeOther",
      "nullable" : true,
      "editable" : true,
      "visible" : true,
      "domain" :
      {
        "type" : "range",
        "name" : "RDOM_3",
        "mergePolicy" : "esriMPTDefaultValue",
        "splitPolicy" : "esriSPTDefaultValue",
        "range" : [
          100,
          150.5
        ]
      },
      "defaultValue" : 125
    },
    {
      "name" : "FLD3_DBL_FC2",
      "type" : "esriFieldTypeDouble",
      "alias" : "FLD3_LONG_FC1",
      "sqlType" : "sqlTypeOther",
      "nullable" : true,
      "editable" : true,
      "visible" : true,
      "domain" :
      {
        "type" : "codedValue",
        "name" : "CDOM_1",
        "mergePolicy" : "esriMPTDefaultValue",
        "splitPolicy" : "esriSPTDefaultValue",
        "codedValues" : [
          {
            "name" : "code 1 description",
            "code" : 1
          },
          {
            "name" : "code 1.5 description",
            "code" : 1.5
          },
          {
            "name" : "code 2 description",
            "code" : 2
          },
          {
            "name" : "code 2.5 description",
            "code" : 2.5
          }
        ]
      },
      "defaultValue" : 1
    }
  ]
}

Example seven

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to rebuild the spatial index for a feature service layer. Note that with hosted feature services at ArcGIS Enterprise 11.1, this will also adjust the extent to cover all features in the layer:

Use dark colors for code blocksCopy
{
  {
    "indexes": [
      {
        "name": "user_11.bookmarkspatialreference_WFL_Wilson_HydroArc_Shape_sidx",
        "fields": "Shape"
      }
    ]
  }
}

Example eight

The following examples demonstrate how to optimize the drawing of complex lines and polygons:

The operation is only supported when the layer metadata has supportsMultiScaleGeometry=true and when async=true .
The multiscale geometry is supported on polyline and polygon data in any projection, but it can be used only when the output projection is Mercator (102100).
The Mercator levels of resolution are used when creating the multiscale geometry. Supported generalization levels are [1–17].
When editing or syncing the data, the multiscale geometries are updated.
At query time, use the maxAllowedOffset or the quantization offset to determine the generalized geometry for that level. If the shape for the requested level does not exist, use the closest generalized geometry. For instance, if the user requests level 5 geometry and it does not exist, search for the next generalized geometry (6 or higher).

If you pass the levels, the minReductionFactor , or both, build the multiscale geometries for these levels or when the difference between the actual geometry and the generalized geometry is greater than the minReductionFactor . Identify the first level to build based on the extent of the data. Try to find the level where the Mercator cell contains all the data. The minReductionFactor is between [0,1]. The default is 0.2.

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to enable multiscale geometry on a layer:

Use dark colors for code blocksCopy
{"multiScaleGeometryInfo": {"levels": [1, 3, 5, 7, 9]}}

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to disable multiscale geometry:

Use dark colors for code blocksCopy
{"multiScaleGeometryInfo": null}

Example nine

Below is a sample JSON object for the udpateDefinition parameter that demonstrates how to add the keywords and exifInfo attachment fields. This requires attachments already be enabled on the layer. For ArcGIS Enterprise hosted feature services, this was added in at 10.8.1 and requires both fields to be provided in the call.

Use dark colors for code blocksCopy
{
 	"attachmentProperties": [
    {
		    "name": "keywords",
		    "isEnabled": true
	   },
    {
		    "name": "exifInfo",
		    "isEnabled": true
	   }
  ]
}

Example 10

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to enable response caching on layer. It is only applicable for Enterprise hosted feature services running on a relational data store starting at 10.9. In this example the caches are set to expire after one day.

Use dark colors for code blocksCopy
{
  "layerCache": {
    "enabled": true,
    "expiration": 1
  }
}

Example 11

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the feature service's field properties.

Use dark colors for code blocksCopy
{
	"fields": [{
		"name": "Code",
		"type": "esriFieldTypeString",
		"alias": "Code",
		"sqlType": "sqlTypeOther",
		"length": 30,
		"nullable": true,
		"editable": false,
		"visible": true,
		"domain": null,
		"defaultValue": null
	}]
}

Example 12

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the feature service's field properties.

Use dark colors for code blocksCopy
{
	"fields": [{
			"name": "Code",
			"type": "esriFieldTypeString",
			"alias": "Code",
			"sqlType": "sqlTypeOther",
			"length": 30,
			"nullable": true,
			"editable": false,
			"visible": true,
			"domain": null,
			"defaultValue": null
		},
		{
			"name": "TypeGroup",
			"type": "esriFieldTypeString",
			"alias": "TypeGroup",
			"sqlType": "sqlTypeOther",
			"length": 250,
			"nullable": true,
			"editable": false,
			"visible": true,
			"domain": null,
			"defaultValue": null
		}
	]
}

Example 13

Below is a sample JSON object for the updateDefinition parameter that demonstrates how to update the feature service's propagateVisibleFields property.

Property Details

Property	Details
`propagateVisibleFields`	Online feature service defaults this property to false and it won't show up in JSON metadata, it only shows when `propagateVisibleFields=true` . This property determines whether fields that are marked as visible in the source layer should be automatically included in the view layers associated with it. Values: `false(default) \| true`

propagateVisibleFields

Online feature service defaults this property to false and it won't show up in JSON metadata, it only shows when propagateVisibleFields=true . This property determines whether fields that are marked as visible in the source layer should be automatically included in the view layers associated with it.

Values: false(default) | true

Usage

New View Layer

When creating a new view layer, you can set the source layer propagateVisibleFields property to either true or false. The default value is false, which means that fields marked as visible in the source layer will not be automatically included in the view layer. This parameter provides a flexible way to manage field propagation in a GIS service, allowing you to control which fields are visible in a view layers based on your specific requirements.

Propagation Behavior

When propagateVisibleFields is set to true, the following behavior occurs:

All existing fields in the source layer marked as visible=true will be automatically included in the view layer.
Any new fields added to the source layer will also be automatically included in the view layer.
If the source layer is associated with multiple view layers, enabling propagateVisibleFields will ensure that the same fields are visible in all view layers.

Example Request

POST /rest/admin/services/{serviceName}/FeatureServer/{layerNumber}/updateDefinition

Content-Type: application/json

Use dark colors for code blocksCopy
{
	"propagateVisibleFields": true
}

Source Layer

To remove the propagateVisibleFields setting to all views associated with a given source layer, you can use the layer updateDefinition admin API.

Example Request

POST /rest/admin/services/{serviceName}/FeatureServer/{layerNumber}/updateDefinition

Content-Type: application/json

Use dark colors for code blocksCopy
{
	"propagateVisibleFields": false
}

Enabling/Dis-enabling propagateVisibleFields at the source layer level will propagate new fields to all associated view layers, ensuring consistency across all views.

Example 14

The following example updates the name of a subtype. Note that the subtype code is required to identify which subtype to rename:

Use dark colors for code blocksCopy
{
  "subtypes": [
    {
      "code": 200,
      "name": "Automobile new"
    }
  ]
}

Example 15

To add subtypes to a layer that does not currently have subtypes, the subtypeField and defaultSubtypeCode properties must first be added to the layer. Each property should be added to the layer in separate requests. First, add the subtypeField property to the layer. The code sample below demonstrates the input for the updateDefinition parameter that adds the subtypeField property to a layer:

Use dark colors for code blocksCopy
{
  "subtypeField": "rd_class"
}

After adding the subtypeField property, another request must be submitted to add the defaultSubtypeCode property to the layer. The code sample below demonstrates the input for the updateDefinition parameter that adds the defaultSubtypeCode property to a layer:

Use dark colors for code blocksCopy
{
  "defaultSubtypeCode": 1
}

After both properties have been added to a layer, the Add to Definition operation can be called to add subtype codes to the layer. The code sample below demonstrates the input for the addToDefinition parameter that adds two subtype codes to a layer:

Use dark colors for code blocksCopy
{
	"subtypes": [
		{
			"code": 1,
			"name": "highway",
			"defaultValues": {
				"textfield": "two lane highway"
			}
		},
		{
			"code": 2,
			"name": "freeway",
			"defaultValues": {
				"textfield": "four lane highway"
			}
		}
	]
}

JSON Response syntax

The example below reflects the syntax of a synchronous response:

Use dark colors for code blocksCopy
{
  "success": <true|false>,
  "error": {
    "code": <code>,
    "message": "<description>",
    "details": [
      "<message>"
    ]
  }
}

The example below reflects the syntax of an asynchronous response:

Use dark colors for code blocksCopy
{"statusURL": “<response status URL>”}

JSON Response examples

Synchronous responses

When updateDefinition succeeds as a synchronous response:

Use dark colors for code blocksCopy
{
  "success": true
}

When updateDefinition fails as a synchronous response:

Use dark colors for code blocksCopy
{
  "error": {
    "code": 400,
    "message": "",
    "details": [
      "Unable to update feature service layer definition."
    ]
  }
}

Asynchronous responses

When an updateDefinition request is submitted asynchronously, the response will include a statusURL, the value of which is a URL that can be accessed to check the status of the request:

Use dark colors for code blocksCopy
{
  "statusURL": "https://machine.domain.com/ArcGIS/rest/admin/services/myhostedservice/FeatureServer/0/updateDefinition/5f4f34c6-2bcf-41c7-8bd1-ea777570ad23"
}

The URL can be used to periodically check the progress of the request, which is returned as the status property. When the job completes, the response retrieved from the status URL will indicate whether the request completed successfully.

Use dark colors for code blocksCopy
//success

{
  "submissionTime":1726444564500,
  "lastUpdatedTime":1726444568893,
  "status":"Completed"
}

//failure

{
  "submissionTime": 1726520769240,
  "lastUpdatedTime": 1726520769773,
  "status": "Failed",
  "error": {
    "code": 500,
    "description": "Editing definition error - RCPerfTestOneWayAllRowsParent.DBO.Volcano_Roop "
  }
}