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.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 ten: Enabling response caching (Enterprise hosted feature services only)

Example eleven: Update the feature service's field properties

Example twelve: Update the feature service's field properties

Example thirteen: Update the feature service's propagateVisibleFields property

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 ten

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 eleven

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 twelve

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
		}
	]
}

JSON Response syntax

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

Example thirteen

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.

JSON Response example

When updateDefinition succeeds:

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

When updateDefinition fails:

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