Apply Edits

f

(Optional)

Specifies the response format. The default response format is html.

Values: html | json | pjson

edits

(Required)

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.

• Event layer

  An event layer can receive a set of add, update, and delete records, a split event record, and a merge events record.

  Event records contain 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 whether 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 whether 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 records 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:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  [
    {
      "id": <eventLayerId>,
      "allowMerge": <true | false>,
      "retireMeasureOverlap": <true | false>,
      "retireByEventId": <true | false>,
      "adds": [ <record1>, <record2>, ... ],
      "updates": [ <record1>, <record2>, ... ],
      "deletes": [ <record1>, <record2>, ... ],
      "splitEvent": <record>,
      "mergeEvents": <record>
    },
    {
      "id": <eventLayerId>,
      "allowMerge": <true | false>,
      "retireMeasureOverlap": <true | false>,
      "retireByEventId": <true | false>,
      "adds": [ <record1>, <record2>, ... ],
      "updates": [ <record1>, <record2>, ... ],
      "deletes": [ <record1>, <record2>, ... ],
      "splitEvent": <record>,
      "mergeEvents": <record>
    },
    ...
  ]

  An add event record has the format shown below. 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 Measure and To Measure values. Attribute names are case sensitive.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  {
    "attributes": {
      "<field1>": <value1>,
      "<field2>": <value2>,
      ...
    }
  }

  An update event record has the format shown below. 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 can 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.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  {
    "eventId": <eventId>,  // string or number value
    "fromDate": <fromDate>,  // date value
    "where": "<whereClause>",
    "attributes": {
      "<field1>": <value1>,
      "<field2>": <value2>,
      ...
    }
  }

  A delete event record has the format shown below. 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 can be specified to uniquely identify a single record to delete out of all the temporal records for a given eventId.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  {
    "eventId": <eventId>,  // string or number value
    "fromDate": <fromDate>,  // date value
    "where": "<whereClause>"
  }

  A split event record has the format shown below. The record must contain the objectId, measure, and fromDate properties. The routeId property is optional for non-spanning events and is required for spanning events. The toDate property is optional and is assumed null if not specified. The attributes and attributes2 objects are optional and should contain attribute values for the two new event records after the split. Attribute names are case sensitive.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  {
    "objectId": <objectId>,  // string or number value
    "routeId": <routeId>,  // string value
    "measure": <measure>,  // double value
    "fromDate": <fromDate>,  // date value
    "toDate": <toDate>,  // date value
    "attributes": {
      "<field1>": <value1>,
      "<field2>": <value2>,
      ...
    },
    "attributes2": {
      "<field1>": <value1>,
      "<field2>": <value2>,
      ...
    }
  }

  A merge event record has the format shown below. The record must contain objectIds, objectIdToPreserve, fromDate, and toDate properties. The toDate property is optional and is assumed null if not specified. The attributes object is optional and should contain attribute values for the new event record after merge. If attributes object is not provided, attributes of the preserve event will be used. Attribute names are case sensitive.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  {
    "objectIds": [<objectId1>, <objectId2>, ...], // two or more object IDs to merge
    "objectIdToPreserve": <objectId>,  // object ID of preserve event
    "fromDate": <fromDate>,  // date value
    "toDate": <toDate>,  // date value
    "attributes": {
      "<field1>": <value1>,
      "<field2>": <value2>,
      ...
    }
  }

• Network layer

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

  Syntax for network layer edits:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  [
    {
      "id": <networkLayerId>,
      // include only one of the following record types:
      "createRoute": <record>
      "extendRoute": <record>
      "realignRoute": <record>
      "reassignRoute": <record>
      "retireRoute": <record>
      "deleteRoutes": <record>
      "reverseRoute": <record>
      "renameRoute": <record>
    },
    {
      "id": <networkLayerId>,
      // include only one of the following record types:
      "createRoute": <record>
      "extendRoute": <record>
      "realignRoute": <record>
      "reassignRoute": <record>
      "retireRoute": <record>
      "deleteRoutes": <record>
      "reverseRoute": <record>
      "renameRoute": <record>
    },
    ...
  ]

  A create route record has the format shown below. The attributes object must include a route name and can optionally include route from and to dates, and any other fields from the network layer except 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. Optionally, the flippedCenterlineObjectIds object includes a list of centerline object IDs to reverse its direction in memory.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  {
    "centerlineObjectIds": [<objectId1>, <objectId2>, ...],
    "flippedCenterlineObjectIds": [<objectId2>, ...],
    "fromMeasure": <measure>,
    "toMeasure": <measure>,
    "attributes": {
      "<fieldName1>": <value1>,
      "<fieldName2>": <value2>,
      ...
    }
  }

  An extend route record has the format shown below. The newRouteAttributes object must include a route name and can optionally include any other fields from the network layer except route ID, line ID, line name, line order, from date, and to date. Those fields are automatically derived from other request properties and from the route being edited. Optionally, the flippedCenterlineObjectIds object includes a list of centerline object IDs to reverse its direction in memory.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  {
    "effectiveDate": <date>,
    "centerlineObjectIds": [<objectId1>, <objectId2>, ...],
    "flippedCenterlineObjectIds": [<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 formats shown below, 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. Optionally, the flippedCenterlineObjectIds object includes a list of centerline object IDs to reverse its direction in memory.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  {
  // valid for networks that do not support lines
    "effectiveDate": <date>,
    "centerlineObjectIds": [<objectId1>, <objectId2>, ...],
    "flippedCenterlineObjectIds": [<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>, ...],
    "flippedCenterlineObjectIds": [<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 format shown below. The sourceToRouteId property is only applicable for networks that support lines. If sourceToRouteId is not provided, it is assumed that sourceRouteId and sourceToRouteId values are the same.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  {
    "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 routes
    "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 formats shown below, depending on the network layer configuration and on the portion of route or routes being retired.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  {
    "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 format shown below. 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.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  {
    "routeIds": ["<routeId1>", "<routeId2>", "<routeId3>", ...],
    "deleteCenterlines": true,
    "deleteEvents": true,
    "deleteCalibrationPoints": true
  }

  A reverse route record has the format shown below:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  {
    // reverse an entire route
    "effectiveDate": <date>
    "routeId": <routeId1>
  }

  A rename route record has the format shown below:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  {
    // rename by route name
    "existingRouteOrLineName": <routeName>
    "newRouteOrLineName": <lineName>
    "isLineName": false
  }
  
  or
  
  {
    // rename by line name
    "existingRouteOrLineName": <lineName>,
    "newRouteOrLineName": <lineName>,
    "isLineName": true
  }

• 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:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  [
    {
      "id": <calibrationPointLayerId>,
      "addCalibrationPoints": [<record1>, <record2>, <record3>, ...],
      "updateCalibrationPoints": [<record1>, <record2>, <record3>, ...],
      "deleteCalibrationPoints": [<record1>, <record2>, <record3>, ...]
    },
    ...
  ]

  An add calibration point record has the format shown below:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  {
    "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
    "retire": <retire> // boolean value. defaults to false
  }

  An update calibration point record has the format shown below. 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.

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  {
    "objectId": <objectId>,
    "fromDate": <fromDate>,  // date value
    "toDate": "<toDate>", // date value
    "measure": <measure>,
    "recalibrateRouteDownstream": <recalibrateRouteDownstream> // boolean value
  }

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

  Use dark colors for code blocksCopy

  1
  2
  3
  {
    "objectId": <objectId>
  }

• 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, or calibration point edits.

  Syntax for centerline layer edits:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  [
    {
      "id": <centerlineLayerId>,
      "splitCenterline": <record>
    },
    ...
  ]

  A splitCenterline record has the format shown below:

  Use dark colors for code blocksCopy

  1
  2
  3
  4
  5
  6
  7
  {
    "objectId": oid,
    "geometry": {"x":<x>,
      "y":<y>,
      "spatialReference":<spatialReference>
  }
  }

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

  Use dark colors for code blocksCopy

  1
  2
  3
  {
    "objectIds": [<oid1>, <oid2>, ..]
  }

gdbVersion

Specifies the geodatabase version to use. If this parameter is not specified, the published map's version is used.

Syntax:

1
gdbVersion=<version>

Example:

1
gdbVersion="user1.version1"

returnEditMoment

Specifies whether the response reports the time edits that were applied. If returnEditMoment is set to true, the server returns the time edits that were applied in the response's editMoment key. The default value is false.

Values: true | false

sessionId

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:

1
sessionId=<guid>

Example:

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

returnServiceEditsOption

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 original feature in the response. Note that, even for deletions, 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 can have edited features returned in an editedFeatures object.

Service-level applyEdits response structure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[
  {
    id
    addResults
    updateResults
    deleteResults
    attachments: {
      addResults
      updateReults
      deleteResults
    }
    editMoment
    editedFeatures
    exceededTransferLimit
  },
  {
  ...
  }
]

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

editedFeatures response structure:

1
2
3
4
5
6
7
8
9
{
  "editedFeatures": [
    {
      "adds": [ <feature1>, <feature2>], 	// current features
      "updates": [[<originalFeature3>, < currentFeature3>], [<originalFeature4>, < currentFeature4>]],
      "deletes": [ <feature5>, <feature6>]	// original features
    },
  ]
}

The response includes no editedFeatures values and exceededTransferLimit as 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 is returned as true. If the server encounters an error when generating the list of edits in the response, exceededTransferLimit is returned as true.

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 value is none, which does not include editedFeatures values.

Values: none | originalAndCurrentFeatures