Update Definition (Feature Layer)
- URL:https://<layer-url>/updateDefinition
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 |
---|---|
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
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:
{"hasAttachments": true}
Example two
Below is a sample JSON object for the updateDefinition parameter that demonstrates how to rename a feature service layer:
{"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:
{
"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:
{
"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:
{
"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:
Note:
When updating field properties, note that not all of these properties may be updated.
{
"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. :
{
{
"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:
{"multiScaleGeometryInfo": {"levels": [1, 3, 5, 7, 9]}}
Below is a sample JSON object for the updateDefinition parameter that demonstrates how to disable multiscale geometry:
{"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.
{
"attachmentProperties": [
{
"name": "keywords",
"isEnabled": true
},
{
"name": "exifInfo",
"isEnabled": true
}
]
}
Example ten
Note:
At ArcGIS Enterprise 10.9.1, the ability to configure a hosted feature service to provide server-side caching was temporarily removed. Response caching is once again supported with the release of Enterprise 11.0. Organizations using Enterprise version 10.9, 11.0, or higher can cache queries made by services with response caching enabled. Organizations using a 10.9.1 deployment can still use services that support response caching, though queries will not be cached.
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.
{
"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.
Note:
When updating field properties, note that editable setting cannot be changed on fields in the hosted feature layer views in ArcGIS Enterprise.
{
"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.
Note:
When updating field properties, note that editable setting cannot be changed on fields in the hosted feature layer views in ArcGIS Enterprise.
{
"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
{
"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 |
---|---|
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
{
"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
{
"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.
Note:
- If propagateVisibleFields is set to true at the source level, it will show all existing fields marked as visible=true in all associated view layers, even if propagateVisibleFields is not explicitly set or is sset to false in those view layers.
- Any fields added to the source layer will automatically show in all associated view layers when propagateVisibleFields is enabled.
JSON Response example
When updateDefinition succeeds:
{
"success": true
}
When updateDefinition fails:
{
"error": {
"code": 400,
"message": "",
"details": [
"Unable to update feature service layer definition."
]
}
}