Helper classes for managing feature layers and datasets. These class are not created by users directly.
Instances of this class, are available as a properties of feature layers and make it easier to manage them.

Manager class for manipulating feature layer attachments. This class is not created by users directly.
An instance of this class, called ‘attachments’, is available as a property of the FeatureLayer object,
if the layer supports attachments.
Users call methods on this ‘attachments’ object to manipulate (create, get, list, delete) attachments.

The search method allows querying the layer for its attachments and returns the results as
a Pandas DataFrame or dict

Arguement

Description

where

required string. The definition expression to be applied to
the related layer/table. From the list of records that are
related to the specified object Ids, only those records that
conform to this expression will be returned.

Example: where=”STATE_NAME = ‘Alaska’”.
The query results will return all attachments in Alaska.

object_ids

optional list/string. The object IDs of this layer/table to be
queried.

Syntax: objectIds=<objectId1>,<objectId2>

Example: objectIds=2. The query results will return attachments
only for the specified object id.

Manager class for manipulating replicas for syncing disconnected editing of feature layers.
This class is not created by users directly.
An instance of this class, called ‘replicas’, is available as a property of the FeatureLayerCollection object,
if the layer is sync enabled / supports disconnected editing.
Users call methods on this ‘replicas’ object to manipulate (create, synchronize, unregister) replicas.

The create operation is performed on a feature layer collection
resource. This operation creates the replica between the feature
dataset and a client based on a client-supplied replica definition.
It requires the Sync capability. See Sync overview for more
information on sync. The response for create includes
replicaID, replica generation number, and data similar to the
response from the feature layer collection query operation.
The create operation returns a response of type
esriReplicaResponseTypeData, as the response has data for the
layers in the replica. If the operation is called to register
existing data by using replicaOptions, the response type will be
esriReplicaResponseTypeInfo, and the response will not contain data
for the layers in the replica.

Inputs:

replica_name - name of the replica
layers - layers to export
layer_queries - In addition to the layers and geometry parameters, the layer_queries

parameter can be used to further define what is replicated. This
parameter allows you to set properties on a per layer or per table
basis. Only the properties for the layers and tables that you want
changed from the default are required.
Example:

geometry_filter - spatial filter from arcgis.geometry.filters module to filter results by a

spatial relationship with another geometry

replica_sr - the spatial reference of the replica geometry.
transport_type - The transport_type represents the response format. If the

transport_type is esriTransportTypeUrl, the JSON response is contained in a file,
and the URL link to the file is returned. Otherwise, the JSON object is returned
directly. The default is esriTransportTypeUrl.
If async is true, the results will always be returned as if transport_type is
esriTransportTypeUrl. If dataFormat is sqlite, the transportFormat will always be
esriTransportTypeUrl regardless of how the parameter is set.
Values: esriTransportTypeUrl | esriTransportTypeEmbedded

return_attachments - If true, attachments are added to the replica and returned in

the response. Otherwise, attachments are not included. The default is false. This
parameter is only applicable if the feature service has attachments.

return_attachments_databy_url - If true, a reference to a URL will be provided for

each attachment returned from create method. Otherwise, attachments are embedded
in the response. The default is true. This parameter is only applicable if the
feature service has attachments and if return_attachments is true.

asynchronous - If true, the request is processed as an asynchronous job, and a URL is

returned that a client can visit to check the status of the job. See the topic on
asynchronous usage for more information. The default is false.

attachments_sync_direction - Client can specify the attachmentsSyncDirection when

creating a replica. AttachmentsSyncDirection is currently a createReplica property
and cannot be overridden during sync.
Values: none, upload, bidirectional

sync_model - this parameter is used to indicate that the replica is being created for

per-layer sync or per-replica sync. To determine which model types are supported by a
service, query the supportsPerReplicaSync, supportsPerLayerSync, and supportsSyncModelNone
properties of the Feature Service. By default, a replica is created for per-replica sync.
If syncModel is perReplica, the syncDirection specified during sync applies to all layers
in the replica. If the syncModel is perLayer, the syncDirection is defined on a layer-by-layer
basis.

If syncModel is perReplica, the response will have replicaServerGen. A perReplica syncModel
requires the replicaServerGen on sync. The replicaServerGen tells the server the point
in time from which to send back changes. If syncModel is perLayer, the response will include
an array of server generation numbers for the layers in layerServerGens. A perLayer sync
model requires the layerServerGens on sync. The layerServerGens tell the server the point
in time from which to send back changes for a specific layer. sync_model=none can be used
to export the data without creating a replica. Query the supportsSyncModelNone property
of the feature service to see if this model type is supported.

data_format - The format of the replica geodatabase returned in the response. The

default is json.
Values: filegdb, json, sqlite, shapefile

replica_options - This parameter instructs the create operation to create a

new replica based on an existing replica definition (refReplicaId). It can be used
to specify parameters for registration of existing data for sync. The operation
will create a replica but will not return data. The responseType returned in the
create response will be esriReplicaResponseTypeInfo.

wait - if async, wait to pause the process until the async operation is completed.
out_path - folder path to save the file

Allows updating the definition (if access permits) of a feature layer collection.
This class is not created by users directly.
An instance of this class, called ‘manager’, is available as a property of the FeatureLayerCollection object.

Users call methods on this ‘manager’ object to manage the feature layer collection.

The add_to_definition operation supports adding a definition
property to a hosted feature layer collection service. The result of this
operation is a response indicating success or failure with error
code and description.

This function will allow users to change or add additional values
to an already published service.

Input:

json_dict - part to add to host service. The part format can

be derived from the properties property. For
layer level modifications, run updates on each
individual feature service layer object.

Creates a view of an existing feature service. You can create a view, if you need a different view of the data
represented by a hosted feature layer, for example, you want to apply different editor settings, apply different
styles or filters, define which features or fields are available, or share the data to different groups than
the hosted feature layer create a hosted feature layer view of that hosted feature layer.

When you create a feature layer view, a new hosted feature layer item is added to Content. This new layer is a
view of the data in the hosted feature layer, which means updates made to the data appear in the hosted feature
layer and all of its hosted feature layer views. However, since the view is a separate layer, you can change
properties and settings on this item separately from the hosted feature layer from which it is created.

For example, you can allow members of your organization to edit the hosted feature layer but share a read-only
feature layer view with the public.

be derived from the properties property. For
layer level modifications, run updates on each
individual feature service layer object. Only
include the items you want to remove from the
FeatureService or layer.

Overwrite all the features and layers in a hosted feature layer collection service. This operation removes
all features but retains the properties (such as metadata, itemID) and capabilities configured on the service.
There are some limits to using this operation:

Only hosted feature layer collection services can be overwritten

The original data used to publish this layer should be available on the portal

3. The data file used to overwrite should be of the same format and filename as the original that was used to
publish the layer
4. The schema (column names, column data types) of the data_file should be the same as original. You can have
additional or fewer rows (features).

In addition to overwriting the features, this operation also updates the data of the item used to published this
layer.

Parameters:

data – path to data_file used to overwrite the hosted feature layer collection

Returns:

JSON message as dictionary such as {‘success’:True} or {‘error’:’error message’}

The update_definition operation supports updating a definition
property in a hosted feature layer collection service. The result of this
operation is a response indicating success or failure with error
code and description.

Input:

json_dict - part to add to host service. The part format can

be derived from the properties property. For
layer level modifications, run updates on each
individual feature service layer object.

Allows updating the definition (if access permits) of a feature layer. This class is not created by users
directly.
An instance of this class, called ‘manager’, is available as a property of the FeatureLayer object,
if the layer can be managed by the user.
Users call methods on this ‘manager’ object to manage the feature layer.

be derived from the asDictionary property. For
layer level modifications, run updates on each
individual feature service layer object. Only
include the items you want to remove from the
FeatureService or layer.

Creates a FeatureLayerManager object from a GIS Item.
The type of item should be a ‘Feature Service’ that represents a FeatureLayerCollection.
The layer_id is the id of the layer in feature layer collection (feature service).

The updateDefinition operation supports updating a definition
property in a hosted feature layer. The result of this
operation is a response indicating success or failure with error
code and description.

Input:

json_dict - part to add to host service. The part format can

be derived from the asDictionary property. For
layer level modifications, run updates on each
individual feature service layer object.

VersionManager allows users to manage the branch versioning for FeatureLayerCollection
services. The Version Management Service is responsible for exposing the management
capabilities necessary to support feature services that work with branch versioned
datasets.

For the specified feature service, return the info of all versions
that the client has access to. If the client is the service owner
(the user that published the service), all versions are accessible
and will be returned.

Argument

Description

owner

Optional String. A filter the versions by the owner.

show_hidden

Optional Boolean. If False (default) hidden versions will not be
returned.

The `conflicts` operation allows you to view the conflicts by layer
and type (update-update, update-delete, delete-update) that were
identified during the last Reconcile operation. The features that
are in conflicts will also be returned as they existed in the branch,
ancestor, and default versions.

If the input moment does not match a specific moment (a moment
corresponding to an edit operation), the call will return an error.
The client app must correctly manage the edit session’s edit
operations moments (for example, the undo/redo stack) and not
blindly pass in a timestamp that could mistakenly delete all the
forward moments. Thus, the input moment must be equal to a moment
in which an edit operation for the version was applied. The call
will also fail if the session does not have a write lock on the
version.

Argument

Description

moment

Required String. Moment representing the new tail of the version;
all forward moments will be trimmed.

The edit operation allows users to apply changes to the current version. The edit
session must be in the mode of edit or an exception will be raised.

Inputs

Description

layer

Required FeatureLayer. The layer to perform
the edit on.

adds

Optional FeatureSet/List. The array of
features to be added.

updates

Optional FeatureSet/List. The array of
features to be updateded.

deletes

Optional FeatureSet/List. string of OIDs to
remove from service

use_global_ids

Optional boolean. Instead of referencing
the default Object ID field, the service
will look at a GUID field to track changes.
This means the GUIDs will be passed instead
of OIDs for delete, update or add features.

rollback_on_failure

Optional boolean. Optional parameter to
specify if the edits should be applied only
if all submitted edits succeed. If false, the
server will apply the edits that succeed
even if some of the submitted edits fail.
If true, the server will apply the edits
only if all edits succeed. The default
value is true.

The `inspect` operation allows the client to annotate conflicts
from the conflict set that was obtained during the last reconcile
operation. Users can mark the conflicts as being inspected;
additionally, a description or note can be associated with the
conflict.

Argument

Description

conflicts

Required List. The conflicts that are being inspected (removed)
from the conflict set.

Parameter Format:

[

{

“layerId” : <layerId>,
“features” : [

{

“objectId” : <objectId>,
“note” : string

}

]

}

]

The objectId key is required. The note parameter is optional.

inspect_all

Optional Boolean. This parameter, if true, will mark all conflicts
as being inspected.

set_inspected

Optional Boolean. If True, the examined values will be set to
inspected. If `inspect_all` is True, this parameter is ignored.

The Post operation allows the client to post the changes in their
branch to the default version. The client can only post changes if
the branch version has not been modified since the last reconcile.
If the default version has been modified in the interim, the client
will have to reconcile again before posting.

Reconcile a version against the DEFAULT version. The reconcile
operation requires that you are the only user currently editing the
version and the only user able to edit the version throughout the
reconcile process until you save or post. The reconcile operation
requires that you have full permissions to all the feature classes
that have been modified in the version being edited. The reconcile
operation detects differences between the branch version and the
default version and flags these differences as conflicts. If
conflicts exist, they should be resolved.

Argument

Description

end_with_conflict

Optional Boolean. Specifies if the reconcile should abort when
conflicts are found. The default is False

with_post

Optional Boolean. If True the with_post causes a post of the current
version following the reconcile.

For example, if a parcel polygon exists without lines, then build will
construct the missing lines. If lines are missing, the polygon row(s)
are created. When constructing this objects, build will attribute the
related keys as appropriate. Build also maintains lineage and record
features. The parcel fabric must have sufficient information for build
to work correctly. Ie, source reference document, and connected lines.

Build provides options to increase performance. The process can just
work on specific parcels, geometry types or only respond to parcel point
movement in the case of an adjustment.

Argument

Description

extent

Optional Envelope. The extent to build.

Syntax: {“xmin”:X min,”ymin”: y min, “xmax”: x max, “ymax”: y max,

“spatialReference”: <wkt of spatial reference>}

moment

Optional String. This should only be specified by the client when
they do not want to use the current moment

return_errors

Optional Boolean. If True, a verbose response will be given if errors
occured. The default is False

Changes a set of parcels to a new parcel type. It creates new
polygons and lines and deletes them from the source type. This
is used when a parcel was associated in the wrong parcel type subtype
and/or when creating multiple parcels as part of a build process.
Example: when lot parcels are created as part of a subdivision, the
road parcel is moved to the encumbrance (easement) parcel type.

Clip cuts a new child parcel into existing parent parcels. Commonly
it retires the parent parcel(s) it cuts into to generate a reminder
child parcel. This type of split is often part of a parcel split
metes and bounds record driven workflow.

Optional List. A list of child parcels that will be used to clip
into the parent parcels. Parcel lineage is created if the child
‘clipping_parcels’ and the parcels being clipped are of the same
parcel type.

Syntax: clippingParcels= < id : parcel guid, layered: <layer id>…>

Example:

[{“id”:”{D01D3F47-5FE2-4E39-8C07-E356B46DBC78}”,”layerId”:”16”}]

Either clipping_parcels or geometry is required.

geometry

Optional Polygon. Allows for the clipping a parcel based on geometry instead of
‘clippingParcels’ geometry. No parcel lineage is created.

Either clipping_parcels or geometry is required.

moment

Optional String. This should only be specified by the client when
they do not want to use the current moment

Copy lines to parcel type is used when the construction of the
child parcel is based on parent parcel geometry. It creates a
copy of the parent parcels lines that the user can modify (insert,
delete, update) before they build the child parcels. If the source
parcel type and the target parcel type are identical (common)
parcel lineage is created.

Merge combines 2 or more parent parcels into onenew child parcel. Merge
sums up legal areas of parent parcels to the new child parcel legal
area (using default area units as dictated by client). The child parcel
lines arecomposed from the outer boundaries of the parent parcels.
Merge can create multipart parcels as well as proportion lines (partial
overlap of parent parcels). Record footprint is updated to match the
child parcel.

Argument

Description

parent_parcels

Required String. It is the parcel(guid)+layer(name) identifiers to
merge.

target_parcel_type

Required String. Layer where parcel is merged to. History is
created when parents and child are of the same parcel type

attribute_overrides

Optional List. A list of attributes to set on the child parcel, if
they exist. Pairs of field name and value.

The Utility Network Service exposes analytic capabilities (tracing)
as well as validation of network topology and management of
subnetworks (managing sources, updating subnetworks, exporting
subnetworks, and so on). The Utility Network Service is conceptually
similar to the Network Analysis Service for transportation networks.

Inputs

Description

url

Required String. The web endpoint to the utility service.

version

Required Version. The Version class where the branch version will take place.

Network attributes support the ability to have their values
overridden without having to edit features and validate the network
topology (build the index). The utility network also supports the
ability to place ephemeral connectivity (for example, jumpers in an
electrical network) between two devices or junctions without having
to edit features or connectivity associations and validate the
network topology (build the index). When specified by the client, a
trace operation may optionally incorporate the network attribute
and connectivity override values when the trace is run on.

A subnetwork controller (or simply, a source or a sink) is the
origin (or destination) of resource flow for a subpart of the
network. Examples of subnetwork controllers are circuit breakers in
electric networks, or town border stations in gas networks.
Subnetwork controllers correspond to devices that have the
Subnetwork Controller network capability set. A source is removed
with disable_subnetwork_controller.

A subnetwork controller is the origin (or destination) of resource
flow for a subpart of the network (e.g., a circuit breaker in
electric networks, or a town border station in gas networks).
Controllers correspond to Devices that have the Subnetwork
Controller network capability set.

The export_subnetwork operation is used to export information
about a subnetwork into a JSON file. That information can then be
consumed by outside systems such as outage management and asset
tracking. The exportSubnetwork operation allows you to delete
corresponding rows in the Subnetwork Sources table as long as the
IsDeleted attribute is set to True. This indicates a source feeding
the subnetwork has been removed.

The query_network_moments operation returns the moments related
to the network topology and operations against the topology. This
includes when the topology was initially enabled, when it was last
validated, when the topology was last disabled (and later enabled),
and when the definition of the utility network was last modified.

Network attributes support the ability to have their values
overridden without having to edit features and validate the network
topology (build the index). The utility network also supports the
ability to place ephemeral connectivity (e.g., jumpers in an
electrical network) between two devices or junctions without having
to edit features or connectivity associations and validate the
network topology (build the index). This operation allows the
client to query all the overrides associated with the network
attributes (by network attribute id). In addition, all connectivity
overrides are returned.

The synthesize_association_geometries operation is used to export
geometries representing associations that are synthesized as line
segments corresponding to the geometries of the devices at the
endpoints. All features associated with an association must be in
the specified extent in order for the geometry to be synthesized.
If only zero or one of the devices/junctions intersects the extent,
then no geometry will be synthesized.

A trace refers to a pre-configured algorithm that systematically
travels a network to return results. Generalized traces allow you to
trace across multiple types of domain networks. For example, running
a Connected trace from your electric network through to your gas
network. An assortment of options is provided with trace to support
various analytic work flows. All traces use the network topology to
read cached information about network features. This can improve
performance of complex traces on large networks. Trace results are
not guaranteed to accurately represent a utility network when dirty
areas are present. The network topology must be validated to ensure
it reflects the most recent edits or updates made to the network.

Utility network features have an attribute called IsConnected that
lets you know if a feature is connected to a source or sink, and
therefore it could potentially be part of an existing subnetwork.
The update_is_connected operation updates this attribute on
features in the specified utility network. This operation can only
be executed on the default version by the portal utility network
owner.

A subnetwork is updated by calling the update_subnetwork operation.
With this operation, one or all of the subnetworks in a single tier
can be updated. When a subnetwork is updated, four things can occur;
the Subnetwork Name attribute is updated for all features in the
subnetwork, the record representing the subnetwork inside the
SubnetLine class is refreshed, the Subnetworks table is updated and
finally diagrams are generated or updated for the subnetwork.

Validating the network topology for a utility network maintains
consistency between feature editing space and network topology space.
Validating a network topology may include all or a subset of the
dirty areas present in the network. Validation of network topology
is supported synchronously and asynchronously.