Skip To Content
ArcGIS Developers
Dashboard

Apply Edits

Description

License:

The ArcGIS Location Referencing license is required to use this resource.

This operation applies a batch of event or route changes to the editable linear referencing layers in the service.

Currently, only point and linear event layers, network (route) layers, and calibration point layers can be edited.

Edits may only be applied to event feature classes that are local to the LRS geodatabase. External event tables are treated as read-only data sources and do not support web editing.

All edits sent in one request are applied in a single database transaction to maintain data integrity. If any of the individual edits fail, the entire transaction is rolled back and none of the changes are applied. An edit operation may only include layers that exist in a single database workspace. An error message is returned if an edit request specifies more than one layer and those layers are defined in different workspaces.

Note:

If conflict prevention is enabled, locks must be acquired before executing applyEdits, or an error with the missing locks will be returned.

Request parameters

ParameterDetails
f

Description: Optional parameter to specify the response format. The default response format is html.

Values: html | json

edits

Required

Description: A batch of changes to apply to the editable layers in the service. Each layer can receive a distinct set of additions, updates, and deletions. The format of the change records depends on the layer type being edited.

Editing Event Layers

An event layer can receive a set of add, update, and delete records. Event records contain only attributes (including measure values), but no geometry, and the attribute names are case sensitive.

Control merge behavior for linear events using the allowMerge option, which can be set to true or false for each layer being edited. The default is false.

If allowMerge is set to true for a linear event layer, each added record is inspected to determine if it can be merged with any existing event record associated with the same route. Merging two records is possible only if their measure ranges are coincident or overlapping, and all other attribute values are the same. This behavior applies only to additions, not updates or deletions.

Control retire overlap behavior for linear events using the retireMeasureOverlap option, which can be set to true or false for each layer being edited. The default is false.

If retireMeasureOverlap is set to true for a linear event layer, each added record is inspected to determine if it overlaps the measure range of any events associated with the same route. The overlapping portions of any existing events are retired, which entails updating the ToDate field value for that record. This behavior applies only to additions, not updates or deletions.

Control retire by Event ID behavior using the retireByEventId option, which can be set to true or false for each layer being edited. The default is false.

If retireByEventId is set to true for a point or linear event layer, any existing event records with the same event ID and temporality overlaps as the added record are retired.

If an event layer is configured to store referent locations for each event record, the allowMerge and retireMeasureOverlap options preserve the referent location information of existing events whenever possible.

Syntax for event layer edits:

[
  { 
    "id" : <eventLayerId>,
    "allowMerge" : <true | false>,
    "retireMeasureOverlap" : <true | false>,
    "retireByEventId" : <true | false>,
    "adds" : [ <record1>, <record2>, ... ],
    "updates" : [ <record1>, <record2>, ... ],
    "deletes" : [ <record1>, <record2>, ... ]
  },
  {
    "id" : <eventLayerId>,
    "allowMerge" : <true | false>,
    "retireMeasureOverlap" : <true | false>,
    "retireByEventId" : <true | false>,
    "adds" : [ <record1>, <record2>, ... ],
    "updates" : [ <record1>, <record2>, ... ],
    "deletes" : [ <record1>, <record2>, ... ]
  },
  ...
]

An add event record has the following format. Each record must contain at least a Route ID attribute value. In addition, point events must contain a Measure value, and linear events must contain From and To Measure values. Attribute names are case sensitive.

{
  "attributes" : {
    "<field1>" : <value1>,
    "<field2>" : <value2>,
    ...
  }
}

An update event record has the following format. Each record must contain at least the eventId property or the WHERE property to define the set of records to update. If the eventId property is specified, the optional fromDate property may be specified to uniquely identify a single record to update out of all the temporal records for a given eventId. The attributes object should contain only those attribute values that are to be updated. Attribute names are case sensitive.

{
  "eventId" : <eventId>,  // string or number value
  "fromDate" : <fromDate>,  // date value
  "where" : "<whereClause>",
  "attributes" : {
    "<field1>" : <value1>,
    "<field2>" : <value2>,
    ...
  }
}

A delete event record has the following format. Each record must contain at least the eventId property or the WHERE property to define the set of records to delete. If the eventId property is specified, the optional fromDate property may be specified to uniquely identify a single record to delete out of all the temporal records for a given eventId.

{
  "eventId" : <eventId>,  // string or number value
  "fromDate" : <fromDate>,  // date value
  "where" : "<whereClause>"
}

Editing Network Layers

A network (route) layer can receive a create, extend, realign, reassign, or retire record. Attribute names in edit records are case sensitive.

Syntax for network layer edits:

[
  { 
    "id" : <networkLayerId>,
    // include only one of the following record types:
    "createRoute" : <record>
    "extendRoute" : <record>
    "realignRoute" : <record>
    "reassignRoute" : <record>
    "retireRoute" : <record>
    "deleteRoutes" : <record>
  },
  { 
    "id" : <networkLayerId>,
    // include only one of the following record types:
    "createRoute" : <record>
    "extendRoute" : <record>
    "realignRoute" : <record>
    "reassignRoute" : <record>
    "retireRoute" : <record>
    "deleteRoutes" : <record>         
  },
  ...
]

A create route record has the following format. The attributes object must include a route name and can optionally include route from/to dates and any other fields from the network layer except for route ID, line ID, and line order. If the network layer represents a line network, the attributes must include a line name. The route ID and line ID fields are automatically generated by the applyEdits operation and should not be included in the attributes object.

{
  "centerlineObjectIds" : [<objectId1>, <objectId2>, ...],
  "fromMeasure" : <measure>,
  "toMeasure" : <measure>,
  "attributes" : {
    "<fieldName1>" : <value1>,
    "<fieldName2>" : <value2>,
    ...
  }
}

An extend route record has the following format. The newRouteAttributes object must include a route name and can optionally include any other fields from the network layer except for route ID, line ID, line name, line order, from date and to date. Those special fields are automatically derived from other request properties and from the route being edited.

{
  "effectiveDate" : <date>,
  "centerlineObjectIds" : [<objectId1>, <objectId2>, ...],
  "routeId" : "<routeId>",
  "fromMeasure" : <measure>,
  "toMeasure" : <measure>,
  "extendAtEnd" : <bool>,
  "recalibrateRouteDownstream" : <bool>, // defaults to true
  // Specify these attributes only when a new route should be created due to an equation point
  "newRouteAttributes" : {
    "<fieldName1>" : <value1>,
    "<fieldName2>" : <value2>,
    ...
  }
}

A realign route record can have any of the following formats, depending on the network layer configuration. The newRealignRouteAttributes, newDownstreamRouteAttributes and abandonedRoutesAttributes should not contain the line ID, line name, from date and to date attributes, as they are derived by the system.

{
// valid for networks that do not support lines
  "effectiveDate" : <date>,
  "centerlineObjectIds" : [<objectId1>, <objectId2>, ...],
  "routeId" : <routeId>,
  "sourceFromMeasure" : <measure>,
  "sourceToMeasure" : <measure>,
  "realignFromMeasure" : <measure>,
  "realignToMeasure" : <measure>,
  "recalibrateRouteDownstream" : <bool> // defaults to true
}

or

{
// valid for networks that support lines
  "effectiveDate" : <date>,
  "centerlineObjectIds" : [<objectId1>, <objectId2>, ...],
  "routeId" : <routeId>,
  "toRouteId" : <routeId>,
  "sourceFromMeasure" : <measure>,
  "sourceToMeasure" : <measure>,
  "realignFromMeasure" : <measure>,
  "realignToMeasure" : <measure>,
  "recalibrateRouteDownstream" : <bool>, // defaults to true
  "newRealignRouteAttributes" : { // if new route is created
    "<fieldName1>" : <value1>,
    "<fieldName2>" : <value2>,
      ...
  },
  "abandonedLineName": "<new_abandoned_line_name>", // if the realigned portion needs to be abandoned
  "abandonedRoutesAttributes": [ // if the realigned portion needs to be abandoned
    {  
      "<fieldName1>" : <value1>,
      "<fieldName2>" : <value2>,
      ...
    },
   ...
  ]
}

A reassign route record has the following format. The sourceToRouteId is only applicable for networks that support lines. If sourceToRouteId is not provided, it is assumed that sourceRouteId and sourceToRouteId are the same.

{
  "effectiveDate" : <date>,
  "sourceRouteId" : <routeId>,
  "sourceToRouteId" : <routeId>,
  "sourceFromMeasure" : <measure>,
  "sourceToMeasure" : <measure>,
  "recalibrateSourceRouteDownstream" : <bool>,
  "reassignFromMeasure" : <measure>,
  "reassignToMeasure" : <measure>,
  "transferCalibrationPoints" : <bool>,

  // optional, only needed when reassigning to an existing route
  "reassignRouteId" : <routeId>,
  "recalibrateReassignRouteDownstream" : <bool>,

  // optional, only needed when reassigning to a new line
  "newReassignLineName" : "<lineName>",

  // optional, only needed when reassigning to new route(s)
  "newRouteAttributes" : [
    // either a single attributes object, or one per reassigned source route
    // if only a single object and there are multiple source routes, then merging occurs
    // attributes must include route name, but not route ID, line ID, or line order
    { "<field>" : <value>, "<field>" : <value>, ... },
    { "<field>" : <value>, "<field>" : <value>, ... },
    { "<field>" : <value>, "<field>" : <value>, ... },
    ...
  ]
}

A retire route record can have any of the following formats, depending on the network layer configuration and on the portion of route or routes being retired.

{
  "retireDate" : <date>,
  "routeId" : <routeId>,
  "fromMeasure" : <measure>,
  "toMeasure" : <measure>,
  "recalibrateRouteDownstream" : <bool> // defaults to true
}

or

{
// valid for networks that support lines.
  "retireDate" : <date>,
  "routeId" : <routeId>,
  "toRouteId" : <routeId>,
  "fromMeasure" : <measure>,
  "toMeasure" : <measure>,
  "recalibrateRouteDownstream" : <bool> // defaults to true
}

or

{
// retire an entire route
  "retireDate" : <date>,
  "routeId" : <routeId>
}

or

{
// If the network supports lines, retire all routes along the line between (and including) routeId and toRouteId.
  "retireDate" : <date>,
  "routeId" : <routeId>,
  "toRouteId" : <routeId>
}

A delete routes record has the following format. The routeIds object must contain one or more route Ids to be deleted. The deleteCenterlines, deleteEvents, & deleteCalibrationPoints objects are optional and default to false if omitted

{ 
  "routeIds": ["<routeId1>", "<routeId2>", "<routeId3>", …],
  "deleteCenterlines" : true,
  "deleteEvents" : true,
  "deleteCalibrationPoints" : true
}

Editing Calibration Point Layer

A calibration point layer can receive a set of add, update, and delete records. These edits must be performed separately and should not be combined with network (route) or event edits.

Syntax for calibration point layer edits:

[
  {
    "id" : <calibrationPointLayerId>,
    "addCalibrationPoints" : [<record1>, <record2>, <record3>, ...],
    "updateCalibrationPoints" : [<record1>, <record2>, <record3>, ...],
    "deleteCalibrationPoints" : [<record1>, <record2>, <record3>, ...]
  },
  ...
]

An add calibration point record:

{
  "networkLayerId" : <networkLayerId>,
  "routeId" : <routeId>,
  "geometry" : { "x" : <x>, 
    "y" : <y>, 
    "spatialReference" : <spatialReference>
  },
  "fromDate" : <fromDate>, // date value
  "measure" : <measure>,
  "toDate" : <toDate>, // date value
  "recalibrateRouteDownstream" : <recalibrateRouteDownstream> // boolean value
}

An update calibration point record has the following format. Each record must contain at least an Object Id attribute value to update a calibration point. Although the attribute values for From Date, To Date, Measure, and Recalibrate Route Downstream are optional, at least one attribute value must be passed along with the Object Id attribute.

{
  "objectId" : <objectId>,
  "fromDate" : <fromDate>,  // date value
  "toDate" : "<toDate>", // date value
  "measure" : <measure>,
  "recalibrateRouteDownstream" : <recalibrateRouteDownstream> // boolean value
}

A delete calibration point record has the following format. Each record must contain at least an Object Id attribute value to delete a calibration point.

{
  "objectId" : <objectId>
}

Editing Centerline Layer

A centerline layer supports splitting a centerline at a specific location. These edits must be performed separately and should not be combined with network (route), event edits, or calibration point edits.

Syntax for centerline layer edits:

[
  {
    "id": <centerlineLayerId>,
    "splitCenterline": <record>
  },
  ...
]

A splitCenterline record has the following format.

{
  "objectId": oid,
  "geometry": {"x":<x>,
    "y":<y>,
    "spatialReference":<spatialReference>
 }
}

A splitCenterlinesIntoSingleparts record has the following format. This API separates the component parts of a multipart feature into singlepart features while maintaining the underlying network to centerline relationship.

{
  "objectIds": [<oid1>, <oid2>, ..]
}
gdbVersion

Description: Optional parameter to specify the geodatabase version to use. If this parameter is not specified, the published map's version is used.

Syntax: gdbVersion=<version>

Example: gdbVersion="user1.version1"

returnEditMoment

Description: Optional parameter to specify whether the response will report the time edits that were applied. If returnEditMoment=true, the server will return the time edits that were applied in the response's editMoment key. The default value for this parameter is false.

Values: true|false

This parameter was added at 10.6.1.

sessionId

Description: Optional parameter set by a client during long transaction editing on a branch version. The sessionId parameter value is a GUID that clients establish at the beginning and use throughout the edit session. The sessonId parameter ensures isolation during the edit session.

Syntax: sessionId=<guid>

Example: sessionId="{E81C2E2D-C6A7-40CB-BF61-FB499E53DD1D}"

This parameter was added at 10.6.1.

returnServiceEditsOption

Description: Optional parameter that returns features edited due to the geodatabase behavior that results from applying the edits. For example, if a feature is deleted and it is the origin in a composite relationship, the destination feature is automatically deleted from the geodatabase. If returnServiceEditsOption is set to originalAndCurrentFeatures, the deleted destination feature is returned along with a reference to the deleted origin feature in the response. Note that, even for deletes, the geometry and attributes of the edited feature are returned.

Results returned from applyEdits are organized layer by layer. If returnServiceEditsOption is set to originalAndCurrentFeatures, each layer may have edited features returned in an editedFeatures object.

Service-level applyEdits response structure:

[
  {
    id
    addResults
    updateResults
    deleteResults
    attachments: {
      addResults
      updateReults
      deleteResults
    }
    editMoment
    editedFeatures
    exceededTransferLimit
  },
  {
  ...
  }
]

The editedFeatures object returns full features, including the original features prior to delete, the original and current features for updates, and the current rows for inserts that may contain implicit changes (for example, as a result of a calculation rule).

editedFeatures response structure:

{
  "editedFeatures": [
    {
      "adds": [ <feature1>, <feature2>], 	// current features
      "updates": [[<originalFeature3>, < currentFeature3>], [<originalFeature4>, < currentFeature4>]],
      "deletes": [ <feature5>, <feature6>]	// original features
    },
  ]
}

The response includes no editedFeatures values and exceededTransferLimit=true if the count of edited features to return is more than the maxRecordCount value. If clients are using this parameter to maintain a cache, they should invalidate the cache when exceededTransferLimit=true is returned. If the server encounters an error when generating the list of edits in the response, exceededTransferLimit=true is also returned.

Edited features are returned in the spatial reference of the feature service as defined by the services spatialReference object or by the spatialReference value of the layers extent object.

The default for this parameter is none, which does not include editedFeatures values.

Values: none|originalAndCurrentFeatures

This parameter was added at 10.6.1.

Example usage

The following examples demonstrate how to add events to an event layer.

Example 1

URL for adding new events to a point event layer.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":1,"adds":[{"attributes":{"route_id":"I90","event_id":"ABC123","meas":48.5}}]}]

Example 2

URL for adding new events to a linear event layer.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"adds":[{"attributes":{"RouteID":"US101","EventID":"ABC123","FromMeasure":20,"ToMeasure":25.75}}]}]

Example 3

URL for adding new events with a temporal view date range.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":3,"adds":[{"attributes":{"ROUTEID":"SR85","EVENTID":"ABC123","MEAS":35,"FROM_DATE":1230768000000,"TO_DATE":1262304000000}}]}]

Example 4

URL for adding new events with measure merging.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"allowMerge":true,"adds":[{"attributes":{"RouteID":"US101","EventID":"ABC123","Pavement":"concrete","FromMeasure":20,"ToMeasure":25.75}}]}]

Example 5

URL for adding new events with measure overlap retirement.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"retireMeasureOverlap":true,"adds":[{"attributes":{"RouteID":"US101","EventID":"ABC123","FromMeasure":20,"ToMeasure":25.75}}]}]

Example 6

URL for adding new events with referent locations.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"allowMerge":true,"retireMeasureOverlap":true,"adds":[{"attributes":{"RouteID":"US101","EventID":"ABC123","SpeedLimit":65,"FromMeasure":20,"ToMeasure":25.75,"FromRefMethod":12,"FromRefLocation":"{E9A2157D-DFD5-4696-943F-B35DD77C0BBE}","FromRefOffset":"125","ToRefMethod":20,"ToRefLocation":"{C061ECEC-C0BA-462D-BB73-DA175EAEFBD2}","ToRefOffset":"-50.3"}}]}]

Example 7

URL for updating events by WHERE clause.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"updates":[{"where":"Pavement = 'asphalt' and LaneCount = 2","attributes":{"LastPaved":1262304000000}}]}]

Example 8

URL for updating events by event ID.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"updates":[{"eventId":"ABC123","attributes":{"FromMeasure":42.5,"ToDate":null}}]}]

Example 9

URL for deleting events by WHERE clause.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":2,"deletes":[{"where":"RouteType = 'IN' and LaneCount < 3"}]}]

Example 10

URL for deleting events by event ID.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":4,"deletes":[{"eventId":500},{"eventId":501}]},{"id":1,"deletes":[{"eventId":"ABC123"}]}]

Example 11

URL for adding calibration points.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id" : 0, "addCalibrationPoints" : [{ "networkLayerId": 2, "routeId": "US101", "fromDate": 1520318060000, "geometry": { "x":34, "y": 117}, "measure": 101 }] }]

Example 12

URL for updating calibration points.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id" : 0, "updateCalibrationPoints" : [{ "objectId": 777, measure: 107 }] }]

Example 13

URL for deleting calibration points.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id" : 0, "deleteCalibrationPoints" : [{ "objectId": 777}] }]

Example 14

URL for splitting a centerline.

Note:

Centerlines cannot be split at endpoints.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":7,"splitCenterline":{"objectId":14166,"geometry":{"x":1276002.55695067,"y":12351516.6711279},"spatialReference":{ "wkid": 102013}}}]

Example 15

URL for splitting centerlines into singlepart features.

https://sampleserver/arcgis/rest/services/MyLRS/MapServer/exts/LRServer/applyEdits?f=json&edits=[{"id":7,"splitCenterlinesIntoSingleparts":{"objectIds":[14166,14177]}}]

JSON Response syntax

Example of a successful response.

{
  "success" : true
}

If an error occurs, the operation fails and rolls back, for example, if any line (or route) that the user is editing has a lock.

{
  "error" : { "code" : <errorCode>, "message" : "<errorMessage>" }, 
  "missingLocks" : 
    {"networkId" : "<networkId>", "routeId" : "<routeId>"}, | 
    {"networkId" : "<networkId>", "lineId" : "<lineId>"}, ...  }
}

Example of a successful split centerline response.

Note:

In 10.9 or later, this result is an array of new centerline object ids that were created as part of the split operation. In prior releases, the response format had a single objectId.

{
  "objectIds": [newCenterlineOID1, newCenterlineOID2 …]     
}