一般的に、Web フィーチャ レイヤーは、他のベクター データと同様に編集できます。 Web フィーチャ レイヤーに対して行うことができる編集のタイプは、フィーチャ サービスのプロパティによって制御されます。 公開されるデータ、編集者権限、およびサービスで有効になる機能に応じて、さまざまな編集パターンがあります。 編集パターンに影響する機能には、バージョン管理機能があります。 公開者がブランチ バージョン対応データを公開するときにこの機能を有効にすると、編集者が ArcGIS AllSource の Web レイヤーを編集できる方法が変わります。
詳細については、フィーチャ サービスのエディター権限および追加レイヤーおよび追加機能をご参照ください。
バージョン管理を含まない Web レイヤーの編集
ほとんどの場合、ArcGIS AllSource で Web フィーチャ レイヤーを編集すると、バージョン管理機能が無効になります。 これらのフィーチャ レイヤーを編集する場合、実行されたほとんどの編集は、保存する前に ArcGIS AllSource が実行されているコンピューターのローカルに格納されます。 ArcGIS AllSource で用意されている元に戻すおよびやり直しオプションを使用して、編集を維持または破棄できます。 編集を保存または破棄するまで、個々の編集を元に戻すおよびやり直すことができます。
注意:
編集が保存または破棄されるまで、元に戻す操作とやり直し操作を含む更新と削除は、ローカルに保存されます。 フィーチャを挿入すると、フィーチャはすぐにフィーチャ サービスに追加され、ローカルに格納されます。
編集を保存または破棄
保存すると、最後に保存したタイミング以降に実施したすべての更新と削除が、一度に 1 つずつソース データに適用されます。 編集を破棄すると、ローカル コンピューターから編集内容が削除されます。 編集が破棄されると、削除がサーバーにも送信され、セッション中に実行された挿入が元に戻ります。
複数の編集をクライアント側に保存するため、編集を保存または破棄する操作に時間がかかる可能性があります。 また、編集が保存されるまで、サービスの他のユーザーに更新や削除が表示されなくなります。 編集を頻繁に保存するか、定期的に編集を保存するオプションをオンにすることをお勧めします。 このオプションを選択すると、時間間隔または特定の操作数に基づいて保存するようにアプリケーションを設定できます。 この設定により、データ ソースへの編集が定期的に自動保存され、保存操作にかかる時間も短くて済みます。 他のデータ ソースと同様、編集を保存すると元に戻せません。
サーバー側の編集動作に依存する機能は、編集セッションの間、遅延が生じたり、使用できなくなったりすることがあります。 このタイプの動作に関する例を次に示します。
- 編集セッションで作成されたリレーションシップ内での元から先への移動
- クライアント側の評価から除外された属性ルールに計算済みの値が表示されません
ワークフローでこれらの動作に即座にアクセスする必要がある場合や、他のユーザーが実行した編集を表示する必要がある場合には、編集を頻繁に保存するか、定期的に編集を保存するオプションをオンにすることをお勧めします。 遅延を回避するには、操作を行うたびに保存することもできます。 これらのサーバー側の動作を観察するために、マップの更新が必要になる場合があります。
注意:
挿入したフィーチャへの編集が保存される前に ArcGIS AllSource セッションが予期せず閉じた場合、これらの挿入したフィーチャを、後のセッションで手動で確認する必要があります。
バージョン管理を含む Web フィーチャ レイヤーの編集
公開者が Web フィーチャ レイヤーを公開する際に、バージョン管理機能を有効化した場合、この機能が存在しないフィーチャ レイヤーを編集する場合とは、編集ワークフローが異なります。 バージョン管理機能は、ブランチ バージョン対応のデータでのみ使用できます。
バージョン管理が有効になっている Web フィーチャ レイヤーを編集する場合は、デフォルト バージョンまたは名前付きバージョン (存在する場合) のいずれかを編集できます。 マップ内の名前付きバージョンにアクセスする方法については、ブランチ バージョンへの接続をご参照ください。
名前付きバージョンの編集と比較して、デフォルト バージョンの編集時には、いくつかの重要な違いがあります。 バージョン管理が有効になっているレイヤーを編集する場合、編集は、基となるデータ ソースに即座に保存されます。 名前付きバージョンを編集する場合、個々の編集を元に戻したりやり直したり、編集グループを保存または破棄したりできます。 元に戻す/やり直し、保存/破棄に関する機能は、デフォルト バージョンの編集時には使用できません。
名前付きバージョンでこれらの編集機能を提供するには、編集中のバージョンを他のエディターから分離する必要があります。 これを実現するため、ArcGIS AllSource はロック メカニズムを使用して、表示または編集しているバージョンへのアクセスを制限します。 ロック モデルにより、複数の同時閲覧者または 1 人の編集者によるアクセスを実現します。
- 1 人の編集者が名前付きバージョン内で編集を開始すると、排他ロックが取得されるため、それ以外のユーザーは、編集セッション中にそのバージョンに接続できなくなります。
- 編集者が名前付きバージョンの編集を開始する時点で、そのバージョンに接続している唯一のユーザーである必要があります。
名前付きバージョンを作成する際は、バージョン アクセス権限をプライベートに設定することで、このようなブロック状態を回避できます。
追加の編集動作
バージョン管理機能に関する上記の動作と同様に、サービスとレイヤーのプロパティに基づいて、追加の編集動作が表示されます。 これらの動作を使用する目的は、ファイル サイズの制限や処理時間に起因する編集の失敗を減らすことです。
非同期の編集の適用を使用したアップロード
編集内容がどのようにサーバーに通知されるかは、supportsApplyEditsbyUploadID と supportsAsyncApplyEdits という 2 つのプロパティによって決まります。 サービスの supportsApplyEditsbyUploadID および supportsAsyncApplyEdits プロパティが true に設定されている場合、ArcGIS AllSource は、applyEdits 操作を使用して編集を実行するときに、アップロードおよび非同期処理を利用する可能性があります。 applyEdits にアップロードおよび非同期処理を使用するかどうかの決定には、下記のアルゴリズムが使用されます。
upload の使用には、リクエスト サイズが使用されます。 リクエスト サイズは、リクエストのペイロード サイズと推定の URL エンコーディング サイズによって決まります。 リクエスト サイズが 6 MB を超える場合、upload が使用されます。 このアップロード プロセスの目的は、編集ペイロードを 1 つのファイルにパッケージ化し、個別のアイテム ID でアップロードすることによって、タイムアウトを減らすことです。 その後、アップロードのアイテム ID が applyEdits 呼び出しによって参照され、サービス編集内容が適用されます。
ファイルのアップロードの詳細については、アップロードをご参照ください。
非同期の applyEdits を使用した場合には、編集を実行するために必要となった applyEdits サービス リクエストごとに、コストが計算されます。 この計算では、編集されるレコード数と編集のペイロード サイズが考慮されます。 これらの値が、以下の式で使用されます。
1 + (レコード数 / 1000) + (ペイロード サイズ (MB) / 6 MB)結果の値は、整数値に四捨五入されます。 この四捨五入された値が 3 以上である場合、applyEdits 呼び出しは、非同期に実行されます。 四捨五入された値が 3 未満である場合、applyEdits 呼び出しは、同期実行されます。
非同期の applyEdits の詳細については、編集の適用をご参照ください。