ArcMap のオブジェクト ローダーを使用するかそれとも ArcCatalog または [カタログ] ウィンドウのシンプル データ ローダーを使用するかを決める際には、考慮すべき点がいくつかあります。最も重要なのは時間です。シンプル データ ローダーは、データを読み込むときに整合のチェックやチェックに伴う処理を行わないため、オブジェクト ローダーよりも高速です。一方で、時間的な制約がない場合は、オブジェクト ローダーを使用するほうが効果的です。オブジェクト ローダーでは、ジオメトリック ネットワーク、フィーチャリンク アノテーション、リレーションシップのフィーチャクラスを読み込むことができます。スタンドアロンのテーブル内に読み込む唯一の方法は、シンプル データ ローダーを使用することです。
ジオメトリック ネットワークへの読み込み
時間的な制約がある場合は、オブジェクト ローダーを使用して大量のデータをネットワーク フィーチャに読み込むと、処理に時間がかかる可能性があることを考慮する必要があります。複数のフィーチャクラスで構成される大きなネットワークでは、特に時間がかかります。このため、ネットワークを一から作成している場合は、ネットワークを構築する前に、シンプル データ ローダーを使用してすべてのデータを読み込む方が効果的です。すでにネットワークを構築している場合は、オブジェクト ローダーを使用する代わりに、ジオメトリック ネットワークを削除し、シンプル データ ローダーを使用してデータをフィーチャクラスに読み込んだ後、ネットワークを再構築することで、時間を節約できる場合があります。
バージョン対応のフィーチャクラスとテーブルへの読み込み
バージョン対応のフィーチャクラスとテーブルへの読み込みについても、バージョン対応でないフィーチャクラスやテーブルへの読み込みよりも時間がかかります。データをジオデータベースに移行する場合は、データをバージョン対応登録する前に読み込むことが推奨されます。データとアプリケーションのジオデータベースへの移行が完了したら、フィーチャクラスとテーブルをバージョン対応登録します。バージョン対応登録後は、フィーチャクラスとテーブルに自由に更新を行うことができます。
データがすでにバージョン対応登録されていて、バージョン対応のフィーチャクラスにデータを読み込む必要がある場合に最も簡単な方法は、オブジェクト ローダーを使用することです。ArcMap の編集セッションで読み込むと、変更内容がマージされ、新たに読み込んだフィーチャを保存する前に、他の編集内容を確認することができます。また、必要に応じて、ArcMap の競合解決機能を利用することもできます。
ただし、複数のフィーチャを読み込む必要があるが、時間的な制約が存在する、という場合は、時間を節約するためのデータの準備方法があります。
- DEFAULT バージョンに対してデータベースの各未処理バージョンをリコンサイルしてポストします。ポストが完了した、各バージョンを削除します。
- 圧縮を実行して、データベースを圧縮します。
- データのバージョン対応登録を解除します。
- ジオメトリック ネットワークを削除します。
- ArcCatalog または [カタログ] ウィンドウのシンプル データ ローダーを使用して、新しいデータを既存のフィーチャクラスに読み込みます。
- ArcCatalog または [カタログ] ウィンドウのジオメトリック ネットワーク構築ウィザードを使用して、ジオメトリック ネットワークを再構築します。
- データをバージョン対応登録し、作業を続行します。データをバージョン対応登録すると、フィーチャクラスのデータベース統計が自動的に更新されます。
ヒント
- ネットワークに接続ポイントとカスタム トポロジを持つコンプレックス ジャンクション フィーチャが含まれている場合、ネットワークを再構築するバッチ プロセスではカスタム トポロジが再作成されないため、この方法を使用することはできません。
- ネットワークの再構築プロセスでは、ネットワークとの接続が切断されていたネットワーク フィーチャがすべて再接続されます。
- データを読み込むフィーチャクラスにフィーチャリンク アノテーションが関連付けられている場合、シンプル データ ローダーを使用することはできません。この場合は、オブジェクト ローダーを使用する必要があります。
- この方法には、一部のワークフローとの互換性がありません。DEFAULT バージョンへのリコンサイルおよびポストが不可能な未処理バージョンがある場合、この方法を使用することはできません。こうしたバージョンには、不完全である、ポストの準備が整っていない、または履歴バージョンである未処理のデザイン バージョンが含まれます。このような場合は、オブジェクト ローダーを使用して、編集セッションの一部としてデータを追加する必要があります。
シンプル データ ローダーまたはオブジェクト ローダーを使用すると、データは差分テーブルに読み込まれます。このため、バージョン対応登録されたフィーチャクラスまたはテーブルへのデータの読み込みが完了し、編集内容をベース テーブルに移行するオプションを選択していない場合は、各バージョンをデフォルトにリコンサイルしてからデータベースを圧縮し、デルタ テーブルのすべてのレコードをベース テーブルに移行します。データをベース テーブルに移行すると、デルタ テーブルに大量のデータが格納されている場合よりも、検索速度が向上します。
トポロジを持つフィーチャクラスへの読み込み
トポロジを作成する前にデータを読み込むと、トポロジに属するフィーチャクラスに新しいフィーチャを挿入するたびにダーティ エリアが作成されることがなくなります。データを読み込んだ後にトポロジを作成すると、すべてのフィーチャにまたがるダーティ エリアが 1 つ作成されます。このダーティ エリアは、「トポロジの整合性チェック」で説明されている手順に従って整合チェックできます。
トポロジを持つフィーチャクラスにデータを読み込む場合は、オブジェクト ローダーとシンプル データ ローダーのどちらかを使用することができます。ただし、どちらのツールもフィーチャの読み込み時にトポロジの整合チェックをしないので、最終的な結果は同じです。つまり、読み込みが完了したら、トポロジを明示的に整合チェックをする必要があります。
別の座標系からのデータの読み込み
読み込むデータが読み込み先のフィーチャクラスとは異なる座標系を使用しているとします。たとえば、NAD 1927 座標系を使用するフィーチャを、NAD 1983 座標系を使用するフィーチャクラスに読み込むような場合です。このような場合には、フィーチャを読み込む前に、[投影変換 (Project)] ツールを使用して、それらを新しい座標系に変換します。
大きいテキスト フィールドを含むデータセットをパーソナル ジオデータベースから ArcSDE ジオデータベースへ読み込む場合
ArcSDE ジオデータベースからパーソナル ジオデータベースに移動したデータを、もう一度 ArcSDE ジオデータベースに戻さなければならないときがあります。ArcSDE データセットに 255 文字を超える長さのテキスト フィールドがある場合、そのデータセットをパーソナル ジオデータベースにコピーする、または読み込むと、テキスト フィールドは Microsoft Access のメモ フィールドとして格納されます。
ArcGIS はこのメモ フィールドを BLOB と解釈し、2,147,483,647 文字のサイズを割り当てます。Access のメモ フィールドはフィールド長を記録しません。実際にそれほど多くの文字をフィールドに格納する可能性は低いので、適切なフィールド長をメタデータで必ず指定してください。
パーソナル ジオデータベースからデータをコピーし、再度 ArcSDE ジオデータベースに貼り付けようとした場合、長さ 2,147,483,647 文字のテキスト フィールドの作成を試行することになるため、貼り付けは失敗します。ほとんどのデータベース管理システムは、2,147,483,647 文字ものテキスト フィールドをサポートしていないからです。
このような状況を回避するには、ArcSDE ジオデータベースでフィーチャクラスを作成し、適切なフィールド長に基づいてテキスト フィールドのサイズを定義します。次に、シンプル データ ローダーまたはオブジェクト ローダーを使用してデータを読み込み、パーソナル ジオデータベースのテキスト フィールドを、ArcSDE ジオデータベースのフィーチャクラスで定義したテキスト フィールドにマッピングします。