トポロジの基礎
このトピックは、ArcEditor および ArcInfo にのみ適用されます。
トポロジは、編集ツールやテクニックと組み合わせて使用される一連のルールであり、ジオメトリック リレーションシップをジオデータベースでより正確にモデリングできるようにします。ArcGIS は、フィーチャ間で地理空間を共有する方法を定義する一連のルールと、ジオメトリを共有するフィーチャを操作するための一連の編集ツールを通じて、トポロジを統合方式で実装します。トポロジは、1 つ以上のフィーチャクラスにあるフィーチャがどのようにジオメトリを共有するかを定義している 1 つ以上のリレーションシップとして、ジオデータベースに格納されます。トポロジに含まれるフィーチャは、シンプル フィーチャクラスです。トポロジは、フィーチャクラスの定義を変更するのでなく、フィーチャをどのように空間的に関連付けるかを説明しています。
なぜトポロジなのか
トポロジは、従来より、データの管理と整合性に欠かせない GIS の要件の 1 つです。一般に、トポロジ的なデータ モデルは、空間オブジェクト（ポイント、ライン、エリア フィーチャ）をトポロジ的なプリミティブ（ノード、フェイス、エッジ）のグラフとして表すことで、空間的な関連性を管理します。これらのプリミティブは、それらの相互のリレーションシップとそれらが表す境界線を持つフィーチャとのリレーションシップとともに、トポロジ エレメントの平面グラフでフィーチャ ジオメトリを表すことによって定義されます。
 |
トポロジは基本的に、空間的な関連性のデータの品質を確保し、データの編集を支援するために使用されます。また、隣接するポリゴン間の境界線を同じ属性値でディゾルブする、トポロジ グラフにある複数エレメントのネットワークをから成るネットワークを通ったり、さまざまな状況下での空間的な関連性の解析にも使用されます。
トポロジは、複数のフィーチャクラスのジオメトリを統合する方法のモデリングにも使用することができます。これはフィーチャクラスの垂直統合とも呼ばれます。
トポロジにおいてフィーチャがジオメトリを共有する方法
フィーチャはトポロジ内のジオメトリを共有することができます。次に、隣接フィーチャの例を示します。
 |
- エリア フィーチャは、境界線を共有することができます（ポリゴン トポロジ）。
- ライン フィーチャは、端点を共有することができます（エッジ/ノード トポロジ）。
さらに、フィーチャクラス間の共有ジオメトリをジオデータベース トポロジで管理することができます。たとえば、次のものがあります。
- ライン フィーチャは、他のライン フィーチャと線分を共有することができます。たとえば、土地区画をブロック内におさめることができます。
- エリア フィーチャは、他のエリア フィーチャと重ね合わせることができます。
- ライン フィーチャは、他のポイント フィーチャと端点を共有することができます（ノード トポロジ）。
- ポイント フィーチャは、ライン フィーチャ上に配置することができます（ポイント イベント）。
注意:土地区画は一般的に、単純なフィーチャクラスとジオデータベース トポロジを使用して管理されています。これは、土地区画、境界、角の位置、およびコントロール ポイントをモデル化するために必要な一連のフィーチャクラスが、必要な一致のルールに従うようにするためです。土地区画を管理するためのもう 1 つの方法は、自動的にユーザに土地区画レイヤを提供するパーセル ファブリックの使用です。ファブリックは内部トポロジを管理し、ジオデータベース トポロジを管理したり、土地区画によって使用される一連のレイヤにトポロジ編集を実行する必要はありません。
単純なフィーチャとしてモデル化された土地区画とファブリックにおける土地区画の重要な違いは、ファブリック パーセル境界（ファブリックにおける「ライン」）が共有されておらず、各土地区画の境界上にラインが存在する点です。つまり、隣接する土地区画のファブリック ラインは重複し、同じ位置に配置されます。
パーセル ファブリックがジオデータベース トポロジに含められる場合があります。この場合、重複する境界ラインは異なるジオメトリを持ち、ラインはクラッキングされて、トポロジ グラフは通常どおり作成されます。
2 つの表示方法：フィーチャとトポロジ エレメント
次の図は、ポリゴンレイヤがどのように描画および使用されているかを示しています。
- ジオグラフィック フィーチャ（ポイント、ライン、ポリゴン）の集まりとして
- トポロジ エレメント（ノード、エッジ、フェイス、およびそれらのリレーションシップ）のグラフとして
 |
これは、フィーチャを操作する方法が 2 つあることを意味します。1 つの方法では、フィーチャはそれらの座標によって定義され、もう 1 つの方法では、フィーチャは規則性のあるトポロジ エレメントのグラフとして表されます。
ArcInfo カバレッジからジオデータベース トポロジへの進化
注意:ジオデータベース トポロジを実装するためにこのトピックを読み通す必要はありません。ただし、トポロジが導入された経緯とジオデータベースでトポロジが管理される方法に興味がある場合は、このトピックを読んでください。
Arc ノードと Geo リレーショナルの起源
データの空間整合性を管理するためにトポロジが果たす役割は、ArcInfo カバレッジのユーザにとって待望の機能です。
次に、ArcInfo カバレッジのデータ モデルのエレメントを示します。
 |
カバレッジでは、フィーチャの境界線とポインタは複数のメイン ファイルに保存され、ArcInfo Workstation によって管理および所有されていました。Arc ファイルでは、リニアまたはポリゴン境界ジオメトリがトポロジ エッジとして保持され、「アーク」と呼ばれていました。LAB ファイルでは、ポリゴンのラベル ポイントとして、または井戸フィーチャ レイヤなどの個々のポイント フィーチャとして使用される、ポイント位置が保持されていました。さらに、それぞれのエッジとポリゴン間のトポロジ リレーションシップを定義および保持するために、他のファイルが使用されていました。
たとえば、PAL（ポリゴン / アーク リスト）ファイルには、各ポリゴンのアークの順番と方向が定義されていました。ArcInfo では、ソフトウェア ロジックを使用して、各ポリゴンの座標を表示、解析、検索処理のために組み立てていました。PAL ファイルの順序付きのエッジ リストは、ARC ファイルで保持されているエッジ座標の検索と組み立てに使用されていました。ポリゴンは、必要に応じて、実行時に組み立てられていました。
カバレッジ モデルには、次のような利点があります。
- トポロジを管理するための構造が単純です。
- エッジを一度だけデジタイズして格納し、複数のフィーチャで共有することができます。
- ポリゴンは、実際には順序付きのエッジ（アーク）として定義されるため、（数千個の座標からなる）巨大なサイズのポリゴンを表現することができます。
- カバレッジのトポロジ格納構造は直感的です。ArcInfo ユーザは、その物理トポロジ ファイルをすぐに理解することができます。
注意:「Info」という名前のテーブル マネージャと「Arc」の組み合わせが、ArcInfo という製品名と、それ以降のすべての Esri Arc 製品（ArcView、ArcIMS、ArcGIS など）の由来です。
カバレッジには、欠点がいくつかあります。
- 必要に応じて多くのフィーチャをリアルタイムに組み立てなければならないため、一部の操作ではパフォーマンスが低下します。これには、リージョン（マルチパート ポリゴンを意味するカバレッジ用語）やルート（マルチパート ライン フィーチャを意味するカバレッジ用語）などのマルチパート フィーチャが含まれます。
- トポロジ フィーチャ（ポリゴン、リージョン、ルートなど）は、カバレッジ トポロジが構築されるまで利用できません。エッジが編集された場合は、トポロジを再構築する必要があります。（注意：最終的には、カバレッジ トポロジの変更された部分だけを再構築する部分的な処理が使用されました。）一般に、トポロジ データセットのフィーチャを編集する際には、格納モデルにかかわらず、地理解析アルゴリズムを実行して、トポロジ リレーションシップを再構築する必要があります。
- カバレッジはシングルユーザ編集に制限されます。トポロジ グラフとフィーチャ ジオメトリの同期を保つ必要があるため、トポロジを更新できるのは一度に 1 人のユーザに限られます。ユーザはカバレッジをタイル分割し、編集用にタイル分割されたデータベースを維持します。これにより、個々のユーザが、分割された 1 つのタイルを一度に編集するようになります。一般的なデータの使用や導入に関しては、タイルのコピーをモザイク化されたデータ レイヤに追加します。つまり、編集済みのタイル分割されたデータセットを組織内で直接使用することはありません。それらは変換しなければならないので、余分な作業と時間が発生することになります。
シェープファイルとシンプル ジオメトリ格納
1980 年代の初め、カバレッジは旧式のポリゴンとラインベースに代わる、次世代のシステムと目されていました。それまでは、ポリゴンは完全なループとして保持されていました。旧式のシステムでは、フィーチャのすべての座標が各フィーチャのジオメトリに格納されていました。カバレッジと ArcInfo が登場するまでは、このようなシンプルなポリゴン / ライン構造が使用されていました。これらのデータ構造はシンプルでしたが、二重にデジタイズされた境界線という欠点を抱えていました。つまり、ポリゴンの隣接部分と共有エッジの 2 つの座標が、各ポリゴンのジオメトリに含まれていました。最大の欠点は、当時の GIS ソフトウェアが共有エッジの整合性を管理できなかったことでした。さらに、格納のコストは膨大で、格納領域の 1 バイト 1 バイトがとても貴重でした。1980 年代の初頭、300MB のディスク ドライブは洗濯機ほどの大きさで、30,000 ドルもしました。座標の表現を 2 つ以上保持するのは高価で、計算にもはるかに時間がかかってしまいます。このため、カバレッジ トポロジの導入は画期的な出来事でした。
1990 年代の中盤、ディスク領域やハードウェア コストが低下し、コンピュータの計算速度が向上すると、シンプルなジオメトリ構造が注目されるようになりました。同時に、既存の GIS データセットが利用しやすくなり、主にデータのコンパイルで占められていた GIS ユーザの作業に、データの使用、解析、共有が含まれるようになりました。
ユーザはデータを使用するときのパフォーマンスの向上を望むようになりました（たとえば、必要に応じてポリゴン ジオメトリを生成するためにコンピュータ時間を無駄にしたくない、この 1,200 個のポリゴンのフィーチャ座標をできるだけ速く提供したい、など）。完全なフィーチャ ジオメトリをすぐに利用できるようにするほうが効率的でした。そして、数千にのぼる地理情報システムはすでに使用され、膨大な数のデータセットが利用可能でした。
この頃、Esri は Esri Shapefile フォーマットを開発し、公開しました。シェープファイルは、フィーチャ座標に非常にシンプルな格納モデルを使用していました。シェープファイルはそれぞれ 1 つのフィーチャクラス（ポイント、ライン、ポリゴン）を表し、フィーチャ座標にシンプルな格納モデルを使用していました。シェープファイルは、ArcInfo カバレッジやその他多くの地理情報システムから簡単に作成することができました。シェープファイルはデファクト スタンダードとして普及し、現在でも広く使用され、導入されています。
その数年後、ArcSDE はリレーショナル データベース テーブルで同様のシンプルな格納モデルを実現しました。フィーチャ テーブルは、1 行につき 1 つのフィーチャを保持することができ、ジオメトリを保持する列とその他のフィーチャ属性を保持する列で行を構成することができます。
次に、州ポリゴンのサンプル フィーチャ テーブルを示します。行はそれぞれ 1 つの州を表します。Shape 列は、各州のポリゴン ジオメトリを保持します。
 |
このシンプルなフィーチャ モデルは、SQL エンジンにうまく適合しています。リレーショナル データベースを使用することで、パフォーマンスを低下させずに、GIS データを前例のないサイズとユーザ数に対応させることが可能になりました。そして、Esri では GIS データの管理に RDBMS を利用するようになりました。
シェープファイルは普遍的な存在となり、ArcSDE を使用することで、シンプルなフィーチャ メカニズムが RDBMS の基本的なフィーチャ格納モデルになりました。（相互運用性をサポートするために、Esri は OGC/ISO Simple Feature Specification の策定作業に尽力しています。）
フィーチャのシンプルな格納モデルには、明らかな利点があります。
- 各フィーチャの完全なジオメトリが 1 つのレコードに保持されます。組み立ては必要ありません。
- データ構造（物理スキーマ）が非常にシンプルで、高速で、スケーラブルです。
- プログラマがインタフェースを簡単に作成できます。
- 相互運用が可能です。これらのシンプルなジオメトリとその他の形式との間でデータをやり取りするシンプルなコンバータが数多く作成されています。シェープファイルは、データを使用および交換するための形式として広く導入されています。
欠点は、トポロジによって提供されるデータ整合性の維持が、シンプル フィーチャの実装ほど簡単ではないことでした。このため、編集と管理に適用するデータ モデル（カバレッジなど）と、導入に使用するデータ モデル（シェープファイルや ArcSDE レイヤなど）が異なる結果となりました。
ユーザは、このハイブリッド手法を編集やデータの導入に使用するようになりました。たとえば、ユーザはデータをカバレッジ、CAD ファイル、またはその他の形式で編集します。そして、それらのデータを導入または使用するために、シェープファイルに変換します。シンプルなフィーチャ構造は、直接使用するにはすばらしい形式でしたが、トポロジ対応の編集や共有ジオメトリの管理はサポートされません。直接使用するデータベースではシンプルな構造が使用され、編集には別のトポロジ形式が使用されました。これには導入上の利点がいくつかありましたが、データが古くなってしまい、更新しなければならないという欠点がありました。情報を更新するために遅延が生じました。要するに、トポロジが欠けていたのです。
GIS が必要としており、かつジオデータベース トポロジ モデルが実装するのは、シンプル フィーチャ ジオメトリを使用してフィーチャを格納し、このシンプルなオープン データ構造でトポロジを使用できるようにするメカニズムです。つまり、トポロジ的な検索、共有ジオメトリの編集、高度なデータ モデリング、データ整合性を可能にするトランザクション データ モデルと、シンプルなオープン フィーチャ ジオメトリに基づくスケーラビリティに優れたデータ格納メカニズムの両方が実現されています。
この直接使用のデータ モデルは、高速で、シンプルで、効率的です。さらに、任意数の同時ユーザによる直接的な編集と管理が可能です。
ArcGIS のトポロジ フレームワーク
事実上、トポロジは単なるデータ格納の問題ではないと考えられてきました。完全なソリューションには、次の要素が含まれます。
- 完全なデータ モデル（オブジェクト、整合性ルール、編集ツールと整合チェック ツール、任意のサイズと複雑さのデータセットを処理できるトポロジ/ジオメトリ エンジン、トポロジ演算子一式、マップ表示、検索ツール）。
- シンプル フィーチャの一連のレコード タイプを使用するオープン格納形式と、シンプル フィーチャを検索する、トポロジ エレメントを取得する、およびそれらの空間的な関連性をナビゲートするためのトポロジ インタフェース（隣接エリアとそれらの共有エッジの検索、接続しているライン沿いのルート検索など）。
- フィーチャ（ポイント、ライン、ポリゴン）、トポロジ エレメント（ノード、エッジ、フェイス）、および互いのリレーションシップを提供する機能。
- サポート可能なメカニズムは次のとおりです。
- 数百万個のフィーチャからなる巨大なデータセット
- 多数の同時ユーザによる編集と管理の実行
- いつでも利用可能なフィーチャ ジオメトリ
- トポロジ的な整合性とロジックのサポート
- 多数のユーザおよびエディタに高速に対応できるシステム
- 柔軟でシンプルなシステム
- RDBMS の SQL エンジンとトランザクション フレームワークを活用するシステム
- 複数の編集ユーザ、ロング トランザクション、履歴管理、レプリケーションをサポートできるシステム
ジオデータベース トポロジでは、整合チェック プロセスにより、（同じフィーチャクラス内で、およびフィーチャクラスにまたがって）フィーチャ間の共有座標を特定します。クラスタリング アルゴリズムを使用して、共有座標が同じ位置にあることを確認します。これらの共有座標は、各フィーチャのシンプル ジオメトリの一部として格納されます。
これにより、トポロジ エレメント（ノード、エッジ、フェイス）の非常に高速かつスケーラブルな検索が可能となります。これには、RDBMS の SQL エンジンとトランザクション管理フレームワークに対応し、活用するという利点があります。
編集と更新の過程では、フィーチャが追加されると、それらは直接使用できる状態になります。マップ上の更新されたエリア（ダーティ エリア）がマークされ、各フィーチャクラスの更新に応じて追跡されます。ユーザはいつでもダーティ エリアのトポロジ解析と整合チェックを選択して、クリーンなトポロジを生成することができます。再構築が必要なのはダーティ エリアのトポロジだけなので、処理時間が節約されます。
結果として、トポロジ プリミティブ（ノード、エッジ、フェイス）と、プリミティブ間およびフィーチャとのリレーションシップを効率的に検出し、組み立てることができます。これにはいくつかの利点があります。
- フィーチャにはシンプル フィーチャ ジオメトリ格納が使用されます。この格納モデルは、オープンかつ効率的で、大きなサイズや多くのユーザに対応します。
- このシンプル フィーチャ データ モデルは、トランザクションとマルチユーザに対応します。対照的に、以前のトポロジ格納モデルにはスケーラビリティがなく、複数の編集トランザクションやその他の GIS データ管理ワークフローのサポートに問題がありました。
- ジオデータベース トポロジは、ジオデータベースのロング トランザクションとバージョン対応機能を完全にサポートします。ジオデータベース トポロジをタイル分割する必要はなく、多くのユーザはトポロジ データベースを同時に編集することができます。必要であれば、同じフィーチャの個々のバージョンを操作することができます。
- フィーチャクラスのサイズ制限はなく（数十億個のフィーチャを使用できます）、優れたパフォーマンスを発揮します。
- このトポロジ実装は付加可能です。通常は、これを空間的に関連するフィーチャクラスの既存のスキーマに追加することができます。もう 1 つの方法は、既存のフィーチャクラスをすべて再定義して、トポロジ プリミティブを保持する新しいデータ スキーマに変換することです。
- ジオメトリの編集や使用に必要なデータ モデルは 1 つだけです。
- すべてのフィーチャ ジオメトリ格納が Open Geospatial Consortium/ISO の Simple Features Specification に準拠しているため、相互運用が可能です。
- データ モデリングはトポロジ プリミティブ（ノード、エッジ、フェイス）ではなくユーザ フィーチャ（土地区画、道路、土壌タイプ、分水界など）に基づいているため、より自然です。ユーザは、トポロジ プリミティブの整合性ルールではなく、実際のフィーチャの整合性ルールやロジックについて考えることから始めます。たとえば、土地区画のロジックはどのようなものでしょうか。これにより、あらゆる種類のジオグラフィック フィーチャをより適切にモデリングすることができます。これにより、道路、土壌タイプ、国勢調査区、分水界、鉄道、地質、森林区、地形、物理フィーチャなどについて考えやすくなります。
- ジオデータベース トポロジは、トポロジ ライン グラフを保存してフィーチャ ジオメトリを検出するか（ArcInfo カバレッジなど）、フィーチャ ジオメトリを保存してトポロジ エレメントとリレーションシップを検出するかにかかわらず（ジオデータベースなど）、永続化されたトポロジ実装と同じ情報を提供します。
ユーザがトポロジ プリミティブを保存したい場合、さまざまな解析 / 相互運用目的のためにトポロジおよびリレーションシップを作成して、簡単にテーブルにポストできます。（トポロジ プリミティブのテーブルを格納する Oracle Spatial ウェアハウスにフィーチャをポストするなど）。
ArcGIS のトポロジ実装は、現実的なレベルで機能します。パフォーマンスを低下させずに、非常に大きなジオデータベースやマルチユーザ システムに対応します。ジオデータベースでトポロジを構築して管理するための整合チェック ツールと編集ツールが含まれています。また、柔軟なデータ モデリング ツール一式が揃っており、ファイル システム、任意のリレーショナル データベース、および任意数のスキーマに対応する現実的なシステムを組み立てることができます。