Skip To Content
ArcGIS Developers
Dashboard

Append Events

Description

License:

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

This operation appends event records from a table, layer, or feature class into an existing Location Referencing event feature class.

Note:

Validation results for this tool are written to the ArcGIS Server directory. This file is automatically cleaned up using default 10 minute intervals, which may not be enough time to process all of the validations and write them to the workstation that is running ArcGIS Pro. For larger data loads, it is recommended that you adjust the maximum file age to at least one hour.

Request parameters

ParameterDetails
f

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

Values: html | json

uploadItemId

Description: The item ID of the uploaded source event table. The item ID is generated when the source event table is uploaded to the server.

The file geodatabase must be zipped before upload and must contain only one source table. The following hierarchy must be maintained in the zip archive:

|--<filename>.zip
    |--<filename>.gdb
        |--Source event table

Syntax: uploadItemId=<guid>

Example: uploadItemId="idec5bf57-1649-44ce-bac1-19bd0872a026"

fieldMap

Description: Specifies how the attribute information in the fields of the source is transferred to the target event layer.

Syntax: fieldMap=[{"sourceField":"<field name>","targetField":"<field name>"},{"sourceField":"<field name>","targetField":"<field name>"}, ...]

Example: fieldMap=[{"sourceField":"SourceFieldName1","targetField":"TargetFieldName1"},{"sourceField":"SourceFieldName1","targetField":"TargetFieldName1"}, ... ]

loadType

Description: Specifies how appended events with measure or temporality overlaps of identical Event IDs as Target Event records are loaded into the event feature class.

  • add—Appends the Input Event records to the Target Event. No changes are made to Target Event records.
  • retireOverlaps—Appends the Input Event records to the Target Event and retires any records in the Target Event with measure or temporality overlaps as the appended events. If the appended event eclipses the Target Event, the Target Event is deleted. Use this option for linear events only.
  • retireByEventId—Appends the Input Event records to the Target Event and retires any records in the Target Event that have the same Event ID and temporality overlaps as the appended events. If the appended event eclipses a Target Event with the same Event ID, the Target Event is deleted.
  • replaceByEventId—Appends the Input Event records to the Target Event and deletes any records in the Target Event that have the same Event ID as the appended events.

Values: add | retireOverlaps | retireByEventId | replaceByEventId

generateEventIdGuid

Description: Optional parameter to specify whether to generate event IDs for source event records being appended. Generation of event IDs will only be applied to source event records with a Null value for the Event ID field.

Values: true | false

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"

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

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

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

Example usage

The following URL adds event records in the target event from the source table:

https://sampleserver/server/rest/services/LRSService/MapServer/exts/LRServer/eventLayers/2/appendEvents?returnServiceEditsOption=originalAndCurrentFeatures&returnEditMoment=true&uploadItemId=ifbfbd4e2-f09e-4924-b33e-1341b9f593ea&fieldMap=[{"sourceField":"SourceFieldName1","targetField":"TargetFieldName1"},{"sourceField":"SourceFieldName1","targetField":"TargetFieldName1"}]&loadType=add&f=json&gdbVersion=userTest.versionx&sessionId={35B712BC-554E-49EC-8081-7E254569340F}

JSON Response syntax

Query this job URL to get progress updates and results of the operation.

{
  "statusURL": "<jobIdURL>"
}

JSON Response example

The following example demonstrates a successful response that returns a statusURL:

{
  "statusURL": "https://sampleserver/arcgis/rest/services/LRSService/MapServer/exts/LRServer/jobs/j0c1381f58c9a49e982ee2c3e1634c09b"
}